CI / CDとは何ですか？継続的な統合と継続的な配信を理解する

「AWS、Azure、GitlabのCI / CD」コースの開始を見越して、役立つ資料の翻訳を用意しました。

---

継続的統合（CI）と継続的配信（CD）は、開発者がソフトウェアの変更をより頻繁かつ確実に展開できるようにする文化、一連の原則と実践です。



CI / CDはDevOpsプラクティスの1つです。また、アジャイルプラクティスにも適用されます。展開の自動化により、開発者はビジネス要件、コード品質、およびセキュリティを満たすことに集中できます。

CI / CDの定義

継続的統合は、頻繁にコミットするコードに小さな変更を加える開発方法論と一連のプラクティスです。また、最新のアプリケーションのほとんどはさまざまなプラットフォームとツールを使用して開発されているため、統合メカニズムと導入された変更のテストが必要です。



技術的に言えば、CIの目標は、アプリケーションを構築、パッケージ化、およびテストするための一貫した自動化された方法を提供することです。合理化された継続的な統合プロセスにより、開発者は頻繁にコミットする可能性が高くなります。これにより、コミュニケーションが改善され、ソフトウェアの品質が向上します。



継続的な配信は、継続的な統合が終了するところから始まります。さまざまな環境へのアプリケーションの展開を自動化します。ほとんどの開発者は、実稼働環境と開発およびテスト環境の両方で作業します。



CI / CDツールは、展開中に構成される特定の環境パラメーターを設定するのに役立ちます。また、CI / CD自動化は、Webサーバー、データベース、およびアプリケーションの展開時に再起動または追加のアクションを実行する必要があるその他のサービスに対して必要な要求を実行します。



継続的な統合と継続的な配信には継続的なテストが必要です究極の目標は高品質のアプリケーションを開発することだからです。継続的なテストは、CI / CDパイプラインで実行されるさまざまな自動テスト（回帰、パフォーマンスなど）のセットとして実装されることがよくあります。



CI / CDの成熟したプラクティスにより、継続的な展開が可能になります。コードがCI / CDパイプラインを正常に通過すると、アセンブリは自動的に実稼働環境に展開されます。継続的な配信を実践しているチームは、毎日または1時間ごとに展開する余裕があります。ただし、継続的な配信がすべてのビジネスアプリケーションに適しているわけではないことに注意してください。

継続的な統合により、コミュニケーションと品質が向上します

継続的な統合は、規制されたプロセスと自動化に基づく開発方法論です。継続的な統合が実装されているため、開発者はコードをソースコードリポジトリにコミットすることがよくあります。そして、ほとんどのチームは、少なくとも1日に1回コミットするというルールに従います。小さな変更は、長期間にわたって取り組んできた大きな変更よりも、欠陥やさまざまな問題を見つけやすくなります。さらに、短いコミットサイクルで作業すると、複数の開発者が同じコードを変更する可能性が低くなり、マージの競合が発生する可能性があります。



継続的な統合を実装するチームは、多くの場合、バージョン制御システムをセットアップしてワークフローを定義することから始めます。コミットは頻繁に行われるという事実にもかかわらず、機能の実装とバグの修正には長い時間がかかる可能性があります。どの機能とコードの準備ができているかを制御するには、いくつかのアプローチがあります。



多くの人が機能フラグを使用しています。これは、実行時に機能のオンとオフを切り替えるメカニズムです。まだ開発中の機能は機能フラグにラップされ、マスターブランチから本番環境に展開されますが、完全に使用できるようになるまで無効になります。最近の研究によるとフラグ機能を使用しているチームの63％が、テスト容易性とソフトウェア品質の向上を報告しています。CloudBees Rollout、Optimizely Rollouts、LaunchDarklyなどの機能フラグを操作するための特別なツールがあります。これらはCI / CDに統合され、機能レベルで構成を実行できます。



機能を操作する別の方法は、バージョン制御システムでブランチを使用することです。この場合、分岐モデル（Gitflowなど）を定義し、コードが開発、テスト、および本番のブランチにどのように組み込まれるかを説明する必要があります。開発サイクルが長い機能の場合、個別の機能ブランチが作成されます。機能の作業を完了した後、開発者は機能ブランチからメイン開発ブランチに変更をマージします。このアプローチはうまく機能しますが、多くの機能が同時に開発されている場合は不便になる可能性があります。



ビルドフェーズでは、必要なソフトウェア、データベース、およびその他のコンポーネントのパッケージ化を自動化します。たとえば、Javaアプリケーションを開発している場合、CIは、HTML、CSS、JavaScriptなどのすべての静的ファイルをJavaアプリケーションおよびデータベーススクリプトとともにパッケージ化します。



CIは、すべてのソフトウェアコンポーネントとデータベースをパッケージ化するだけでなく、ユニットテストやその他のタイプのテストも自動的に実行します。このテストにより、開発者は、行った変更によって何も破損しなかったというフィードバックを得ることができます。



ほとんどのCI / CDツールでは、手動、コミット、またはスケジュールに従ってビルドを開始できます。チームは、チームのサイズ、予想される1日のコミット、およびその他の基準に基づいて、チームに適したビルドスケジュールについて話し合う必要があります。コミットとビルドが高速であることが重要です。そうしないと、ビルドが長いと、開発者がすばやく頻繁にコミットしようとする際の障害になる可能性があります。

継続的なテストはテストの自動化以上のものです

自動テストフレームワークは、QAエンジニアがさまざまな種類のテストを設計、実行、および自動化するのに役立ち、開発者がビルドの成功を追跡するのに役立ちます。テストには、各スプリントの最後に開発され、アプリケーション全体の回帰テストに結合される機能テストが含まれます。回帰テストは、変更によってアプリケーションの他の場所で何かが壊れたかどうかをチームに通知します。



ベストプラクティスは、開発者にローカル環境で回帰テストの全部または一部を実行するように要求することです。これにより、開発者はすでにチェック済みのコードをコミットできます。



回帰テストはほんの始まりに過ぎません。パフォーマンステスト、APIテスト、静的コード分析、セキュリティテスト-これらおよびその他のタイプのテストも自動化できます。重要な点は、コマンドライン、Webhook、またはWebサービスを介してこれらのテストを実行し、実行結果を返す機能です。テストが成功したかどうか。



継続的なテストには、自動化だけでなく、自動化されたテストのCI / CDパイプラインへの統合も含まれます。ユニットテストと機能テストはCIの一部であり、CIパイプラインの起動前または起動中に問題を特定できます。パフォーマンステストやセキュリティテストなど、完全な環境展開を必要とするテストは、多くの場合CDの一部であり、ビルドがターゲット環境に展開された後に実行されます。

CDパイプラインは、さまざまな環境への変更の配信を自動化します

継続的な配信とは、アプリケーションをターゲット環境に自動的に展開することです。通常、開発者は、テストとレビューのためにアプリケーションが展開される1つ以上の開発環境とテスト環境で作業します。このために、Jenkins、CircleCI、AWS CodeBuild、Azure DevOps、Atlassian Bamboo、TravisCIなどのCI / CDツールが使用されます。



一般的なCDパイプラインは、ビルド、テスト、および展開のステップで構成されています。より複雑なパイプラインには、次の手順が含まれます。

• ソースコントロールからコードを取得し、ビルドを実行します。
• Infrastructure-as-Codeアプローチによって自動化されたインフラストラクチャの構成。
• コードをターゲット環境にコピーします。
• ターゲット環境の環境変数を設定します。
• (-, API-, ).
• , , .
• .
• .

たとえば、Jenkinsコンベヤーで決定されたファイルJenkinsfileには、アセンブリ（ビルド）、テスト（テスト）、展開（デプロイ）などのさまざまなステップが記述されています。また、パイプラインステージで使用できる環境変数、秘密鍵、証明書、およびその他のパラメーターについても説明します。投稿セクションでは、エラー処理と通知を構成します。



より複雑なCDパイプラインでは、データの同期、情報リソースのアーカイブ、更新とパッチのインストールなどの追加の手順が必要になる場合があります。 CI / CDツールは通常、プラグインをサポートします。たとえば、Jenkinsには、サードパーティプラットフォームと統合し、ユーザーインターフェイス、管理、ソースコード管理、および構築を拡張するための1500を超えるプラグインがあります。



CI / CDツールを使用する場合、開発者は、すべてのパラメーターが環境変数を介してアプリケーションの外部で構成されていることを確認する必要があります。CI / CDツールを使用すると、これらの変数の値を設定し、パスワードとアカウントキーをマスクし、特定の環境への展開中にそれらをカスタマイズできます。

CDツールにもダッシュボードとレポートがあります。ビルドまたは配信に失敗した場合、彼らはそれについて通知します。CDをバージョンコントロールおよびアジャイルツールと統合することにより、ビルドに含まれるコードの変更やユーザーストーリーを簡単に見つけることができます。

Kubernetesおよびサーバーレスアーキテクチャを使用したCI / CDパイプラインの実装

クラウドでCI / CDパイプラインを使用する多くのチームは、DockerのようなコンテナとKubernetesのようなオーケストレーションシステムを使用します。コンテナは、パッケージング、配信を標準化し、揮発性環境のスケーリングと破壊を簡素化するのに役立ちます。



コンテナ、コードとしてのインフラストラクチャ、およびCI / CDパイプラインを共有するための多くのオプションがあります。これについて詳しくは、Kubernetes withJenkinsおよびKuberneteswith AzureDevOpsの記事をご覧ください。



サーバーレスコンピューティングは、アプリケーションを展開およびスケーリングするもう1つの方法です。サーバーレス環境では、インフラストラクチャはクラウドプロバイダーによって完全に管理され、アプリケーションはその設定に従って必要に応じてリソースを消費します。たとえば、AWSでは、サーバーレスアプリケーションはAWS Lambda関数を介して実行され、その展開はプラグインを使用してJenkins CI / CDパイプラインに統合できます。

CI / CDにより、より頻繁なコード展開が可能になります

それでは、要約しましょう。 CIパッケージ、ビルドのテスト、および問題が発生した場合の開発者への通知。 CDは自動的にアプリケーションを展開し、追加のテストを実行します。



CI / CDパイプラインは、信頼性の高い配信プロセスでアプリケーションに頻繁に変更を加える必要がある組織向けに設計されています。ビルドの標準化、テストの開発、および展開の自動化に加えて、コード変更を展開するための全体的なワークフローを取得します。 CI / CDを実装することで、開発者はアプリケーションの改善に集中でき、展開に時間を無駄にすることはありません。



CI / CDはDevOpsプラクティスの1つですこれは、頻繁に変更を加えたい開発者と、安定性を必要とする悪用との間の矛盾と戦うことを目的としているためです。自動化により、開発者はより頻繁に変更を加えることができ、環境の構成が標準化され、配信プロセス中に継続的なテストが実行されるため、運用チームはより安定性を得ることができます。また、環境変数の設定はアプリケーションとは別であり、自動ロールバック手順があります。



CI / CDパイプラインの実装による影響は、DevOpsの主要なパフォーマンス指標（KPI）の観点から測定できます。..。展開頻度、変更リード時間、平均回復時間などのKPIは、継続的なテストを伴うCI / CD展開で改善されることがよくあります。ただし、CI / CDは、これらの改善に貢献できるプロセスの1つにすぎません。配信頻度を上げるには、他にも条件があります。



CI / CDの使用を開始するには、開発および運用チームがテクノロジー、プラクティス、および優先順位について協力する必要があります。チームは、CI / CDの実装後、チームが選択されたプラクティスを一貫して順守できるように、ビジネスとテクノロジーへの適切なアプローチについてコンセンサスを構築する必要があります。

---

CICDツールの概要：Gitlab CI、Docker、Ansible

---