みんなのウェディングの継続的デリバリー

みんなのウェディングの高井です。今回は、みんなのウェディングで構築している継続的デリバリーの仕組みについての話です。

継続的デリバリーとは?

インターネットサービスを提供していくうえで、とても重要なプラクティスのひとつに「継続的デリバリー」があります。継続的デリバリーとは、ソフトウェアをいつでもリリース可能な状態にしたままで構築していくというソフトウェア開発の規律です。

継続的デリバリーを採用することで、ソフトウェアのリリースサイクルを短かくすることができるようになります。リリースサイクルを短かくすることは、サービスの仮説検証プロセスを短かくすることにつながります。

サービス開発の本質は、どこにあるのか分からないユーザーのニーズをとらえることにあります。ですから、仮説検証の機会を最大化できる継続的デリバリーはサービス開発にとって、欠かせないプラクティスとなるわけです。

完了条件を定義する

ソフトウェアをいつでもリリース可能な状態にするためには、まずリリース可能な状態、つまり何時をもって開発が完了したのかということを決めなくてはなりません。これが完了条件です。完了条件はプロダクトの規模や性質によって異なります。また、同じプロジェクトでも時期によって変わることもあるでしょう。

みんなのウェディングでは、次のような完了条件を設けています。

  • コーディング規約やセキュリティ規約に従っていること
  • 開発者によるコードレビューがされていること
  • 開発者テストをパスすること
  • ステージング環境で動作に問題がないこと
  • プロダクトオーナーに承認されていること(該当する場合)

ウェブアプリケーションであれば、リリース後に問題があれば、すぐにロールバックすることができます。『テストから見えてくるグーグルのソフトウェア開発』という書籍には「バグの寿命は、数ヶ月から数分に短縮された」とあるほどです。

私たちは、バグを出さないために厳重な完了条件を定めてリリース回数を減らすよりも、スピード感をもってリリースし、サイトを改善していけるような方針で完了条件を定めています。それが結果として、ユーザー価値をふやすことにつながると考えているからです。

プロセスを定義し、自動化する

完了条件を定義したら、それをプロセスに落とし込みます。それから、そのプロセスを可能な限り自動化します。みんなのウェディングでは、継続的インテグレーションのためのサービスであるCircleCIが、その主要な役割を担っています。

プログラマが開発をしたソースコードは、GitHub上のプルリクエストとして提出されます。プルリクエスト単位で継続的インテグレーションによるテストが行なわれるのと同時に、開発者によるコードレビューが行なわれます。

この両方で問題がなかったソースコードは、masterブランチにマージされ、再び継続的インテグレーションによるテストが実行されます。

CircleCIでは、次のような自動化が行なわれています。

  • 静的検査ツール(RuboCophaml-lint)によるコーディング規約の検査
  • セキュリティスキャナ(Brakeman)によるセキュリティ検査
  • RSpecによる開発者テスト
  • CSSやJavaScriptなどのアセットの生成
  • AWS CodeDeployによるステージング環境へのデプロイ(masterブランチのみ)

ステージング環境で目視による動作確認を行ない、問題がないことが確認できたら、いよいよリリースです。

リリースは、Slackでボットに話しかけることで行ないます。Slackのボットが、CodeDeployのAPIにリクエストを送ることで、デプロイのプロセスが実行されます。

まとめ

今回は、みんなのウェディングの継続的デリバリーの仕組みについて説明をしました。

開発者からみると、コードレビューで問題がなかったプルリクエストをマージするだけで、ステージングサーバーに開発したコードがデプロイされることになります。リリースもチャットで発言するだけです。

継続的デリバリーで重要なことは、ソースコードがリリースされるまでのプロセスを定義し、それを可能な限り自動化することです。自動化することで、抜け漏れのない検査が可能となり、品質とスピードを両立させることができるようになります。

継続的デリバリーは、ユーザー価値を追求するサービス開発にとって、欠かせないプラクティスです。


みんなのウェディングは、ソフトウェアエンジニアを心から猛烈に募集中です。興味のある方は、 Wantedlyからご応募ください。もちろん、社内の人間と面識があるのでしたら、直接にご連絡いただいてもかまいません。