継続的なインテグレーション、デリバリー、デプロイ
これらの継続的なプラクティスの違いについてご確認ください
Sten Pittet
寄稿ライター
CI と CD は、最新の開発プラクティスと DevOps で頻繁に使用される 2 つの頭字語です。CI は継続的なインテグレーションの略で、開発者が自動化されたビルドとテストを実行する中央リポジトリにコードの変更を頻繁にマージする、基本的な DevOps のベスト プラクティスです。しかし、CD は、継続的なデリバリーまたは継続的なデプロイを意味する場合があります。
継続的なインテグレーション、デリバリー、デプロイ (CI/CD) の相違点
継続的インテグレーション
継続的なインテグレーションを実践する開発者は、変更を可能な限り頻繁にメイン ブランチにマージして戻す必要があります。開発者による変更は、ビルドを作成してそのビルドに対して自動テストを実行することによって検証されます。そうすることで、リリース日を待ってリリース ブランチに変更をマージする場合に発生する可能性がある統合の課題を回避できます。
継続的なインテグレーションは、新しいコミットがメイン ブランチに統合されるたびにアプリケーションが壊れていないことを確認するために、テストの自動化を著しく重視しています。
継続的デリバリー
継続的なデリバリーは継続的なインテグレーションの拡張であり、ビルド ステージ後にテスト環境や本番環境にすべてのコード変更を自動でデプロイします。
つまり、自動化されたテストに加えて、自動化されたリリース プロセスがあり、ボタンをクリックすることでいつでもアプリケーションをデプロイできます。
理論的には、継続的なデリバリーでは、毎日、毎週、隔週、またはビジネス要件に合ったタイミングで、リリースするように決断できます。ただし、継続的なデリバリーのメリットを本当に活かしたい場合は、問題発生時に簡単にトラブルシューティングできる小規模なバッチをリリースできるように、できるだけ早く本番環境にデプロイする必要があります。
ソリューションを見る
Open DevOps によるソフトウェアの構築と運用
関連資料
DevOps パイプラインとは
継続的デプロイ
継続的なデプロイは、継続的なデリバリーを一歩先に進めたものです。この手法では、生産パイプラインの全段階を通過するあらゆる変更が、顧客にリリースされます。人手は一切不要です。新しい変更が本番にデプロイされないのは、テストに失敗した場合のみです。
継続的なデプロイは、「リリース日」がないため、顧客とのフィードバック ループを加速してチームの負担を取り除く優れた方法です。開発者はソフトウェアの構築に集中できて、作業が終了してから数分後に作業が稼働開始されます。
プラクティスの相互関連
簡単に言うと、継続的インテグレーションは継続的デリバリーと継続的デプロイの両方の一部です。継続的デプロイは継続的デリバリーと似ていますが、リリースが自動的に行われる点だけが異なります。
各プラクティスのメリット
What are the benefits of each practice?
継続的なインテグレーションとデリバリーとデプロイの違いを説明しましたが、これらを導入する理由についてはまだ見ていません。各プラクティスの実施には明らかにコストがかかりますが、メリットの方が遥かに上回ります。
継続的インテグレーション
必要なもの (コスト)
- チームは、新機能、改善、またはバグ修正ごとに自動テストを作成する必要があります。
- メインリポジトリを監視し、プッシュされたすべての新しいコミットに対して自動的にテストを実施する継続的インテグレーションサーバーが必要です。
- 開発者は可能な限り頻繁に (少なくとも 1 日 1 回)、変更をマージする必要があります。
得られるもの
- 自動化されたテストによって劣化が早期に捕捉されるため、本番環境にリリースされるバグは少なくなります。
- すべてのインテグレーションの課題が早期に解決されているため、リリースは簡単に構築できます。
- 開発者はビルドが中断するとすぐに警告され、次のタスクに移る前に修復作業を行うことができるため、コンテキストの切り替えが少なくなります。
- テストは大幅にコスト削減されます。CI サーバーは数百件のテストをほんの数秒で実行できます。
- QA チームによるテスト時間が短縮されて、品質文化の大幅な改善に集中できます。
継続的デリバリー
必要なもの (コスト)
- 継続的なインテグレーションには強力な基盤が必要であり、テスト スイートは十分なコードベースをカバーする必要があります。
- デプロイは自動化する必要があります。トリガーはまだ手動ですが、デプロイが開始されると、人間が介入する必要はなくなるはずです。
- 不完全なフィーチャーが本番環境の顧客に影響を与えないように、チームはフィーチャー フラグを採用しなければならない可能性が高くなります。
得られるもの
- ソフトウェアのデプロイの複雑さが解消されました。チームはリリースの準備に何日も費やす必要がなくなりました。
- より頻繁にリリースを実行できることから、顧客とのフィードバックループを加速できます。
- 小規模な変更の決定に対する負担ははるかに少ないので、より速い反復を奨励します。
継続的デプロイ
必要なもの (コスト)
- 最高のテスト文化が求められます。テストスイートの品質がリリースの品質を左右します。
- ドキュメント作成プロセスとデプロイのペースの足並みをそろえる必要があります。
- フィーチャー フラグは、他の部門 (サポート、マーケティング、広報など) と連携できるように、重要な変更をリリースするプロセスの本質的な部分になります。
得られるもの
- リリースの開発を一時停止する必要がないため、より速く開発できます。デプロイ パイプラインは、変更ごとに自動でトリガーされます。
- 小規模な変更のバッチをデプロイすると、リリースのリスクが低くなって問題発生時の修正が容易になります。
- 顧客は継続的改善のストリームを確認でき、品質が月、四半期、年単位ではなく毎日向上します。
継続的なインテグレーションに関連する従来のコストの 1 つに、CI サーバーの設置とメンテナンスがあります。しかし、あらゆる Bitbucket リポジトリに自動化を追加する Bitbucket Pipelines のようなクラウド サービスを使用することで、これらのプラクティスの導入コストを大幅に削減できます。リポジトリのルートに設定ファイルを追加するだけで、メイン ブランチにプッシュされる新しい変更ごとに実行される継続的なデプロイのパイプラインを作成できるようになります。
継続的なインテグレーションから継続的なデプロイまで
まだユーザーがいない新しいプロジェクトを始めたばかりの場合は、すべてのコミットを本番環境にデプロイするのは簡単かもしれません。デプロイを自動化することから始めて、アルファ版を顧客がいない本番環境にリリースすることさえもできます。次に、テスト文化を盛り上げて、アプリケーションを構築するにつれてコード カバレッジを増やすようにします。ユーザーのオンボード準備が整うまでに優れた継続的なデプロイ プロセスが可能になります。その場合は、新しい変更がすべてテストされてから、本番環境へ自動でリリースされます。
しかし、すでに顧客との既存のアプリケーションがある場合は、処理が遅くなって継続的なインテグレーションと継続的なデリバリーから始める必要があります。自動で実行される基本的なユニット テストを実装することから始めます。複雑なエンド ツー エンド テストを実行させることに集中する必要はまだありません。代わりに、できるだけ早くデプロイを自動化して、ステージング環境へのデプロイが自動で実行されるステージに移動する必要があります。自動デプロイを行うことで、リリースを調整するために定期的に作業を停止せずに、テストの向上に注力できるというのがその理由です。
日常的にソフトウェアのリリースを開始できたら、継続的なデプロイについて調べることができます。ただし、ドキュメント、サポート、マーケティングなど、組織の残りの部分も準備が整ったことを確認してください。これらの機能は、新しいリリース期間に合わせて調整する必要があり、顧客に影響を及ぼす可能性のある重要な変更を見逃さないことが重要です。
ガイドを読む
この記事を共有する
次のトピック
おすすめコンテンツ
次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。
DevOps コミュニティ
ブログを読む
