コードを開発、更新、または削除する際に、これらの変更をメイン コード ブランチに統合するための直感的で安全な方法を使用することで、開発者は価値を提供できます。
開発者は、小規模なコード変更を行い、その変更をコード リポジトリにプッシュし、品質、テスト カバレッジ、混入バグに関するフィードバックをほぼ瞬時に得ることができます。 このプロセスにより、より高い信頼度と少ないリスクで速い作業が実現します。
継続的インテグレーション (CI) は、ソース管理システムとソフトウェアデプロイ パイプラインを統合して、ソフトウェア開発チームに自動ビルド、テスト、フィードバックメカニズムを提供するプラクティスです。
継続的統合プロセスは、エンジニアが GitHub pull request を作成して、コード変更を統合する準備ができていることを CI システムに通知するときに開始されます。 理想的には、統合プロセスでは、コードを複数のベースラインとテストに対して検証します。 次に、これらのテストのステータスに関するフィードバックを要求元のエンジニアに提供します。
ベースライン チェックとテストが適切に行われると、統合プロセスによって、更新されたソフトウェアをデプロイする資産が生成され、ステージングされます。 これらの資産には、コンパイルされたコードとコンテナー イメージが含まれます。
継続的インテグレーションでは、次のアクションを実行することで、高品質のソフトウェアをより迅速に提供できます。
- コードに対して自動テストを実行して、破壊的変更を早期に検出します。
- コード分析を実行して、コードの標準、品質、構成を確認します。
- コンプライアンスとセキュリティチェックを実行して、ソフトウェアに既知の脆弱性がないことを確認します。
- 受け入れテストまたは機能テストを実行して、ソフトウェアが期待どおりに動作することを確認します。
- 検出された問題について迅速なフィードバックを提供します。
- 該当する場合は、更新されたコードを含む展開可能なアセットまたはパッケージを作成します。
パイプラインを使用して継続的インテグレーションを自動化する
継続的インテグレーションを実現するには、ソフトウェア ソリューションを使用してプロセスを管理、統合、自動化します。 一般的な方法は、継続的インテグレーション パイプラインを使用することです。
継続的インテグレーション パイプラインには、次を提供するソフトウェア (多くの場合、クラウドでホストされる) が含まれます。
- 自動テストを実行するためのプラットフォーム。
- コンプライアンス スキャン。
- レポート作成。
- 継続的インテグレーション プロセスを構成する他のすべてのコンポーネント。
ほとんどの場合、パイプライン ソフトウェアはソース管理にアタッチされるため、プル要求が作成されたり、ソフトウェアが特定のブランチにマージされたりすると、継続的インテグレーション パイプラインが実行されます。 ソース管理統合により、pull request 関する CI フィードバックを直接提供する機会も提供されます。
Azure Pipelines や GitHub Actions などの多くのソリューションは、継続的統合パイプラインの機能を提供します。
パイプラインをソース管理と統合する
継続的統合パイプラインとソース管理システムの統合は、迅速なセルフサービス コード コントリビューションを実現する鍵となります。
CI パイプラインは、新しく作成された pull request で実行されます。 パイプラインには、すべてのテスト、セキュリティ評価、その他のチェックが含まれます。 CI テストの結果は pull request に直接表示されるため、品質に関するフィードバックをほぼリアルタイムで得ることができます。
もう 1 つの一般的なプラクティスは、現在のビルド状態を表示するためにソース管理に表示できる小さなレポートまたはバッジを作成することです。
次の図は、GitHub と Azure DevOps パイプラインの統合を示しています。 この例では、プル要求の作成によって Azure DevOps パイプラインがトリガーされます。 パイプラインの状態が pull request に表示されます。
自動テストを組み込む
継続的インテグレーションの重要な要素は、開発者がコード コントリビューションする際の、コードの継続的な構築とテストです。 作成された pull request をテストすると、コミットによって破壊的変更が導入されていないというフィードバックが迅速に得られます。 利点は、継続的インテグレーション パイプライン内のテストが、テスト駆動開発中に実行されるテストと同じでよいことです。
次のコード スニペットは、Azure DevOps パイプラインからのテスト 手順を示しています。 この手順には、次の 2 つのタスクがあります。
- 最初のタスクでは、一般的な Python テスト フレームワークを使用して CI テストを実行します。 これらのテストは、Python コードと共にソース管理に存在します。 テスト結果は、test-results.xmlという名前のファイルに移動 します 。
- 2 番目のタスクは、テスト結果を使用し、統合レポートとして Azure DevOps パイプラインに発行します。
- script: |
pip3 install pytest
pytest azure-vote/azure-vote/tests/ --junitxml=junit/test-results.xml
continueOnError: true
- task: PublishTestResults@2
displayName: 'Publish Test Results'
inputs:
testResultsFormat: 'JUnit'
testResultsFiles: '**/test-results.xml'
failTaskOnFailedTests: true
testRunTitle: 'Python $(python.version)'
次の図は、Azure DevOps ポータルに表示されるテスト結果を示しています。
失敗したテスト
テストが失敗すると、展開が一時的にブロックされ、発生した内容が詳細に分析されます。 テストの失敗は、テストの改良や、テストの失敗の原因となった変更の改善につなげる必要があります。
ビルド状態を公開する
多くの開発者は、リポジトリにステータス バッジを表示することで、コードの品質が高い点を示しています。 次の図は、GitHub のオープンソース プロジェクトの readme ファイルに表示される Azure Pipelines バッジを示しています。
ビルド時間の最適化
より高速なビルドを実行するには、次の操作を行います。
パフォーマンス要件を満たすエージェントを選択する: 適切なビルド マシンを選択してビルドを高速化します。 高速マシンは、時間と分の違いを生み出すことができます。 パイプラインが Azure Pipelines にある場合は、Microsoft がホストするエージェントを使用してジョブを実行できます。 Microsoft がホストするエージェントを使用すると、メンテナンスとアップグレードが自動的に行われます。 詳細については、Microsoft ホステッド エージェントに関するページを参照してください。
ビルド サーバーの場所を最適化する: コードをビルドすると、ネットワーク経由でデータが送信されます。 ビルドへの入力は、ソース管理リポジトリと成果物リポジトリからフェッチされます。 コンパイル済みの成果物、テスト レポート、コード カバレッジの結果、デバッグ シンボルなど、ビルド プロセスからの出力をコピーする必要があります。 これらのコピー アクションを迅速に実行することが重要です。 独自のビルド サーバーを使用する場合は、ビルド サーバーがソースとターゲットの場所の近くに配置されていることを確認します。 高速アップロードとダウンロードにより、全体的なビルド時間を短縮できます。
ビルド サーバーのスケールアウト: 小規模な製品には、1 つのビルド サーバーで十分な場合があります。 製品のサイズとスコープ、および製品に取り組むチームの数が増えるにつれて、1 台のサーバーでは不十分な場合があります。 上限に達したら、インフラストラクチャを複数のマシンに対して水平方向にスケーリングします。 詳細については、「 エージェント プールの作成と管理」を参照してください。
ビルドを最適化します。
並列ジョブを追加して、ビルド プロセスを高速化します。 詳しくは、「並列ジョブの設定と支払いについて」をご覧ください。
並列テスト スイートの実行を有効にします。これは、多くの場合、特に統合テストと UI テストを実行する場合に、大量の時間を節約します。 詳細については、「 テスト ランナーに対してテストを並列で実行する」を参照してください。
乗数の概念を使用して、複数のビルド エージェントに対してビルドをスケールアウトできます。 詳細については、「パイプラインでジョブを指定する」を参照してください。
統合、UI、スモーク テストをリリース パイプラインに移動することを検討してください。 リリース パイプラインに移動すると、ビルド速度とビルド フィードバック ループの速度が向上します。
NuGet や Maven などのパッケージ管理ソリューションにビルド成果物を発行します。 パッケージ管理ソリューションに発行すると、ビルド成果物をより簡単に再利用できます。
ワークフローに合わせてビルドの種類を実装する
組織では、ビルド時間を最適化するために、いくつかの異なる種類のビルドを作成することを選択する場合があります。 考えられるビルドは次のとおりです。
継続的インテグレーション (CI) ビルド: このビルドの目的は、コードがコンパイルされ、単体テストが実行されるようにすることです。 このビルドは、コミットごとにトリガーされます。 プロジェクトのハートビートとして機能し、チーム im_imagestelyに品質フィードバックを提供します。 詳細については、「パイプラインをトリガーするイベントの指定」を参照してください。
夜間ビルド: 夜間ビルドの目的は、コードをコンパイルするだけでなく、ビルドごとに通常の周期で非効率的に実行される大規模なテスト スイートを保証することです。 通常、これらのテストには、統合、UI、またはスモーク テストが含まれます。 詳細については、「 パイプラインのスケジュールを構成する」を参照してください。
リリース ビルド: このビルドでは、コンパイルとテスト実行に加えて、API ドキュメントやコンプライアンス レポート、コード署名などが必要とされるケースがある、コードのビルドにおいて常に必要ではないその他の手順も含まれます。 このビルドは、最終的に運用環境にデプロイするためにリリース パイプラインにプッシュされるゴールデン コピーを提供します。
組織に必要なビルドの種類は、チームと組織の成熟度、作業中の製品の種類、デプロイ戦略などの要因によって異なります。
関連リンク
GitHub または Azure DevOps を使用して継続的インテグレーション パイプラインを作成する方法について説明します。
リポジトリにバッジを表示する方法について説明します。