継続的なデプロイの始め方

このガイドでは、継続的なインテグレーションと継続的なデリバリーのワークフローがすでに実施されており、次のステップは継続的なデリバリー パイプラインを設定すると仮定します。

Sten Pittet Sten Pittet

Bitbucket Pipelines での継続的なデプロイを開始する方法のチュートリアルもご確認ください。

もうリリースするところだ、本番環境には手を触れるな!

そのフレーズはおなじみかもしれません。本番環境へのデプロイはリスクが高く、コストのかかる作業であり、時にはすべての開発を保留する必要があります。これによって、リリース サイクルが遅くなって開発環境で変更が停滞します。リポジトリへのコミットが多くなるほど、本番環境に導入される次のデプロイのリスクが増えます。結果として、チームがそのリリースを行う可能性が低くなるという、厄介な (そして危険な) 循環が始まります。

継続的デプロイはメインリポジトリにプッシュされたあらゆる変更を自動的に本番環境にリリースすることでこれらの問題を解決します。リリースの準備と管理に何日も費やす方法とは異なる先鋭的なアプローチですが、継続的デプロイにはいくつかのメリットがあります。

  • リリースは小規模になって、わかりやすくなります。
  • すべてが自動化されているため、デプロイを行うために作業を中断する必要はありません。
  • 顧客とのフィードバック ループは迅速になります。新機能と改善は、準備ができたら本番環境に即実装されます。

承認されたリリースから継続的なデプロイに移行するのは困難な場合がありますが、このガイドがその移行をサポートします。基礎を理解することで、一刻も早く開始できるとともにリリース サイクルを加速できます。

継続的なデプロイと継続的なデリバリー

継続的なデプロイ パイプラインを実装する場合は、継続的なデリバリーから始めるのが最適です。これら 2 つのプラクティスは似ていますが、本番環境のデプロイへのアプローチが異なります。継続的なデリバリーでは、メイン リポジトリにプッシュされたすべての変更をリリースする準備ができていますが、本番環境のリリース プロセスには依然として人間による承認が必要です。継続的なデプロイでは、テスト スイートに合格した変更ごとに、本番環境へのリリースが自動で実行されます。

継続的なデリバリーと継続的なデプロイの比較

変更を本番環境に自動でリリースする前に、優れた継続的なインテグレーション (CI) 文化が必要になります。継続的なデリバリーを最初に開始することを強くお勧めします。2 つのプラクティスの詳細については、以下の記事をお読みください。

継続的なデリバリーから継続的なデプロイへ移行する

継続的なインテグレーションの文化を強調する

継続的デプロイの中核にあるのは偉大な CI 文化です。テストスイートの品質がリリースのリスクレベルを決定し、チームは開発工程においてテストの自動化を最優先に行う必要があります。これは、リリース後に発見されたリグレッションに対する追加テストに加え、すべての新規機能にテストを実装することを意味します。

メイン ブランチの壊れたビルドを修正することも、リストの最初に置く必要があります。そうしないと、継続的なデプロイの導入前に直面したリスクと同じリスクに晒されます。変更は開発環境に蓄積されて、開発者は変更が受け入れテストに合格したかどうかわからないため、作業が完了していることを確認できません。

優れたテスト カバレッジ (と優れたテスト!) を持っていることを確認する

テスト カバレッジ ツールの使用を開始して、アプリケーションが適切にテストされていることを確認します。80% のカバレッジを目指すのが好ましいです。

優れたカバレッジを優れたテストと間違えないように注意してください。実際にコードベースに挑戦していないテストで、100% のテスト カバレッジを持つ可能性があります。コード レビュー中にテストがどのように作成されているか確認して、ためらわずにカバレッジ テストやウィーク テストのギャップを指摘してください。テスト スイートは本番環境への扉として機能して、強力な本番環境を作成します。

リアルタイム監視を導入する

すべてのコミットを自動的に本番環境にデプロイするなら、問題が発生したときに警告を発信してくれる優れた仕組みが必要です。新しい変更がすぐに本番環境を壊さなかったとしても、それが CPU やメモリー消費を危険なレベルに引き上げる原因となる場合があります。そのため、本番環境のサーバーにリアルタイム監視機能を実装すると、指標の異常を追跡することができて便利です。

Nagios といったツールや New Relic のようなサービスは、基本的なパフォーマンス指標を追跡して、システムに障害があるときはいつでも警告します。

デプロイ後のテストを確認する

本番環境にデプロイするたびに、簡単なスモークテストを実施して、アプリケーションが稼働していることを確認します。

これらのテストは、単に静的ページを見つけて成功の応答を待つよりも効果があることを確認します。優れたプラクティスとして、すべての本番環境サービス (データベース、マイクロサービス、サードパーティなど) が正常に動作しているというテストを行うことをお勧めします。

QA チームに上流の作業をしてもらう

あらゆるコミットが本番環境に直行するようになるため、QA チームが新機能をレビューして承認するための従来のバッファーがないことを意味します。代わりに、プロダクト マネージャーや開発チームと緊密に協力して、新しい改善に伴うリスクを定義する必要があります。

時間の経過とともにリリースの品質を向上させるため、これは QA チームにとって絶好の機会です。継続的なデプロイでは、チームは自然とコードベースのテスト カバレッジが良好になる傾向があります。そうでないと、バグによる頻繁な中断が本番環境に発生して、ユーザーにより中断が検出されることになります。

従来のリリース ノートをやめる

継続的なデプロイによって、リリースと歩調を合わせるのが難しくなりますが、それは良いことです。1 日に複数のデプロイであっても、本番環境へ日々のデプロイを持つことが目標です。バグ修正、小規模な改善、新機能など、どんなものでも構いません。開発者が作業を完了するとすぐに、その作業はほんの数分で本番環境で実行しているはずです。

この新しい世界では、もはや新しいバージョンごとに顧客に送信されるリリース ノートを作成できなくなります。代わりに、この新しいフローを取り入れて、発表する内容は顧客にとって重要な主要機能に制限してください。バグ レポートや小規模な改善リクエストは、チケット管理システムで簡単に処理できます。たとえば、Jira は、チケットを閉じるか更新するとすぐに、チケットのすべてのウォッチャーを更新できます。

新しいプロジェクトの別アプローチ: 本番環境にデプロイしてからコーディングする

まったく新しいコードベースを使い始めると、面白いことができるようになります。顧客や機能を準備する前に、(テスト駆動開発とは異なり) 継続的なデプロイのパイプラインを作成することから始められます。最初は、空のプラットフォームをリリースすることになります。その後、開発が進むにつれて新しい機能が自動で出始めます。本番環境は、顧客向けに公開する準備が整うまで非公開にしておくだけです。

このアプローチは、最初は直感的ではないように思われるかもしれません。しかし、手作業によるリリース承認から本番環境への継続的なデプロイまで、ストレスを解消する簡単な方法です。また、継続的なデプロイに必要な条件であるため、開始時に良好なテスト カバレッジと継続的なインテグレーション文化を確保するためのこの上ない方法です。

知識を積み上げて、経験を共有しましょう!

思い切って継続的なデプロイに切り替えるのは、当然難しいものです。突然、ゲートが開いて、数分または数時間でコードが顧客に直行します (うわあ!)。そのため、ビルドに自信を与えるテストや自動化に投資することが重要です。コードベースが新しい場合は簡単ですが、複雑なレガシー コードベースに異なる戦略を採用する必要があるかもしれません。

小規模から始めて、継続的なデプロイに関する知識と経験を構築します。あるプロジェクトでそれに到達すると、組織の他の部分で成功を簡単に再現できます。