Chatwork Creator's Note

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

読者になる

ブランチとリリースと私

こんにちは、サーバーサイド開発部@東京のあらいです。最近オフィスで下駄を履いています。

さて、先日「ファイル保持機能」をリリースしました。

blog-ja.chatwork.com

この機能の開発を通じて、また前職での開発方法と比較して、gitのブランチ運用とリリースについて考えました。そのこと書きたいと思います。

ファイル保持の開発

ファイル保持はチャットワークというシステムの大きな仕様変更でした。 リリース以前は「ファイルをアップした人が部屋を退席すると、そのファイルは消える」という仕様になっていました。 この仕様は古くからあるもので、シンプルな一方で使い勝手の悪さがあります。私の使命はこの仕様を変更することでした。

調査の結果、この仕様を前提としたコードがあちこちに散在していることが分かりました。 そこで「最初にリファクタを行い業務ロジックを凝集したのち仕様変更を行う」という方針を立てました。 私は今年2月ごろから設計を始め、4〜5月にかけてリファクタを、6〜7月にかけて仕様変更を段階的にリリースしていきました。 この間のPRの数は計34本に上ります。

f:id:cw-arai:20180731005629p:plain

git-flowの効能

さて、先に現在のチャットワークのブランチ運用とリリースについて軽く説明しておきましょう。 チャットワーク*1ではgit-flowを採用しています。 phpエンジニア10名弱の他、マルチタレントなフロントエンドエンジニア、SRE、一部マネージャー陣もcontributeしており、1日で数十コミットがdevelopにマージされます。 これを1日に1回〜数回デプロイします。デプロイスクリプトはcapistranoでできており、Jenkinsのジョブを通して開発者自身がリリースできるようになっています。

この運用のため、ファイル保持も変更を小さい単位で少しずつリリースすることが可能でした。 これは特に開発前半のリファクタでは小さいリリースの効果が顕著で、1回の影響範囲を小さく保ち、リリースに臨む開発者(自分)のストレスが軽減されたと感じました。

git-flow以前との比較

これ以前はどうだったのでしょうか? チャットワークに転職する以前の開発では、リリースはmonthlyであることが多く、 ブランチ運用はリリース/マイルストーン単位の安定トランクパターンをベースにしたものが多数でした。 これはこれで好きなやり方でしたが、振り返ってみれば次のような問題があったと思います。

  • 1回のリリースで変更するコードの量が大きく、影響範囲も大きい
  • 仮にリリースに失敗した場合、次のリリースまでの間隔が広いので、計画に与えるダメージが大きい
  • 以上から、リリースに感じる心理的負担(責任・重圧・ストレス)が大きくなる

もちろんリリースは気軽に失敗していいというものではありません。 今回はSLAに抵触こそしなかったものの、不具合により数度のリリース切り戻しがありました。 またデータのライフサイクル周りで設計/調査の甘い部分があり、土壇場になってテーブルの構成を変更することがありました。 SRE部のメンバーに予定外の負担を強いてしまったことは大きな反省点です。 しかしそれを差し引いても「人間は不完全なものだ」という前提に立てば、失敗後の再チャレンジをしやすくする仕組みは重要だったと思います。

これから先のブランチ運用とリリースの形

git-flowとそれ以前の対比をよく検討すると、本当に大事なのはgit-flowというブランチ運用ではなく、 "dailyにリリースしていること""dailyなリリースを可能にしている環境" だと気がつきます。 これからのブランチ運用・リリースはどうあるべきでしょうか?

私はdailyなリリースを推し進め、hourlyなリリースを可能にすること、そのための環境を整えることが重要だと感じました。 それがよりストレスを抑え、早くリリースし、より早く失敗をリカバリーすることにつながるからです。 その状況ではgit-flowではなくgithub-flowがブランチ運用として適当でしょう。 なぜならば、全く無関係なブランチを"develop"として1つにまとめ、releaseブランチを通じて同じタイミングでリリースする必要がないからです。 独立したfeatureは独立して、依存関係のある複数のfeatureは統合ブランチでマージして、それぞれのタイミングでリリースできることが理想です。

理想を実現するにはデプロイスクリプトの改善やテスト実行時間の短縮をはじめ、解決すべき課題がたくさんあるのが現状です。 しかし、チャットワークを使ってくださっている全ての方により快適なサービスを届けるため、地道に改善を進めていきたいと思います。

We're Hiring!

チャットワークでは一緒に働く仲間を募集しています。 よりよいプロダクトを作る熱意を持つ人、ハイスループットかつリアルタイムな実行環境で技術に磨きをかける人、 地道な改善が得意な人、いろんな人がいろんな形でサービスに貢献しています。 少しでも興味を持たれた方はぜひ一度話を聞きに来てください。お待ちしております。

corp.chatwork.com

*1:主にPHPのAPI群とScalaのメッセージングシステムがありますが、これはPHP部分の話です