皆さんお元気ですか?LINEサーバー開発室でサーバ開発を担当している崔珉秀と申します。
この記事ではLINEのサーバーの開発とリリースプロセスについて述べたいと思います。
LINEの開発者はどんな形で開発しているのか、サービスに変更事項をどのように適用しているのか、お互い協力してより良い開発環境を得るためにどんな努力をしているのかをお伝えする機会になったらいいなと思います。
ここで述べるリリースプロセスは、LINEのサーバ開発の流れとソース管理システムの運用方法、そして本番環境に変更事項を適用するまでの過程です。
LINEのServer Applicationはその役割とシステムの構成によって複数のServer Applicationに分かれて構成されています。
例えばNetwork通信及びProtocolなどを担当するApplication、messagingやsocial graphなどの中心となるロジックを担当するCore Messaging Application、その他に機能別に様々なApplicationに分かれて構成されています。
特に、その中でコアロジックを担当するCore Messaging Applicationのprojectについては、数十人の開発者たちが同時に複数の共同作業を進行しています。
多くの開発者たちが複数のイシュー(要求事項)に対する作業を同時に進行すると、それぞれの作業による混乱や現在どんな内容が進められているのかに関して曖昧な状況になりやすくなります。こんな問題点などを少しでも改善したいと考えて共同開発進行の手間を最小限にする前提のルールやポリシーを開発者同士が集まっていつも一緒に思考錯誤しています。
その成果物がこのLINE Serverのリリースプロセスです。
それではここからLINE Server Applicationの開発環境について説明します。LINEのprojectはソース管理システムとしてGitを使用しています。
Git project管理システムとしてはGitHub enterpriseを採用しています。
Githubはcode reviewおよびpull request、issue別milestone機能など様々に活用されています。
ブランチ管理の仕組み
LINE Server Applicationのprojectのブランチ管理は一般的に知られたgit flowとgithub flowを混用した構造を使用しています。
| Branch name | Role |
|---|---|
| master | Release Phase |
| RC | Test just before release |
| develop | BETA Phase |
| feature | ALPHA、BETA Phase |
- master branchは本番に反映されているcodeを基準とします。本番のbuildとRC(Release candidate)のbranch生成のために使用します。
- RC branchは本番にreleaseする直前に作業された事項を本番と出来るだけ同じ環境でテストするため、masterからbranchした後に変更事項を適用して使用します。テストが完了すると、変更事項に関するcommitは別のpull requestを通じてmasterに反映されてRC branchは削除されます。
- develop branchはテスト環境および開発環境のcodeのベースです。社内テスト環境であるBETA環境のbuildとfeature branchの生成のために使用します。
- feature branchは開発進行の立ち上げに向けた作業のbranchです。作業された内容はpull requestを通じてdevelopに反映されます。
Release process
ここからはもっと詳しくそれぞれのbranchを使用して開発する過程とreleaseするまでの過程を見て行きましょう。
| # | Steps | Role |
|---|---|---|
| 1 | 開発開始 | Developer |
| 2 | develop branchに反映に向けた準備 | Developer |
| 3 | code review & merge to develop | Reviewer |
| 4 | BETA統合Test(QA) | QA Tester、Developer |
| 5 | リリースの準備-Pull request生成 | Developer |
| 6 | リリースの準備-Pull requestマージ | Reviewer |
| 7 | リリースの準備 - リリース内容の共有 | Developer |
| 8 | リリースを行う。-リリースのdriving | Release driver |
| 9 | リリースを行う。-リリースの状況共有 | Release driver |
1. 開発開始
開発者の開発及び変更作業はmain repository (upstream)をforkしたpersonal repository (origin)で行なわれます。developからbranchingしたfeature branchでそれぞれの開発者毎の開発及びテストを進行します。作業が完了すると、git commit commentにISSUEのIDを含めてcommitを生成します。
2. develop branchに反映に向けた準備
作業されたcommitはpull requestを通じてmain repositoryのdevelop branchに反映されます。pull requestには、変更内容に対する簡単な説明のほか、必要に応じてreviewをしてほしいメンバーを指定できます。
3. code review
Pull requestを元にcode reviewを行います。codeやcommitにcommentを追加してfeedbackを反映したcommitをpull requestに追加していきます。このようなcode reviewの過程はLINE Serverのすべての開発者が参加/閲覧することができます。code reviewが完了したら、reviewerがpull requestをmergeすることによってfeedbackが反映された作業内容をmain repositoryのdevelop branchに適用します。
頻繁なコードレビューの痕跡(なんと20カ所以上のcommentを受けたpull request-少ない修正でも色んな知識が共有されて共に成長出来るLINEサーバー開発者)
4. BETA統合Test(QA)
develop branchに作業内容が適用されると、BETAテスト環境にSNAPSHOT buildをdeployして変更事項を適用します。このBETA環境は実際にLINE BETA Client(App)を使って社内テスト及びQA専門のテスターによる機能検証を受けることができます。System内部の変更事項だけでClientによる機能のテストが困難な場合にも、回帰テスト及びシステムに対する影響の評価のため使用されます。このようなBETAテストを通じて作業内容に対する質を高めたり、問題を事前に発見することができます。テストの結果がOKではない場合は１番~4番の過程を繰り返してそのイシューを完成させます。
5. リリースの準備-Pull request生成
BETA統合テストが終わったら、開発者は自分の作業内容をLINEサービスにリリースするための準備を行います。この過程もpull requestを通じて行われます。開発者はpersonal repositoryのmasterにdevelop/featureに作業した内容を適用します。そしてpersonal repositoryからmain repositoryのmaster branchへのpull requestを生成します。このリリースpull requestは本番の変更の内容を管理する目的で、以下のような内容を含みます。
- 関連されたISSUE URL(BTS-issue manage system)
- 当該の変更についてISSUEのURLを通じて詳細を確認できます。
- QAテスト結果(Sign-off by)
- テストを進行状況の確認ができます。
- Developのcode reviewer(Reviewed by)
- Develop pull request URL
- code reviewの進行状況の確認ができます。
- Target version(Milestone)
- いつどのようなバージョンで本番に適用されるPull requestかを示すMilestoneを設定します。
このMilestoneはgithubのMilestone taggingを利用しています。Milestoneは毎バージョンごと合わせた日付別に予定するPull requestを管理する目的で使っています。
6. リリースの準備-Pull requestのマージ
5番の過程で生成されたpull requestは前回と同じcode reviewerが再度チェックを行ないます。リリースのpull requestとして必要な項目をきちんと含んでいるか、また、masterへ入れるcommitに必要な内容が問題がなく入っているかの確認を進めてその内容などをcommentとして書きます。また、含めるべきでない不必要な修正を含んでいないかも確認をします。問題なければ、同僚の開発者により、当該pull requestは指定されたmilestoneリリースのタイミングでmain repositoryのmasterにマージされます。
7. リリースの準備-リリース内容の共有
このようにリリースのための基本作業が完了すると、各開発者はリリースすることをLINEのServer開発者が参加している共有用のLINEのグループのチャットを使ってLINE Server開発者たちに共有します。共有メッセージを通じていつもどのような内容が適用されるというのかを確認できるようにします。
8. リリースを行う。-Release driving
リリースする際、milestone中での複数の開発者による複数のイシューが入っている場合はpull requestを登録した開発者の中でRelease driverを選定します。このRelease driverはRCテストのためのbuildの管理や実際のリリース時に必要なdeploy(配信)やサーバの再起動などの運用に関する作業を行います。
あるReleaseに反映するイシューを持っている開発者の中で一人がRelease driveを担当することになります。逆にRelease driveを担当しない開発者はそのリリースのPassenger(乗客)と呼んだりします。LINEサーバー開発者の間ではお互いにReleaseのdriveを率先して担当したり、あるいは譲ったりして(?) 、お互いの安全なリリースを祈願するなどの文化があります。3億5千万以上のユーザが使用するサービスの中心となるサーバーであるため、Release driveの規則を遵守します。もし、サーバーのリリースの進行に問題があるときは皆がグループのチャットを通じて共有してお互いに問題解決を助け会いながら、毎日のリリースを行います。
9. リリースを行う。-Releaseの状況共有
Release driverはReleaseの進行状況をLINEのグループのチャットを通じて共有します。その中でそれぞれ担当した部分のモニタリングしながら特異事項がある場合、直ちにお互いに情報を交換して素早く対応きるように努めています。リリースが完了したら、必要な場合は最後にモニタリングシステムのalarmの設定を調整して、関連された部署にリリースの完了を共有します。
milestoneとして設定されたPull requestをまとめてRelease noteとして使います。
| Role name | Roles&Responsibility |
|---|---|
| Developer(Passenger) | development/make pull request |
| Reviewer | code review/check&merge pull request |
| QA Tester | Test on BETA、RC/confirm quality |
| Release driver | build release/deploy/server restart |
ここまでLINE Serverのリリースプロセスについて説明させて頂きました。このリリースプロセスは完全なものではなく、開発者が日々の業務を行ないながら気づいた点を修正したりして少しずつ変化しています。
今後も変わっていくと思いますが、以下に述べる3つのkeyword(特徴)で表わされるポリシーは今後も遵守されていくでしょう。
今回の説明はこの特徴をまとめて終わりにしたいと思います。
1. 公開 (public)
開発の過程とその内容はすべてのLINE Server teamのメンバーたちに公開されます。
多くのメンバーが一緒に開発するServer Applicationなのでそこにどのような変更があるかを常時お互いに情報を交換しながら
LINEのサーバーに対して同じような感覚を維持出来るようにしています。
この積極的な情報の公開によって蓄積された共通の認識が、普段のコミュニケーションをよりスムーズに、また明確にすることを促進していると考えています(Stay tune)
2. 参加 (open)
当該サーバApplicationの開発の内容については、LINEサーバーの開発者ならだれても意見を提案して一緒に仕事が出来るようになっています。
お互いがより良い品質の成果物を出すために助けてあげ、助けて貰うことで、共に成長していきます。
3.分散 (distributed)
code reviewやreleaseに対する確認/受け入れ等が特定の人によって行われるのではなく、一緒に働くメンバーたちの間で行われています。
本番にリリースするための運用作業やモニタリングなどについても、誰でも交代しながら同じように行なうことができます。
特に、reviewerとrelease confirmを進行するメンバーの責任が重要であることで、みんながリリースのプロセスの中で政策的に定めているそれぞれの項目が
どのような目的を持って作られているのかを理解してお互いが合力して定められている内容を遵守しようと努力しています。
(Link1)git flow : http://nvie.com/posts/a-successful-git-branching-model/
(Link2)github flow : http://scottchacon.com/2011/08/31/github-flow.html