CI/CD とは

CI/CD(継続的インテグレーション/継続的な配信またはデプロイ)は、自動化によって実現されるソフトウェア開発手法です。頻繁で信頼性の高い更新により、コードが継続的に配信され、リリースサイクルが加速します。

CI/CD とは

CI/CD は、DevOps のいくつかのフェーズを網羅した総称です。CI(継続的インテグレーション)は、コード変更を 1 日に数回リポジトリに統合する手法です。CD には 2 つの意味があります。継続的な配信ではコードの統合を自動化し、継続的デプロイではエンドユーザーに最終的なビルドを自動的にリリースします。CI/CD の頻繁に実行されるテストにより、コードのエラーや不具合が減少します。これは、すべての DevOps ワークフローにとって不可欠なことです。

 

ソースコード管理

継続的インテグレーション(CI)

CI は DevOps のベストプラクティスであり、DevOps ライフサイクルの 1 段階です。ここでは、開発者が 1 日数回共有コードリポジトリにコードをチェックインします。理想としては、これが発生するたびに自動ビルドツールでチェックインまたはブランチを検証し、エラーなく製品化する準備ができていることを確認します。ここでの主なメリットは、通常は問題が雪だるま式により大きくなる前に、早期に検出されることです。

CI の実践は、変更の小さなサブセットをより短期間で統合することを意味します。回数を少なくして時間のかかる大きな更新を行うのではありません。変更をテスト、マージして、共有リポジトリにチェックインするためのワークフローを自動化することで、チームはよりクリーンなコードを迅速に提供できます。よりクリーンなコードは、迅速な検証、クリーンなリリース、および簡単にスケールできる効率的な開発パイプラインを実現します。

 

継続的インテグレーション(CI)

CI は DevOps のベストプラクティスであり、DevOps ライフサイクルの 1 段階です。ここでは、開発者が 1 日数回共有コードリポジトリにコードをチェックインします。理想としては、これが発生するたびに自動ビルドツールでチェックインまたはブランチを検証し、エラーなく製品化する準備ができていることを確認します。ここでの主なメリットは、通常は問題が雪だるま式により大きくなる前に、早期に検出されることです。

CI の実践は、変更の小さなサブセットをより短期間で統合することを意味します。回数を少なくして時間のかかる大きな更新を行うのではありません。変更をテスト、マージして、共有リポジトリにチェックインするためのワークフローを自動化することで、チームはよりクリーンなコードを迅速に提供できます。よりクリーンなコードは、迅速な検証、クリーンなリリース、および簡単にスケールできる効率的な開発パイプラインを実現します。

 

継続的インテグレーション(CI)

CI は DevOps のベストプラクティスであり、DevOps ライフサイクルの 1 段階です。ここでは、開発者が 1 日数回共有コードリポジトリにコードをチェックインします。理想としては、これが発生するたびに自動ビルドツールでチェックインまたはブランチを検証し、エラーなく製品化する準備ができていることを確認します。ここでの主なメリットは、通常は問題が雪だるま式により大きくなる前に、早期に検出されることです。

CI の実践は、変更の小さなサブセットをより短期間で統合することを意味します。回数を少なくして時間のかかる大きな更新を行うのではありません。変更をテスト、マージして、共有リポジトリにチェックインするためのワークフローを自動化することで、チームはよりクリーンなコードを迅速に提供できます。よりクリーンなコードは、迅速な検証、クリーンなリリース、および簡単にスケールできる効率的な開発パイプラインを実現します。

 

継続的インテグレーションと継続的デリバリーの比較

継続的な配信

継続的な配信は CI に続くプロセスであり、最終製品が顧客にリリースまたはデプロイされる前の開発パイプラインのチェックポイントフェーズと考えることができます。検証されたコード変更は、自動的にリポジトリに配信されます。

継続的な配信の目標は、変更セットを小さくして、メインビルドを更新しなくても、最終製品の「製品版」としてのステータスが(リリース可能な状態でない場合でも)損なわれないようにすることです。最終製品には軽微なエラーが含まれている可能性がありますが、ユーザー体験を損なうほどのエラーではありません。

継続的な配信の実践により、開発者は社内でのテストに費やす時間を減らすことができます。この手法では、安定したコードだけが最初に配信フェーズに到達できるためです。これにより、バグ検出のプロセスがよりシンプルになり、解決までの時間が短縮されます。

CI/CD のメリット

迅速なイテレーション

DevOps ライフサイクルの一部として CI/CD の手法を採用すると、コードベースへの変更を検証してデプロイする手動での作業が自動化され、開発がスピードアップします。

よりクリーンなコード

1 日を通して多数の小さな変更をチェックインすると、ビルドを壊すエラーがソースコードに取り込まれるリスクが大幅に減少します。

迅速なバグ修正

小さな変更セットをより頻繁に CI/CD とマージすると、簡単にコードエラーを特定し、大きな問題になる前に修正できます。

フィードバックループの短縮

CI/CD はフィードバックループの短縮に役立ちます。これは DevOps のコア原則の 1 つです。小さなかつ反復的な変更は、統合、テスト、デプロイが容易であるためです。

より優れたコラボレーション

CI/CD は、コードのコミットとビルドの起動のプロセスおよびタイムラインを定義することで作業を明確にします。より明確な目標を設定することで、チームのアジリティが高まります。

顧客の満足度を高める

ビルドは常に CI/CD でリリース可能な状態であるため、顧客にとってはサービスの中断が少なくなり、フィードバックをより短時間で統合できます。

類似のリソース

CI/CD とその他 DevOps ソリューションやプロセスについて学べるさまざまなリソースが見つかります。

アジャイルと DevOps の比較

アジャイルと DevOps の目標は同じであり、定期的なリリーススケジュールを通じて顧客価値を提供することです。しかし、そのアプローチは少し異なります。これらがどのように連携するかをご覧ください。

DevOps を採用するメリット

DevOps プラクティスを実装すると、開発パイプラインが合理化され、チームとユーザーの満足度を高めることができます。DevOps がどのように役立つかをご確認ください。

ソースコード管理について理解を深める

ソースコード管理(SCM)は、チームが作業をスピードアップし、共同作業を効率化するのに役立ちます。使用するタイミングやしくみなど、バージョン管理ツールについて知っておくべきすべてのことについて説明します。

Unity の CI/CD ソリューション

Unity の CI/CD ソリューションを使用して、プロジェクトのイテレーションをスピードアップし、強力なソースコードの管理と自動化を活用します。分散作業には Unity Cloud Build を利用し、オンプレミスのビルド容量のスケールには Unity Build Server を利用します。

CI/CD Frequently asked questions

Is agile the same as CI/CD?

An agile workflow and CI/CD are related, however, they are not the same! They describe completely different aspects of the software development pipeline. Agile development, refers to the process or methodologies for managing workflows, meeting cadences, and team organization in software development. An agile methodology embraces change while accelerating delivery by listening and responding to customer needs and involving them in each stage of the development process.

CI/CD relies on automation to remove the human elements that create bottlenecks in releasing and improving the software. In both CI and CD testing is automated throughout the pipeline and is done frequently to minimize the costs and time it takes to remediate defects.

 

How often should you be deploying to production with continuous deployment?

With CI/CD, releases should always be frequent to avoid future problems and assure your software is always in a releasable state - typically deploying multiple times a day. A common assumption with CI/CD teams should be implementing "constant" releases, however, this is not always the case. Your release cycle can vary widely depending on your product, your builds, and other factors you might want to take into consideration such as:

Is it a critical or minor fix?

Are you tracking regression counts from build to build?

Is there a QA team put in place?

Does the code base have unit tests?

Are there any code duplications?

These are just a few examples of aspects to consider when thinking about a release strategy and pipeline, but it differs drastically from team to team. Different products require different approaches.

Is continuous deployment worth it?

There is no one size fits all answer to this question. Before investing in continuous deployment a business must first assess what the biggest risks are of their product and then determine the tradeoffs in how you want to deploy software. The success of your product is dependent on being able to quickly iterate, get feedback from your customers, and continue to make changes. Continuous deployment will be highly impactful and profitable if you are prioritizing shortening feedback loops and building a highly responsive business. However, if your business does not have many customers then the benefits of implementing increments of deployment will add less value and more costs. The staging environment you choose to deploy ultimately depends on your business needs, workflow, and budget.

Does continuous delivery encourage configuration as code?

Continuous delivery does encourage configuration because it continuously makes changes to the original code in the configuration. This ensures that the configuration stays up with code errors that may occur over time.

弊社のウェブサイトは最善のユーザー体験をお届けするためにクッキーを使用しています。詳細については、クッキーポリシーのページをご覧ください。

OK