CI/CD とは
リリースを加速するために自動ワークフローを構築する
CI/CD とは
CI/CD は、継続的インテグレーションと、継続的デリバリーまたは継続的デプロイを意味します。これは、ビルド、テスト、デプロイを自動化してソフトウェア開発プロセスを改善し、コードの変更をより迅速かつ確実にリリースできるように設計された、一連のプラクティスとツールです。
継続的インテグレーション (CI): 共有リポジトリ内でコード変更を自動的にビルドし、テストし、統合します。
継続的デリバリー (CD): 自動的にコード変更を本番にすぐに移行できる環境に承認のために提供します。
継続的デプロイメント (CD): コードの変更を顧客に自動的に直接デプロイします。
CI/CD は、継続的インテグレーションと、継続的デリバリーまたは継続的デプロイから構成されます。合体して、「CI/CD パイプライン」を形成します。これは、次のように DevOps チームが手動タスクを削減するのに役立つ一連の自動ワークフローです。
CI/CD パイプラインの例
継続的デリバリーと継続的デプロイ
CI/CD という場合、「CD」というのは通常、継続的デリバリーの意味で、継続的デプロイの意味ではありません。違いについて 継続的デリバリーを使用する CI/CD パイプラインでは、オートメーションは開発者が本番環境にプッシュしたときに一時停止します。最終リリース前に、人間 (運用チーム、セキュリティ チーム、またはコンプライアンス チーム) が手動でサインオフする必要があり、遅延が増加します。一方、継続的デプロイでは、リリース プロセス全体が自動化されます。コードの変更は、必要なテストをすべてパスするとすぐに、顧客にデプロイされます。
継続的デプロイは、DevOps オートメーションの究極の例です。これは CI/CD を行う唯一の方法や「正しい」方法であるという意味ではありません。継続的デプロイは厳格なテスト ツールと成熟したテスト カルチャーに依存しているため、ほとんどのソフトウェア チームは継続的デリバリーから開始し、時間が経つとともに統合する自動テストを増加させます。
CI/CD のメリット
簡潔な答え: 速度。State of DevOps レポートでは、CI/CD のデプロイを 208 倍の頻度で「マスター」した組織は、他の組織に比べてリードタイムが 106 倍速いことがわかりました。最もよく知られている CI/CD のメリットは開発の高速化ですが、継続的インテグレーションと継続的デリバリー パイプラインによってさらに多くのことが可能になります。
開発者のベロシティ: 進行中にフィードバックすると、開発者は 1 回のリリースを待たず、それより頻繁に小さな変更をコミットできます。
安定性と信頼性: 自動化された継続的テストによって、コードベースは常に安定していて、いつでもリリースできるようになります。
ビジネスの成長: 手動のタスクから解放されると、組織は、イノベーション、顧客満足、および技術負債の返済にリソースを集中できます。
当社では、常に自ら自動化してジョブを改善したいと考えています。現在手動で行っているタスクのほとんどが必ず自動化されるようにしたいと考えています。
エンジニアリング ディレクター、Andrew Mulholland 氏
CI/CD ツールキットをビルドする
チームは、自動化されたプロセス、ステップ、ツールを組み合わせて、CI/CD を開発ワークフローの一部とします。
バージョン管理: 継続的インテグレーション (CI) は、Git のようなバージョン管理システム (VCS) を使用してチームがコーディングのコラボレーションをしている、共有リポジトリの内部で開始されます。VCS はコードの変更を追跡し、その復旧を簡素化し、テスト実行とインフラストラクチャを管理するためのコードとしての構成をサポートします。バージョン管理の詳細情報
ビルド: CI ビルド ツールは自動的にファイルとコンポーネントをリリース アーティファクトにパッケージ化し、品質やパフォーマンスなどの必須要件についてテストします。必要なチェックをクリアしたら、CD ツールは、さらにテストしステージングするためにビルドを運用チームに送り出します。CI テストの詳細はこちら
レビューと承認: コード レビューをベスト プラクティスとして扱うことで、コード品質を改善し、コラボレーションを促進して、最高の経験を持つ開発者に対してもコミットする際の支援になります。CI/CD ワークフローでは、チームがコードのレビューと承認を行なったり、あるいはペア プログラミングのために統合開発者環境を活用したりします。コード レビューの詳細情報
環境:CI/CD は、運用チームがアプリケーションを一般公開する場所に開発者がコードをビルドする環境内で、コードをテストしてデプロイします。環境には、多くの場合、セキュリティとコンプライアンスの必須要件を満たすために、それぞれ固有の変数と保護ルールがあります。保護された環境についての詳細はこちら
CI/CD ワークフローの例
CI/CD は複雑である必要はなく、現在のワークフローに多数のツールを追加する必要もありません。mablでは、開発者は、mabl テスト スイートと GitHub Actions という 2 つの CI/CD インテグレーションのみを使用して、週に約 80 回本番環境にデプロイしています。仕組みは次のとおりです。 ✨
初期ビルドとユニット テストをトリガーするために開発者がプルリクエストを開く
承認されたコミットがプレビュー環境にデプロイされる
カスタムビルドの GitHub Actions が mabl CLI をインストールし、ヘッドレス テストを実行する
GitHub アプリケーションがプルリクエスト内にチェック結果をリアルタイムで提供する
承認されたコミットが、追加テストあるいは実稼働へのデプロイのために main ブランチにマージされる
CI/CD を成功させる要因
市場にはさまざまなツールやインテグレーションで溢れていますが、効果的な CI/CD ワークフローは全て、同じ成功の指標を有しています。
自動化: CI/CD は手動で行うことも可能ですが、これは目指すところではありません。適切な CI/CD ワークフローでは、ビルド、テスト、デプロイを自動化するため、コーディングに使用できる時間が増え、タスクは増えません。
透明性: ビルドが失敗した場合、開発者は誤りの内容と理由をすばやく判定できる必要があります。ログ、ビジュアルなワークフロー ビルダー、深く統合されたツールによって、開発者がトラブルシューティングし、複雑なワークフローを理解し、自分たちのステータスをチーム全体と共有することが容易になります。
速度: CI/CD は、DevOps の全体的なパフォーマンス、特にスピードに寄与します。DevOps のエキスパートは、次の 2 つの DORA メトリックを使用してスピードを測定します。変更のリードタイム (本番用のコードがコミットされるまでの時間) とデプロイの頻度 (コードをコミットする頻度) です。
耐障害性: テストカバレッジ、可観測性ツール、フィーチャー フラグのような他のアプローチとともに使用すると、CI/CD でソフトウェアのエラー耐久性が向上します。DORA は、平均修復時間 (事象が解決されるまでの時間) と変更失敗率 (ソフトウェア ロールバックの回数) をトラッキングして、この安定性を測定します。
セキュリティ: オートメーションにはセキュリティが含まれます。勢いがある DevSecOps とともに、CI/CD パイプラインは今後も有効で、コードとアクセス許可の適切なチェックがあり、障害の監査、セキュリティ侵害、非コンプライアンス事象についての仮想証拠書類を提供します。
スケーラビリティ: CI/CD は単なるオートメーション化ではありません。スケーラビリティを確保することも重要です。堅牢な CI/CD 設定は、開発チームの拡大とプロジェクトの複雑化に伴って簡単に拡張できるはずです。これは、生産性と効率を維持しながら、ソフトウェア開発の労力が増大するのに伴って増加するワークロードを効率的に処理できるということです。
CI/CD でできること: 実際に導入されたお客様の事例
DevOps チームが継続的な自動化をどのように実践しているかをご覧ください。
Blue Yonder: 内部サーバーからクラウドベース CI/CD に移行します。Blue Yonder を見てみる
Plaid: 開発時間と開発者の生産性が向上。Plaid について
3M: 共有ツールとオートメーションでサイロを破壊する。3M について
CI/CD でできること
始める準備ができている場合でも、まだ質問がある場合でも、私たちにお任せください。
ベスト プラクティスについて調べる: ベスト プラクティスについて詳しくは、こちら
GitHub デモを行う: 世界クラスの CI/CD、自動化、セキュリティが、どのようにワークフローをサポートするのかをご確認ください。デモをリクエストする
エキスパートに尋ねる: GitHub の製品リーダーとの 1 対 1 のセッションで、自分のビジネス目標のためのカスタムな戦略を作り上げましょう。仮想ブリーフィングを予約する
DevOps ソリューションを比較する: GitHub と、他の DevOps ツールおよびプラットフォームとの比較をご覧ください。詳細はこちら