CI/CD のベストプラクティス

CI/CD のメリットはよく知られていますが、DevOps プロセスを最大限に活用するにはどうすればいいのでしょうか。

継続的インテグレーション、デリバリー、およびデプロイは、コードのビルド、テスト、およびリリースのプロセスを合理化します。これらのプロセスによって、従来の方法よりも迅速に機能する製品をユーザーの手元に届けることができます。自動ビルドパイプラインが適切に実行されると、チーム内で一貫して機能するソフトウェアを素早く提供し、最新の変更に対するフィードバックを即座に得られます。

パイプラインへの適用を検討すべき継続的インテグレーションとデリバリーのベストプラクティスを詳しく見てみましょう。

早期にコミット、頻繁にコミット

ソースコード、構成ファイル、スクリプト、および依存関係がすべてバージョン管理に保存されていることを保証することが継続的インテグレーションを実装するための基本の第一歩です。

ただし、バージョン管理システムだけでは不十分です。それをどのように使用するかが重要になります。継続的インテグレーションは複数の貢献者の変更をより簡単に導入することを目標としています。この手法では、コードの変更をコミットして共有する頻度を上げることが鍵となります。

具体的な仕組みを以下に示します。

各コミットによって一連の自動テストがトリガーされます。これによって変更に対する迅速なフィードバックを得られるため、バグに素早く対応できます。コミットを頻繫に行うほど、このフィードバックをより定期的に受け取れるようになります。
変更をチームと頻繫に共有することで、すべてのメンバーが同じ基盤に立てるようになります。これによってコラボレーションが促進され、大規模かつ複雑な変更を導入する際に生じるマージ競合のリスクを減らすことができます。
ブランチ戦略によってメインブランチ、専用のフィーチャーブランチ、指定された開発ブランチなどの変更のプッシュ先が決まります。
目安としては、チームの全メンバーが少なくとも 1 日 1 回は各自の変更をコミットして共有することを目指してください。

最初のハードルを克服する

最初のうちは他人の目を気にしたり 1 日の許容量を超える数のタスクを処理することへの恐怖心があり、頻繁にコミットすることに居心地の悪さを感じるかもしれません。チーム内で批判し合うのではなく、コラボレーションの文化を育む必要があります。作業方法を変える際は、チームとしてどのように行動するのが効果的かを話し合いましょう。タスクをより管理しやすいサイズに細分化することで、それぞれのメンバーがその作業方法を受け入れやすくなります。

ビルドを青信号に維持する

継続的にリリース可能なコードベースを維持すれば、CI/CD 手法を最大限に活用できるようになります。この手法によって発生したばかりのバグにすぐに対応できるようになるため、効率が高まり、本番環境で何らかの問題が発生しても速やかに修正をリリースできるようになります。

自動テストとパイプラインのステージではコードのリリース可能であるかどうかについてのフィードバックを即時に得られますが、このベストプラクティスでは自動テストとパイプラインのステージが浮き彫りにする問題にどのように対応するかに焦点が当てられています。

問題を協働で解決する

チームは一致団結してビルドに責任を負い、不具合が発生した場合は迅速な解決を優先させる必要があります。変更を行った最後の開発者を責めるのではなく、協働して問題の解決に取り組み、CI/CD ワークフローを強化して継続的な改善の後ろ盾となる建設的な文化を育む必要があります。これは特にプレッシャーのある状況では重要です。

些細な失敗を防ぐ

構文ミスや依存関係の欠落などの単純なエラーによってビルドが失敗するリスクを減らすため、チームメンバーは自分の変更を共有する前に最初のテストをローカルでビルドして実行する必要があります。無駄な労力を避けるため、全員が CI/CD システムと同じスクリプトを使用するようにしましょう。

ビルドは一度限りにする

よくあるミスとして、CI/CD パイプラインのステージごとに新しいビルドを作成するというものがあります。異なる環境ごとにコードを再ビルドすると矛盾のリスクが発生し、以前に行ったすべてのテストが合格するかどうか確証を持てなくなります。

そのため、同一のビルドアーティファクトをビルドパイプラインの各ステージに進めながら、最終的にライブにリリースするようにする必要があります。

システムに依存しないビルドを維持する

変数、認証パラメーター、構成ファイル、またはスクリプトをビルド自体に組み込むのではなく、これらをデプロイスクリプトから呼び出すことで、システムに依存しないビルドを維持しましょう。

ビルドアーティファクトのバージョン管理と保存を一元化する

ビルドアーティファクトをソースコードの成果物として扱いましょう。ビルドアーティファクトはソース管理システムではなく、Nexus などの集中型アーティファクトリポジトリでバージョン管理と保存を行ってください。

デプロイを自動化する

CI サーバーを使用して同一のビルドアーティファクトを各テスト環境にデプロイする作業を自動化しましょう。アーティファクトがステージを進むたびに、チームがその信頼性により自信を持てるようになります。

テストを合理化する

CI/CD はソフトウェアの品質を保証する上で自動テストに大きく依存していますが、どんな場合でもテストしなければならないということではありません。

テストカバレッジとパフォーマンスの適切なバランスを得ることが重要です。テスト結果を得るのに時間がかかりすぎると、各人がそのプロセスを回避するか手早く片付ける口実と手段を探すようになります。

階層化されたテストカバレッジを採用する

ユニットテストに始まり、統合またはコンポーネントテストに至る自動テストのカバレッジを複数の階層内に構築しましょう。

迅速なフィードバックを優先する

できるだけ早くフィードバックを得るため、すぐに完了するテストを先に実行しましょう。通常、最速で実行できるのはユニットテストです。

並列テストを検討する

さらに素早く結果を得るため、テストをバッチに分割して並列実行することを検討しましょう。

より長いテストに徐々に移行する

より長いテストは比較的早く完了するテストに合格し、ビルドに自信を持てるようになった場合にのみ実行するようにしましょう。

人力による QA の実施を制限する

人力による品質保証に要する時間とチームの対応能力を考慮すると、このフェーズはすべての自動テストが正常に完了するまで制限するのが最善です。

より高いレベルのテストに専念する

すべての結果を確認するのに長時間を要するテストを実行しないようにしましょう。低レベルのテストでカバレッジを広げることを優先し、より高いレベルのテストを製品やユーザーに固有のリスクの高い部分に集中させましょう。

環境をクリアする

本番前環境を長時間稼働し続けると、元の構成とその環境間で設定が矛盾する可能性があります。この構成のずれが原因でテスト結果に一貫性がなくなり、CI/CD プロセスが損なわれる可能性があります。

パイプラインを実行するたびにテスト環境とステージング環境をリフレッシュするのがベストプラクティスであり、そうするだけの価値があります。

コンテナーか仮想マシンを使用する

テスト環境は素早くリフレッシュできるようにするため、コンテナーか仮想マシンでホストしましょう。

インフラストラクチャのコード化手法を使用する

環境の作成と破棄のプロセスをスクリプト化しましょう。その後、これらのステップを CI/CD サーバーから自動化できます。

拡張性を考慮する

環境の作成をスクリプト化することで、CI/CD プロセスを拡張したり複数のパイプラインを同時実行したりするのが容易になります。

静的環境を避ける

複数の静的環境を使用する場合、個々の環境を保守して構成のずれを防ぐ必要性が生じます。これにより、QA プロセスが鈍化してリリースに遅れが生じる可能性があります。

パイプラインを保護する

CI/CD パイプラインはコードと本番環境にデプロイするための資格情報へのアクセスを提供するため、攻撃者にとって格好の標的となっています。そのため、CI/CD プロセスにはセキュリティのベストプラクティスを適用することが不可欠です。

バージョン管理へのアクセス: バージョン管理リポジトリへのアクセスをセキュリティで保護し、コントリビューターに多要素認証の使用を要求しましょう。第三者による変更の提供を許可する場合は、ビルドをトリガーする前にその変更をレビューするプロセスを設けましょう。
資格情報の管理: CI/CD パイプラインのサービスと環境にアクセスする場合、資格情報と API キーが必要になるのが一般的です。絶対にソースコードに資格情報を保存しないでください。代わりに専用のシークレットストアを使用し、資格情報がログやビルドアーティファクトに入り込んでいないことを確認してください。
依存関係のチェック: 継続的インテグレーションのチェックの一環として、サードパーティの依存関係に既知の脆弱性が含まれていないことをチェックしましょう。
セキュリティで保護された通信: CI サーバーとビルドマシン間の通信をセキュリティで保護し、すべてのマシンが最新のパッチで更新されている状態を維持してください。
最小権限の原則: 最小権限の原則をパイプライン全体に適用しましょう。これにより、アカウントが侵害された場合に攻撃者がアイランドホッピング攻撃を行うのが難しくなります。
変更の管理: 変更が適用前にレビューされるよう、パイプライン構成に変更の管理を導入しましょう。

プロセスを堅持する

CI/CD 戦略に投資してリリースに自信を持てるような信頼性の高いパイプラインを構築したら、個々のメンバーがそのプロセスを回避したせいでその労力が無駄になるのは避けたいものです。

小さな変更や緊急の変更を行う場合は CI/CD プロセスを回避したくなるものです。しかし、以下のいくつかの理由により、譲歩しないことが重要です。

自動品質保証の段階を省略すると、省略しなければ検出されていたはずのバグが入り込む可能性があります。
テストに使用できるビルドがない場合、本番環境に入り込んだ問題を再現してデバッグするのは難しくなります。
「緊急」リリースの問題を診断して修正するのは、通常の自動プロセスを通過する場合よりも時間がかかります。

プロセスの回避を求められた場合は、時間をとって CI/CD パイプラインのメリットを説明しましょう。また、既存プロセスを部分的に改善できないかどうかを問うことにも価値もあります。

パイプラインを監視して評価する

パイプラインのセットアッププロセスの中では、本番環境（製品）の監視も導入します。

CI/CD パイプライン自体にも同様の形式の監視をセットアップするのがベストプラクティスです。

CI/CD のメトリクスを解析する

CI/CD ツールが収集したメトリクスを使用することで、潜在的な問題と改善の余地を特定しましょう。

ビルドの頻度を監視する

毎週、毎日、または毎時間トリガーされるビルドの数を比較し、パイプラインインフラストラクチャの使用パターンを把握しましょう。このように監視することで、拡張やピーク負荷時間の特定が必要かどうかを判断できます。

デプロイの速度を追跡する

デプロイの速度を経時的に追跡してさまざまな傾向を明らかにし、パフォーマンスの最適化に投資すべきタイミングを判断しましょう。

自動テストからインサイトを得る

自動テストの統計を使用して並列化を活用できる部分を特定しましょう。

QA の結果を確認する

日頃無視されている QA 結果を特定し、テストのカバーを効率化できそうな部分を確認しましょう。

チームワーク化する

CI/CD ワークフローの作成が成功するかどうかは採用するプロセスとツールだけでなく、チームと組織の文化にもかかっています。

継続的インテグレーション、デリバリー、およびデプロイは DevOps の中核をなすプロセスです。その目的は開発者、QA エンジニア、および運用部門を隔てるサイロを解消し、これらの分野間でのコラボレーションを促進することです。これらの DevOps のベストプラクティスを採用することで、さまざまなメリットを得られます。

見える化とコラボレーションの促進

チームメンバーはワークフロー全体とコラボレーションの機会を全体的に把握し、さまざまな分野の専門知識を活用できます。

責任の共有

パイプラインの管理責任を共有することで、1 人が単一障害点になるのを防ぐことができます。

奨励と貢献

ソフトウェア配布の責任共有を奨励することで、チームメンバー全員がビルドの修正、タスクの自動化、プロセスの改善などにより貢献できるようになります。

信頼文化の醸成

チームメンバーが実験しながらアイデアを共有できるような信頼文化を促進することは組織にメリットをもたらし、提供するソフトウェアの改善につながります。

問題が生じた場合はそれを学習の機会とし、より堅牢で効果的な CI/CD 手法を得ることができます。

CI/CD のベストプラクティスに従う理由

継続的インテグレーション、デリバリー、およびデプロイのベストプラクティスに従うことで、さまざまなメリットを得られます。

提供の迅速化

ビルド、テスト、およびデプロイのタスクを自動化することで、リリースプロセスを高速化できるため、ソフトウェアの更新をより迅速に提供できます。自動 CI/CD は市場投入までの時間を短縮し、機能をユーザーへ速やかに提供する上で欠かせません。

定期的なフィードバック

変更のデプロイ頻度を上げることで、ユーザーから定期的にフィードバックを得られます。インサイトを利用して計画を練り直し、戦略を調整できます。

コード品質の改善

自動 QA プロセスを採用すると開発サイクルの早い段階でバグを検出できるため、問題をより迅速に解決し、より品質の高いコードと強力なソフトウェアのサイクルに貢献できるようになります。

ユーザー満足度の向上

自動チェックによって個々の変更が一貫してチェックされるため、バグが本番に到達するリスクを最小限に抑えられます。その結果、ユーザーがより快適に利用できるようになり、ダウンタイムが発生する確率が大幅に減少します。

創作タスクに専念できる時間の増加

ソフトウェアのビルド、テスト、およびデプロイに伴う定型的な手順を自動化することで、チームメンバーが新機能の開発、革新的なデザインの作成、全体的な DevOps 手法の強化などの創作タスクに専念する時間を作ることができます。

CI/CD デプロイ戦略の導入方法

継続的インテグレーション、デリバリー、およびデプロイの導入は大変な作業に思われるかもしれません。 CI/CD 戦略を成功させるにはいくつかの重要な要素があり、長期にわたって強固な DevOps 文化を築く必要があります。

明確な目標を設定する

ソフトウェア開発プロジェクトと同様に、目標を定義し、それをチームに伝えることが重要です。

本番前環境への継続的デリバリーによってリリース周期を毎週にすることを目指すなり、ユーザーに迅速に更新を提供する継続的デプロイを推進するなり、明確な目標を設定することが不可欠です。

管理可能なサイズで作業する

目標を設定したら、その達成までに必要なステップを管理可能なサイズに分割しましょう。パイプラインを段階的に導入することで、CI/CD のメリットを最初から体験できます。

CI から始める

ほとんどのチームは継続的インテグレーションから始められます。 CI にはバージョン管理、ブランチ戦略、自動テストカバレッジの追加や拡大、ビルドとテストの自動化の開始といったタスクが伴います。 CI サーバーを使用することで、これらのアクティビティを調整し、テストの結果を収集して注意深く調べ、他の情報と比較して相違点を見つけ、後続のビルドステージとテストステージを自動化するロジックを実装しやすくなります。

CD に向けて移行する

自動 CI フローを組み込んだら、継続的デリバリーまたはデプロイへの移行を進めることができます。

環境の作成を自動化することで、長期的に時間を節約し、パイプラインの信頼性と堅牢性を高めることができます。その後、より多くの自動テストと手動テストを自動作成された環境で実行できるようになります。

データを解析する

導入中でも CI/CD 戦略を組み込んだ後も、CI/CD ツールのデータを解析し、チームメンバーと共にプロセスを改良する機会を発見することには価値があります。このような反復的な手法により、CI/CD を継続的に改善し、チームと組織にとってのメリットを最大化できます。

まとめ

これらの DevOps ベストプラクティスを採用することで、継続的インテグレーション、デリバリー、およびデプロイのプロセスを最大限に活用できるようになります。

コードの変更を頻繫にコミットする。それによって変更を取り込みやすくなり、自動ビルドとテストから作業に対する定期的なフィードバックを得られるようになります。
ビルドを青信号に維持する。コードベースをデプロイ可能な状態に維持することでコード品質が改善され、本番環境で発生した緊急の問題に確実に対応することができます。
ビルドは一度限りにする。同一のビルドアーティファクトをさまざまな環境を通して進めることで、コードがテストの各ステージを通過したことを確信できます。
自動テストを合理化する。自動テストでも実行には時間がかかります。最速でフィードバックを提供するテストを最初に実行してください。
パイプラインを実行するたびに環境をリフレッシュする。これによって構成のずれを回避し、CI/CD の各ステージの結果を確実に使用することができます。
パイプラインを保護する。ソースコードと本番環境にアクセスできる CI/CD パイプラインはハッカーにとって格好の標的となり得ます。CI/CD にはセキュリティを組み込むことが不可欠です。
プロセスを堅持する。些細な変更や緊急性の高い変更がある場合は CI/CD パイプラインを回避したくなることもありますが、多くの場合はそうすることによって長期的にコストが高くつくことになります。
パイプラインを監視して評価する。パイプラインのデータを解析することで、より堅牢で効率的なパイプラインにすることができます。
プロセスをチームワーク化する。パイプラインは 1 人で管理すべきものではありません。 DevOps の考え方を採り入れると、さまざまなメリットを得られます。

TeamCity のメリット

TeamCity は CI/CD パイプラインのビルドと拡張を支援するために設計された CI/CD 自動化プラットフォームです。 TeamCity は既存のビルドとテストの自動化レベルに関係なく簡単に使い始めることができます。

すべての主要バージョン管理システムに対応する広範な統合、一般的なビルドおよびテストフレームワークのサポート、および直感的なウェブベースの UI が備わっているため、最初のパイプラインを数分で作成できます。構成のコード化をフルサポートしているため、UI からすべてのパイプラインの定義を生成し、バージョン管理システムに保存することができます。

TeamCity はその高い拡張性と優れた性能を実現する設計のおかげで自動テストからフィードバックを迅速に得られるだけでなく、主要 IDE とメッセージングプラットフォームと統合可能であるため、作業場所に関係なく通知を受信できます。広範なセキュリティ機能により、ソースコードとパイプラインを攻撃者から安全に保護することができます。

プロセスの成熟に合わせて TeamCity に組み込まれたテストカバレッジレポート、不安定なテストの特定、およびビルドエージェント統計を活用し、CI/CD プロセスを継続的に最適化できます。