継続的インテグレーションと継続的デプロイ
会社のインフラストラクチャを変更したりデプロイしたりする前に、継続的インテグレーション (CI) と継続的デリバリーまたはデプロイ (CD) の背後にある概念を確認して、何を構築する予定なのかを理解してください。 このユニットでは、CI/CD パイプラインの概要と、GitHub Actions で CI と CD を適用する方法について学習します。
CI と CD は、ソフトウェアの開発、テスト、デプロイのすべてのフェーズに継続的な自動化と監視を導入する運用プラクティスです。 開発者チームは CI と CD を使用して生産性を高め、新しいコードを既存のコード ベースに統合する際に発生する可能性のある問題を減らすことができるようにします。
継続的インテグレーション
CI/CD ツールが開発される前は、開発-テスト-デプロイ-テストのプロセス全体が手動で行われていました。 自動化されたテスト スイートはありましたが、それらは専門家のチームによって、手動で、または時間をスケジュールして、実行する必要がありました。
ソフトウェア開発者が直面した最も大きな課題の 1 つは、"マージ日" でした。 マージ日が設けられたのは、ほとんどのソフトウェア開発チームが、同じコードについて異なるソース管理ブランチで作業し、最小限のテストしか実施されていなかったためです。 マージ日には、すべてのコード変更がメイン ブランチに統合されました。 その結果、チーム メンバーのブランチがメイン ブランチにマージされて混ぜ合わされたときの統合の問題を解決するためだけに、丸 1 日を費やす必要がありました。
CI の重要な原則は、可能な限り頻繁に新しい変更をすべてメイン ブランチにマージし直すことです。 変更を継続的にマージすることで、多くの開発者が一度に変更を結合したときに発生していたマージ日の "統合地獄" を回避できます。
CI では、チームがコードの最小の変更を頻繁に実装して統合することが必要になります。 CI を実装することは、チームが運用環境でテスト、コンパイル、デプロイ、再テストを継続的に実行できることを意味します。 CI の目的は、メイン コード ブランチに影響を与えたり、顧客にデプロイされたりする前に、コード変更によって生じる運用環境の問題を検出して回避することです。
継続的デリバリーとデプロイ
"継続的デリバリー" は、CI が終了するところから始まり、選択されたインフラストラクチャ環境へのデリバリー プロセスを自動化します。 継続的デリバリーを使用して、変更を迅速かつ持続的にリリースできます。 継続的デリバリーを使用した後、変更を毎日、毎週、毎月、またはビジネス要件に合ったそれ以外のスケジュールのいずれでデプロイするかを前もって決定します。
"継続的デプロイ" は、CI/CD パイプラインのすべてのステージに合格した変更を運用環境に自動的にリリースすることで、さらに 1 歩進みます。 継続的デプロイは、ソフトウェア開発における最も高度なプロセスの 1 つであり、人間の介入なしにアプリケーションの機能のすべての側面をテストするコードが必要になります。
CI/CD パイプライン
パイプラインは、指定されたイベントの発生時に実行される集合的なプロセスで構成されています。 ソフトウェア開発には多数のイベントが含まれており、CI/CD パイプラインでは、関連するすべてのイベントがサポートされている必要があります。 あるイベントがパイプラインをトリガーすると、そのイベントに対するすべてのリスナーがトリガーされ、プロセスの最初のステージが開始されます。
CI/CD パイプラインは、新しいコード変更によってそれがトリガーされたときに実行されます。 ほとんどの場合、プロセスはソース コードのクローンまたはダウンロードによって開始されます。 その後、次のステップが順次トリガーされます。
コード変更によって CI/CD の実行がトリガーされるたびに、パイプラインのすべてのステップが実行されます。 あるステップでエラーが発生すると、パイプラインは停止します。 ワークフローにはロジック ジャンプを含めることができ、特定の条件下で一部のステージが実行されないようにしながら、全体的なパイプラインの実行を継続できます。
GitHub Actions
GitHub Actions は、GitHub 関連のすべてのイベントをサポートし、このモジュールの CI/CD パイプラインを自動化します。 GitHub Actions では、各ステップで JavaScript または Docker コンテナーを使用してアクションを定義します。 アクションは簡単に作成でき、パイプライン ステップの構成要素を形成します。
GitHub Actions を使用して、オートメーション ワークフローによって、GitHub でホストされているすべてのコードをシームレスに統合できます。 ワークフローは複数のタスクを処理して、複数の環境にわたってコードを統合します。
GitHub Actions は、オープンソース モデルであるため、CI/CD パイプラインのプロバイダーとして広く使用されています。 ワークフローはオープンソースであるため、プラットフォーム上のすべてのユーザーが利用できるリポジトリに格納されます。 GitHub ユーザーは、お互いのアクションを使用したり、独自のカスタム アクションを作成したりできます。これには、他に何もインストールしたり構成したりする必要はありません。
ユーザー間でアクションを共有できることは、繰り返されるコードやステージを書き直す必要がなく、既存のアクションを使用したりカスタマイズしたりできることを意味します。 次のユニットでは、Docker コンテナーで GitHub Actions を使用して、アプリケーションの継続的デプロイを実装する CI/CD パイプラインを定義します。