継続的インテグレーション、継続的デリバリー、継続的デプロイ

We will see in this article what these three practices mean and what's required to use them.

Sten Pittet Sten Pittet

人々が最新の開発プラクティスについて語るときには、よく CI と CD という 2 つの頭字語が話題にのぼることがあります。CI は、単純に継続的インテグレーションの略で、簡単にリリースを準備することに着目した手法のことです。しかし、CD は継続的デリバリーを意味することもあれば、継続的デプロイを意味する場合もあり、これら 2 つの手法には共通点が多いものの、ビジネスに重大な結果をもたらしかねない大きな相違点もあります。

We will see in this article what these three practices mean and what's required to use them.

継続的インテグレーション、継続的デリバリー、継続的デプロイの相違点

継続的インテグレーション

継続的インテグレーションを実践する開発者は、変更を可能な限り頻繁にメインブランチにマージして戻す必要があります。開発者による変更は、ビルドを作成し、そのビルドに対して自動テストを実行することによって検証されます。そうすることで、通常人々がリリース日を待ってリリースブランチに変更をマージする場合に発生する統合地獄を回避できます。

Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.

継続的デリバリー

Continuous delivery is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way. This means that on top of having automated your testing, you also have automated your release process and you can deploy your application at any point of time by clicking on a button.

In theory, with continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever suits your business requirements. However, if you truly want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches that are easy to troubleshoot in case of a problem.

継続的デプロイ

継続的デプロイは継続的デリバリーを一歩先に進めたものです。この手法では、生産パイプラインのすべての段階を通過するあらゆる変更が顧客にリリースされます。人間は全く介入せず、新しい変更が本番にデプロイされないのはテストに失敗した場合のみです。

Continuous deployment is an excellent way to accelerate the feedback loop with your customers and take pressure off the team as there isn't a Release Day anymore. Developers can focus on building software, and they see their work go live minutes after they've finished working on it.

How the practices relate to each other

簡単に言うと、継続的インテグレーションは継続的デリバリーと継続的デプロイの両方の一部です。継続的デプロイは継続的デリバリーと似ていますが、リリースが自動的に行われる点だけが異なります。

What are the differences between continuous integration, continuous delivery, and continuous deployment? | Atlassian CI/CD

What are the benefits of each practice?

We've explained the difference between continuous integration, continuous delivery, and continuous deployments but we haven't yet looked into the reasons why you would adopt them. There's an obvious cost to implementing each practice, but it's largely outweighed by their benefits.

実践 必要なもの (コスト) 得られるもの

継続的インテグレーション

  • Your team will need to write automated tests for each new feature, improvement or bug fix.
  • メインリポジトリを監視し、プッシュされたすべての新しいコミットに対して自動的にテストを実施する継続的インテグレーションサーバーが必要です。
  • 開発者は可能な限り頻繁に (少なくとも 1 日 1 回)、変更をマージする必要があります。
  • Less bugs get shipped to production as regressions are captured early by the automated tests.
  • Building the release is easy as all integration issues have been solved early.
  • 開発者はビルドが中断するとすぐに警告され、次のタスクに移る前に修復作業を行うことができるため、コンテキストの切り替えが少なくなります。
  • Testing costs are reduced drastically – your CI server can run hundreds of tests in the matter of seconds.
  • Your QA team spend less time testing and can focus on significant improvements to the quality culture.
継続的デリバリー
  • You need a strong foundation in continuous integration and your test suite needs to cover enough of your codebase.
  • Deployments need to be automated. The trigger is still manual but once a deployment is started there shouldn't be a need for human intervention.
  • Your team will most likely need to embrace feature flags so that incomplete features do not affect customers in production.
  • The complexity of deploying software has been taken away. Your team doesn't have to spend days preparing for a release anymore.
  • より頻繁にリリースを実行できることから、顧客とのフィードバックループを加速できます。
  • There is much less pressure on decisions for small changes, hence encouraging iterating faster.
継続的デプロイ
  • 最高のテスト文化が求められます。テストスイートの品質がリリースの品質を左右します。
  • ドキュメント作成プロセスとデプロイのペースの足並みをそろえる必要があります。
  • Feature flags become an inherent part of the process of releasing significant changes to make sure you can coordinate with other departments (Support, Marketing, PR...).
  • You can develop faster as there's no need to pause development for releases. Deployments pipelines are triggered automatically for every change.
  • Releases are less risky and easier to fix in case of problem as you deploy small batches of changes.
  • 顧客は継続的改善のストリームを確認でき、品質が月、四半期、年単位ではなく毎日向上します。

継続的インテグレーション

必要なもの (コスト)

  • Your team will need to write automated tests for each new feature, improvement or bug fix.
  • メインリポジトリを監視し、プッシュされたすべての新しいコミットに対して自動的にテストを実施する継続的インテグレーションサーバーが必要です。
  • 開発者は可能な限り頻繁に (少なくとも 1 日 1 回)、変更をマージする必要があります。

得られるもの

  • Less bugs get shipped to production as regressions are captured early by the automated tests.
  • Building the release is easy as all integration issues have been solved early.
  • 開発者はビルドが中断するとすぐに警告され、次のタスクに移る前に修復作業を行うことができるため、コンテキストの切り替えが少なくなります。
  • Testing costs are reduced drastically – your CI server can run hundreds of tests in the matter of seconds.
  • Your QA team spend less time testing and can focus on significant improvements to the quality culture.

継続的デリバリー

必要なもの (コスト)

  • You need a strong foundation in continuous integration and your test suite needs to cover enough of your codebase.
  • Deployments need to be automated. The trigger is still manual but once a deployment is started there shouldn't be a need for human intervention.
  • Your team will most likely need to embrace feature flags so that incomplete features do not affect customers in production.

得られるもの

  • The complexity of deploying software has been taken away. Your team doesn't have to spend days preparing for a release anymore.
  • より頻繁にリリースを実行できることから、顧客とのフィードバックループを加速できます。
  • There is much less pressure on decisions for small changes, hence encouraging iterating faster.

継続的デプロイ

必要なもの (コスト)

  • 最高のテスト文化が求められます。テストスイートの品質がリリースの品質を左右します。
  • ドキュメント作成プロセスとデプロイのペースの足並みをそろえる必要があります。
  • Feature flags become an inherent part of the process of releasing significant changes to make sure you can coordinate with other departments (Support, Marketing, PR...).

得られるもの

  • You can develop faster as there's no need to pause development for releases. Deployments pipelines are triggered automatically for every change.
  • Releases are less risky and easier to fix in case of problem as you deploy small batches of changes.
  • 顧客は継続的改善のストリームを確認でき、品質が月、四半期、年単位ではなく毎日向上します。

One of the traditional cost associated with continuous integration is the installation and maintenance of a CI server. But you can reduce significantly the cost of adopting these practices by using a cloud service like Bitbucket Pipelines which adds automation to every Bitbucket repository. By simply adding a configuration file at the root of your repository you will be able to create a continuous deployment pipeline that gets executed for every new change pushed to the main branch.

A continuous deployment pipeline with Bitbucket | Atlassian CI/CD

Going from continuous integration to continuous deployment

If you're just getting started on a new project with no users yet, it might be easy for you to deploy every commit to production. You could even start by automating your deployments and release your alpha version to a production with no customers. Then you would ramp up your testing culture and make sure that you increase code coverage as you build your application. By the time you're ready to onboard users, you will have a great continuous deployment process where all new changes are tested before being automatically released to production.

But if you already have an existing application with customers you should slow things down and start with continuous integration and continuous delivery. Start by implementing basic unit tests that get executed automatically, no need to focus yet on having complex end-to-end tests running. Instead, you should try automating your deployments as soon as possible and get a to a stage where deployments to your staging environments are done automatically. The reason is that by having automatic deployments, you will be able to focus your energy on improving your tests rather than having periodically to stop things to coordinate a release.

Once you can start releasing software on a daily basis, you can look into continuous deployment, but make sure that the rest of your organization is ready as well. Documentation, support, marketing. These functions will need to adapt to the new cadence of releases, and it is important that they do not miss on significant changes that can impact customers.

Read our guides

You can find some guides that will go more in depth to help you getting started with these practices.