CI/CD ツールの役割とその仕組み
DevOps と CI/CD は、ソフトウェアチームが品質を維持しながら製品を一早くユーザーに提供できるようにすることを目的としています。
CI/CD ツールは、コミットに続くプロセスの開始から、ビルドの管理、自動テストのトリガー、アーティファクトの公開、フィードバックの照合と伝達まで、パイプラインのさまざまなステージを調整・自動化し、CI 管理における中心の役割を果たします。
CI/CD パイプラインの実装では、組織に適した継続的インテグレーションまたは継続的開発/デリバリーツールを選択することが鍵となるため、留意が必要な主な考慮事項をここにまとめました。
統合オプション
The job of your CI/CD tool is to coordinate activities between a whole host of systems, including version control systems (e.g. Git, Mercurial or Perforce), build tools (e.g. Ant, Maven or Gradle), automated testing frameworks (e.g. NUnit or JUnit), package managers (e.g. NuGet), issue trackers (e.g. Jira, YouTrack or Github) and container platforms (e.g. Docker).
CI/CD パイプラインの構築に関して言えば、どのようなケースにでも適用できるアプローチは存在しないため、機能をニーズに合わせて拡張できるように、ビルトインのサポート、サードパーティプラグイン、API など、ツールに統合できるさまざまなオプションを準備しておくことが不可欠です。 このような柔軟性を備えておけば、将来的に組織内のほかのチームに CI/CD プラットフォームを拡張しやすくなります。
技術スタックのサポート
どのような継続的インテグレーションソリューションツールを選んでも、それが現在使用しているプログラミング言語、プラットフォーム、およびフレームワークをサポートしていることが必要です。また、将来的に新しいものを採用できる余地を残しておくことも必要です。 活発に開発・サポートされているツールであれば、新たなトレンドをサポートできるように更新される可能性があります。
全員が使えるインターフェース
CI/CD ツールの基本ユーザーは開発者であるかもしれませんが、DevOps 手法の重要な側面は、さまざまな役職のサイロを取り壊し、チーム間のコラボレーションを促進することです。
DevOps カルチャを念頭に設計された継続的インテグレーションを実装するツールであれば、これを支える複数のインターフェースを提供することができます。 コマンドラインインターフェースと API によって、プログラム的にシステムと統合できるようにし、 同時に、入念に設計された GUI によって、プロダクトマネージャーやサポートチームなど、誰もが最新のビルドのステータスやパイプラインを通じて何が渡されてくるのかを把握しやすくすることができます。
カスタマイズ
CI/CD パイプラインには標準的な設計はないと言いました。また実際に、時が経つにつれ、パイプラインの複雑性は増していくことがほとんどです。 パイプラインには複数の経路があることが一般的で、中には前の条件が満たされた場合にのみ含まれるステージもあります。
ブランチ作成のロジック、依存関係、および条件が構成しやすければ、個別のパイプラインインスタンスを多数作成して個別に管理する必要のない複雑なワークフローを実現できます。
フィードバック
CI 管理の中心には、パイプラインの各ステージから迅速に結果を戻せるフィードバックループが存在します。 継続的インテグレーションツールはそのフィードバックを使ってパイプラインロジックの状態を解決し、ダッシュボードなどを使ってその情報をユーザーに表示します。
メール通知や IDE またはコミュニケーションプラットフォーム（Slack など）との統合がサポートされていれば、ダッシュボードを確認せずに何が起きているのかを知ることができます。 受信するアラートの数が多すぎると、アラートがバックラウンドのノイズとなる可能性があるため、アラートの設定を変更できる柔軟性が備わっていれば便利です。
インフラストラクチャのオプション
一部のエンタープライズでは、コードベースをオンプレミスで維持することが絶対的な要件となっているため、パイプライン全体を独自のサーバーでホストできることも重要です。 一方、インフラストラクチャの管理をクラウドプロバイダーに任せることにも別のメリットがあります。
AWS、Microsoft Azure、Google Cloud などのパブリッククラウドプロバイダーをサポートする継続的インテグレーションを実装するツールであれば、必要に応じてビルドとテストアクティビティをスケーリングすることができるため、社内の追加インフラストラクチャをプロビジョニングしたり管理したりする際のオーバーヘッドがありません。
セキュリティ
CI/CD パイプラインは、ソースコードや環境パラメーターだけでなく、本番環境へのアクセスも提供してしまう可能性があります。これらが悪意のある人の手に渡ってしまえば、深刻なダメージにつながる可能性があります。
そのため、悪意のあるアクターからパイプラインを保護することが最優先されます。 これには、シークレットの安全な管理、最小権限の原則の適用（人間とマシンの両ユーザー）、および全パイプラインのアクティビティの監視が含まれます。 ツールは、異常な行動を調査できるように、監査証跡を提供できることも必要です。
パフォーマンス
自動 CI/CD パイプラインのメリットの 1 つは、製品の市場化時間を短縮することにあるため、CI/CD ツールのパフォーマンスが制約の要因となります。 タスクを並行化し、クラウドにホストされたインフラストラクチャの柔軟な拡張性を利用できる継続的インテグレーションソリューションであれば、パイプラインの進行速度を高く維持することができます。
メトリクス
CI/CD パイプラインは使用するにつれ進化し、より多くのタスクを蓄積し、より多くのプロジェクトを処理できるように拡張されていきます。 テストカバレッジや故障、ビルド期間やキューでの経過時間などの統計を監視することで、処理速度が低下しているパイプラインのエリアや再設計が有利となるステージを特定することができます。
Tools that give you access to a range of metrics and the option to generate reports or export them to other tools for analysis will make it easier to keep improving your CI/CD practice.
サポート
ソフトウェアツールを選択する際には、ドキュメントの品質や、質問やアイデア交換を行える活発な開発者コミュニティの有無を考慮することが重要です。
多くのエンタープライズでは、必要なときにメールやオンラインで問い合わせることのできる有料サポートオプションを、重大な市場化経路にある製品またはサービスの要件としています。
テストフレームワークのサポート
CI/CD テストツールは、継続的インテグレーションと継続的デリバリー/デプロイ（CI/CD）の手法をサポートするように特別に設計されたソフトウェアアプリケーションです。 これらのツールはテストとデプロイプロセスを自動化し、開発者が、コードベースへの変更が期待どおりに動作することをより簡単に素早く検証できるようにします。
CI/CD テストツールが組織で使用されているテストフレームワークをサポートしていることが重要です。
コスト
CI/CD プラットフォームのコストを比較した場合、ライセンス料はコスト計算の一部でしかありません。 使いやすさと利用できるサポートのレベルは、長期的に、パイプラインのセットアップと管理にかかる時間に大きく影響します。 将来的なスケールアップが予測される場合は、クラウドホスト型インフラストラクチャへの移行しやすさも考慮することをお勧めします。
まとめ
DevOps を実現するには 3 つの重要要素が必要だとよく言われています。カルチャ、プロセス、およびツール です。 組織に最適なビルドツールとデプロイツールを選択することで、CI/CD のメリットを実現し、ソフトウェア開発プロセスと CI 管理を進化・改善し続けることが可能となります。