2017年はGitLabだけで開発のタスク管理を完結するのも夢じゃない
ピクシブ株式会社 Advent Calendar 2016、18日目の記事です。
こんにちは、エンジニアの@uchienneoです。2015年に小説PDF化機能の記事を書いた時にはpixiv本体の機能開発をメインにやっていたのですが、2016年夏に弊社メディアサイトwww.pixivision.netをリニューアルしてからはそちらの開発に携わっています。
pixivやpixivisionのソースコードの管理には自社ホストのGitLabが使われています。(どのようにGitLabが運用されているのかの詳細は16日の@catatsuyさんの記事をご覧ください)
GitLabにはタスク管理の機能があります。こちらの機能もどんどんアップデートを続けていて、そろそろ来年くらいにはGitLabだけでタスク管理するのも夢じゃないのでは…と思っています。
今回は実際のプロジェクトにおけるGitLab上でのタスク管理の運用とあわせてその展望を紹介します。
タスク管理ツールとしてのGitLab - 長所と短所
ピクシブでは基本的にはチーム単位で開発をおこなっていて、タスク管理の方法もチームごとの裁量に任されています。 よく使われているものとしては以下のものがあります。
- Trello
- GitHub
- GitLab
- 物理ホワイトボードにスイムレーンを書き、付箋を貼って管理
タスク管理ツールとしてはGItLabを見た時の以下のような部分が特徴的です。(一部GItHubと重なる部分もあります)
長所
- コードとissue、MR(Merge Request = Pull Request)、Milestoneを一元管理できる
- MR, issue, コミットメッセージにリンクを書くとそのまま互いの関連付けができる。
fixed / closed #123
のようにコミットメッセージを書いてそのままissueを閉じることもできるし、
- MR, issue, コミットメッセージにリンクを書くとそのまま互いの関連付けができる。
- 開発が活発で、欲しい機能はたいてい実装されているか、今後実装予定がある
- 2016年現在ではあまり意識する必要がないことかもしれないが、Markdown記法が使える(ピクシブでは過去にRedmine*1とMoinMoinを併用していた時代があったが、Textile記法やMoin記法をMarkdownとは別に覚える必要があった)
短所
- issueの優先順位や順序づけなど複雑な関係性の設定や、issueとスケジュールの関連づけなどには弱い(こういった概念づけは基本的にすべてタグで補うという思想)
- 基本的な機能以外を使う際のUIが複雑でわかりづらい
- 例えばmilestoneは複数のプロジェクトを跨いで配置することができるため、GitLabのmilestoneの詳細ページにはすべてのプロジェクトを通してmilestoneの状況が見られるページと、1つのプロジェクトに限ったmilestoneの状況が見られるページがある。この2つは一見ほとんど同じ見た目をしているが微妙に機能が異なり、紛らわしい
pixivisionでは開発のタスク管理は現在ほぼすべてGitLab上でやっています。
pixivisionでの実際の運用
基本運用スタイルは以下のような感じです。
- 1週間ごとにイテレーションを切り、GitLab上でMilestoneを作成する
- それぞれのタスクにストーリーポイントをつけて、イテレーションごとにどれだけのストーリーポイントをこなせるのかを計測し、それを元にこなすタスクの量を決めていく
- タスクの進行状況はGitLabのスイムレーン上で管理し、基本的にはそこを見れば自分のやるタスクがすべてわかるようになっている
GitLabでタスクをTrelloのようにスイムレーン形式で管理する方法としてはそのままMilestone詳細ページを見るやり方の他に比較的最近実装されたBoard機能を使うやり方があります。
2つの機能を比較すると、Board機能はまだ新しいためなのかissueの管理という部分であまりパワーがなく、比較的タスクの規模の小さいpixivisionチームではMilestone詳細ページのレーン数でもあまり不便がないため、issueの状態を直接操作することを優先してMilestoneページの方を利用しています。
現状の運用上の問題点 - ベロシティとレビューの管理が難しい
現在の運用で開発上のタスク管理はほとんどGitLabを見れば大丈夫という感じになっているのですが、まだいくつか難しい問題もあります。
まず、イテレーションの開発ベロシティの管理について、GitLabにはストーリーポイントをつけるという機能がないため、ストーリーポイントの管理は現状、タイトルにストーリーポイントと期日を入れておき、イテレーションの終わりごとに手でポイントを足し合わせて計算するというアナログな方法でやっています。
また、現在pixivの開発では1つのコードを必ず2人以上がレビューするという方針を取っているのですが、 GitLabではMRやissueに担当者を1人しかアサインすることができません。このため、どうしてもレビュー依頼はチャットやほかの手段を通じて出さなくてはならず、自分が今どのレビューを依頼されているのかわからなくなるということがしばしばあります。
これらの機能についてはGitLabの開発コミュニティで現在実装が進んでいるようで、リリースを心待ちにしています。
- https://gitlab.com/gitlab-org/gitlab-ce/issues/13386
- https://gitlab.com/gitlab-org/gitlab-ee/issues/91
まとめ
- GitLab上だけでイテレーション単位の開発タスクのやりとりはほとんどできる
- バーンダウンチャートと複数人アサインが実装されたら、GitLab上ですべて完結させるのも夢じゃない
明日のAdvent Calendarはpixivの決済システムの番人、 @ik-fib さんが担当してくれます。
*1:現在はMarkdown記法が使えるようになっているらしい
GitLabの運用方法をドーンと公開!!
ピクシブ株式会社 Advent Calendar 2016の時間です。今回はピクシブ株式会社でエンジニアをしている @catatsuy が担当します。今回は意外と書いてなかったのでGitLabを社内でどう運用しているかの話を書こうと思います。
GitLabとGitHub
ピクシブ社内では以下の2つの方法でソースコードを管理しています。
- 自社でホストしているGitLab
- GitHub Organization
それぞれ以下の特徴があります。
- GitLabのメリット
- 自社でホストしているため、アメリカにサーバーがあるGitHubよりも
git clone
でリポジトリをダウンロードする場合などは速い - オープンソースのプロジェクトのため、社内のサーバーにインストールするだけで使える
- ソースコードを読めば内部でやっていることが分かる
- ユーザー数やリポジトリ数などで料金がかからないため、気軽に使える
- 自社でホストしているため、アメリカにサーバーがあるGitHubよりも
- GitLabのデメリット
- バージョンアップは自分たちでやる必要がある
- 停止する必要がある
- バージョンアップは自分たちでやる必要がある
- GitHub Organizationのメリット
- GitHubと全く同じ使い方ができる
- 外部サービスの連携が充実している
- 外部の会社とのやり取りに使うこともできる
- GitHub Organizationのデメリット
- ユーザー数やリポジトリ数などで料金がかかる
- 日本からだと回線が遅いので、容量の大きいリポジトリだと扱いにくい
ピクシブ株式会社では社内でpixiv.git
と呼ばれている最も大きなリポジトリでGitLabを使用しています。今回は弊社でのGitLabの使い方や運用方法について紹介します。
GitLab上のユーザー権限について
GitLab上のユーザー権限は複数存在します。
Permissions - GitLab Documentation
現在社内では社員全員Developer権限にしています。そうするとリポジトリの作成権限などもなくなるので、Owner権限をもつアカウントを用意して必要なときだけそのアカウントを使用しています。
またGitLabにはprotected branches機能があります。この機能を使うことでmasterブランチなど特定のブランチに対してforce pushを禁止することが出来ます。現在ではGitHubでも使える機能ですが、GitLabには以前から存在した機能の一つです。
pixiv.gitでは基本的に作った本人がmasterブランチにmergeして、本人が本番にデプロイするルールで運用しています。しかしprotected branches機能を使うとDeveloper権限のユーザーでは通常のpushすらできませんでした。そのため以前はDeveloper権限のユーザーでもpushできるようにGitLab側にパッチを当てていました。現在ではDeveloper権限のユーザーにもpushする権限を与えることができるので、現在ではパッチを当てていません。
会社によってはGitLabにパッチを当てて運用していると聞きます。GitLabはオープンソースで開発されていて、主観ですがソースコードも読みやすいと思います。なのでパッチを当てることが容易なところもGitLabの魅力です。以前は上記のパッチを当てていましたが、現在ではGitLabにパッチを当てずに運用しています。
GitLabの認証
pixivの開発サーバーはLDAPでユーザーを管理しています。なのでpixivの開発に関わる人は全員LDAPのアカウントを所有しています。そこでGitLabの認証もLDAPを使用しています。LDAP経由で初めてログインを行った際にユーザーが作成されるので、その後にOwner権限を持っているユーザーでGroupにDeveloper権限で所属させることでアカウントを作成しています。LDAPでの設定は以下のURLを参照してください。
加えて、GitLabではRubyで広く使われている omniauth/omniauth で使える認証を使用できます。
社内でGoogle Appsを使用している場合はそのGoogle Appsのアカウントを使用して認証することなども可能です。各社で最適な認証方法で提供できることもGitLabの魅力です。
詳細は以下のドキュメントを参照してください。
OmniAuth - GitLab Documentation
外からも使いたい
社内のGitLabは社内のネットワークからのみ参照できるようにしていました。しかしこれだと社外からアクセスする場合にVPNを使う必要があります。VPNを使うのは手間ですし、ネットワーク機器上の制約もあります。そこでGitLabをもっと社外から気軽に見られるようにしたいという需要が社内からありました。そういった場合に社内ではgateを使ってGoogle認証で提供していました。それについては以前に私が記事を書きました。
ただしgateは最近ほとんどメンテナンスされていません。またgateは単純なプロクシサーバーとして機能するわけではないため、GitLabのような様々なオープンソースのツールに対応するのは難しい部分があります。そこで最近では bitly/oauth2_proxy を使って、下の記事の方法で前段にGoogle認証を挟むことで外部からでも手軽にセキュアにアクセスできるようにしています。
GitLabで前段にGoogle認証を挟む場合はいくつか注意すべき点がありました。それを紹介します。
GitLabの前段にGoogle認証を挟む
pixivの開発は専用の開発サーバー上で行われています。そのサーバーは自社データセンター内に存在するため、GitLab上のリポジトリへのアクセスはデータセンター内のサーバーで使えるプライベートなホスト名を使ってsshでアクセスしています。
しかしGitLabでは外部から見れるドメインと、ssh経由でリポジトリを持ってくる際のドメインは同じであることが前提になっているため、指定できるhost名は1つだけです。またGitLab上のソースコードは機密情報でもあるため、HTTPS通信にしたいです。そうなると当然外部から解決できるドメイン名で提供する必要があります。
つまり以下のような設定にしたいです。
- ブラウザからは外部から解決できるドメイン名でHTTPS通信で見れる
git clone
はsshからのみ行う- sshのURLのドメインはデータセンター内のプライベートなホスト名
GitLabの設定はgitlab.yml
にYAMLで記述します。HTTPSで提供する場合はgitlab:
以下でhttps: true
と記述します。gitlab:
以下のhost:
にブラウザ上で見れるドメイン名を記述します。
これではリポジトリのsshのURLでhostに指定したもので表示されてしまいます。そこでgitlab.yml
のgitlab_shell:
の下に ssh_path_prefix: "git@private.domain:"
という設定を行います。そうすることでリポジトリのURLだけを変えることが出来ます。
GitLabではリポジトリのURLとしてデフォルトではhttpとsshの両方を提供していますが、Google認証を通した時点でhttp経由ではgit cloneができなくなります。GitLab上の設定でEnabled Git access protocols
というものがあるため、ここをsshのみにすることでGitLab上ではsshのURLしか表示されなくなります。
実は設定のssh_path_prefix
はGitLabにパッチを当てるつもりでソースコードを読んでいたときに見つけました。ドキュメントにも載って無さそうだったので隠しオプションかもしれません。使用する際はソースコードを読んで使えるか確認した方がよいでしょう。
バージョンアップについて
GitLabの開発は非常に活発なため、定期的にバージョンアップをしたいです。基本的にはドキュメント通りに行えば問題ありませんが、実際に社内で行っているバージョンアップ方法を紹介します。
GitLabでは全てのバージョン間のバージョンアップ方法のドキュメントが用意されています。現在使用しているバージョンから使いたいバージョン間のドキュメントは必ず全て目を通しましょう。
gitlabhq/doc/update at master · gitlabhq/gitlabhq · GitHub
ドキュメントはほとんどが毎回コピペされているだけですが、バージョンによってはコピペではない文章が書かれていることがあります。その文章を手元にコピーするなどして忘れないようにしましょう。バージョンにもよると思いますが、基本的には複数のバージョンアップを同時にやっても問題ありません。ただし先程紹介したコピペではない文章に注意する必要があります。
バージョンアップのドキュメントでは必ず最初にバックアップを行っています。GitLabのバックアップではMySQLで使用している場合はmysqldumpと、gitリポジトリのバックアップをしています。停止時間はできる限り小さくしたいところですが、MySQLのデータが増えるとmysqldumpだけでもかなりの時間を使います。
バージョンアップの作業では基本的にgitリポジトリをいじることはないため、実はmysqlを停止してからdata_dir以下をバックアップするだけで十分なことがほとんどです。ただし今後のアップデートで変わる可能性があるのでバックアップをどの程度行う必要があるかは各自で確認してください。
またGitLabのリポジトリ上に.ruby-version
があります。Rubyのコンパイルにはそれなりに時間がかかるので、次に使いたいGitLabのバージョンで使うRubyは予めインストールしておきましょう。rbenvであれば複数のバージョンをインストールする事が可能です。新しいバージョンのRubyをインストールする際は、そのRubyのバージョンでbundlerのインストールをすることを忘れないようにしましょう。
まとめ
紹介したように、GitLabは認証について柔軟な設定ができます。またGitHubが障害になっても業務が行えたり、自社でホストしているためリポジトリのダウンロードが高速に行えるメリットがあります。ソースコードが読みやすいOSSなので、必要に応じてパッチを当てる事も比較的容易です。バージョンアップで気を付けるべき点などもありますが、皆さんの会社でも社内のリポジトリ管理にGitLabを使ってみてはいかがでしょうか。
次回は弊社が誇るおもしろアルバイターのhakatashiがおもしろエントリーを公開してくれます。hakatashi の検索結果 - pixiv inside で是非予習してからご覧ください!