継続的インテグレーション、デリバリー、デプロイメントの違い

継続的インテグレーションは、従来的に「インテグレーション」中に少しずつ頻繁に行われていたステップを、コードが完成してからすべてを集めてテストするのではなく、開発プロセス全体で実行する手法です。

ソフトウェア製品に携わる人員は複数いると仮定した場合（ほとんどの商用ソフトウェアやオープンソースソフトウェアでは普通です）、ある時点で、各開発者が担当していた部品を合わせて、最終的な結果が目標通りに動作することを確認する必要があります。 継続的インテグレーションの場合、このプロセスは1日に少なくとも1回発生します。

その理由は単純です。 すべてのコードが記述されてからインテグレーションを実施する場合、ソリューションをビルドする上でコードをセクションごとに解いて書き直し、意図したとおりに動作するための作業に膨大な時間を費やさなければいけなくなる可能性が十分にあるからです。 コードは複雑です。 あらかじめ詳細に設計していた場合でも、ロジックが実際にどのように相互作用するのか予測して、あらゆる課題を回避することは非常に難しいのです。 コードの量が多いほど、複雑さも高まるため、何かが動作しない場合にはさらに多くのセクションを確認しなくてはなりません。

継続的インテグレーションでは、開発者は変更をソースコントロールに定期的（1日1回など）コミットすることで共有し、ソリューションが正しくビルドされ、テストに合格していることを確認することができます。 つまり、何らかの障害が発生した場合は、問題の原因を特定するために、はるかに少ない数の変更を確認すればよいのです。 フィードバックを素早く、作業内容の文脈を覚えている間に得られることも、課題の修正がより簡単に行えることにつながります。

適切なCIプロセスには、次のようないくつかの基本要素が必要です。

上記のすべての要素を採り入れることで、コードに対するフィードバックを素早く敵的に得られるようになります。 バグ修正や新機能または一部のリファクタリングにせよ、コードベースへの変更から少なくともテストに合格するクリーンなビルドを得られるようにしておけば、不良の土台に新しい作業を構築して作業のやり直しをやむなくされることを回避できます。 継続的インテグレーションを独自に実装することが、正しく動作するソフトウェアをユーザーに提供するプロセスを加速させる大きな第一歩です。

継続的デリバリーは、継続インテグレーションで確立したビルドとテストの自動化を基礎に構築されます。

継続的デリバリーでは、ソフトウェアのビルドを本番にリリースするために手動で行っていたステップを自動プロセスで行います。

以前は、開発者からテスター、そしてテスターからリリースマネージャーへとハンドオフされていましたが、継続的デリバリーでは、チーム（さまざまな分野からの参加者が含まれることがあります）が製品のビルド、テスト、そしてリリースの全プロセスを所有することになります。 これには、次のようないくつかのメリットがあります。

• 従来のサイロ方式を避けることで、開発チームが、製品をユーザーに提供する際のビジネスやオペレーションのニーズをより理解できるようになります。
• このため、通常は手動で、多くの場合に非常に長期的であったプロセスに開発手法を取り入れる機会が生まれます。
• 製品をライブにするために伴うステップを自動化することで、プロセスを加速できるだけでなく、エラーのリスクを軽減し、より安定性のある信頼の高い製品にすることができます。

ソフトウェアをユーザーに提供する際に伴う実際のステップ、そしてデリバリーパイプラインで必要となるステージは、ビジネスとユーザーのニーズによって異なりますが、製品がリリースされる前に、少なくとも1つの本番前環境にデプロイするのが一般的な手法です。

こういった環境は、セキュリティテスト、負荷テスト、およびパフォーマンステストなどの追加のテストレイヤー用のテスト環境であったり、サポートチームや営業チームが新機能を習得するためのサンドボックス環境であったり、QAや製品担当者が変更が意図されたとおりに動作するかを確認する承認テスト環境であったりします。

継続的デリバリーでは、正しく機能するそれぞれのビルドは、それぞれの本番前環境に自動的にデプロイされ、各ステージで品質が高まることを確信することができます。

これは、手法に投資する必要のある価値の高い目標です。

継続的デリバリーでは、ソフトウェアの提供に関する責任はチームにあり、全プロセスを通じて適時に提供されるフィードバックを活用するのもチームです。 継続的インテグレーションと同様に、この手法も長期的に構築して改善していくことができます。

継続的デプロイメントは、継続的インテグレーションとデリバリーの論理的な最終作業として、

ビルドがパイプライン内の前のステージをすべてクリアしていれば、自動的に本番にリリースします。 つまり、ソフトウェアへの変更がすべてのテストに合格すれば、ユーザーに提供されることになります。 継続的デプロイメントは、変更の品質を妥協することなく実世界での動作に関する情報を適時にチームに提供することで、コード変更から本番での使用までのフィードバックループを短縮することができます。

すべての製品や組織でソフトウェアを本番にデプロイするプロセスを自動化することが適しているとは限りませんが、個々の要素にはそれぞれの有効性があるため、それを達成するまでに必要なステップを検討する価値はあります。

継続的インテグレーション、継続的デリバリー、および継続的デプロイメントはすべて、価値の高い機能ソフトウェアをユーザーに頻繁に提供する目標を達成する手段です。 インテグレーションとリリースを少しずつ頻繁に行えば、プロセスをさらに管理しやすくなります。このステップを定期的に実行することで、チームはプロセスに徐々に慣れていくでしょう。

プロセスに自動化を含めると、プロセスを加速させられるだけでなく、信頼性も高まります。 パイプラインの各ステップは前のステップを土台にビルドされるため、ある特定の時間にどれくらいの期間を設け、後でビルドしていくのかを決めることができます。