Continuous integration, explained

Build your team's agility with faster feedback. Because you only move as fast as your tests.

Nothing builds–or destroys–agility like a team's commitment to continuous integration (CI). That might sound ominous (especially if your team has yet to embrace CI), but there's good news. Regardless of the technologies a team uses, chances are there's a continuous integration and automated test framework that will work for their code base. Here's what you need to know before you dive into the detail.

Continuous integration articles


What is continuous integration?

Continuous integration is the practice of routinely integrating code changes into the main branch of a repository, and testing the changes, as early and often as possible. Ideally, developers will integrate their code daily, if not multiple times a day.

Automated testing, continuous delivery, and continuous deployment

It is important to distinguish continuous integration from automated testing as well as continuous delivery and continuous deployment. While those development practices relate to each other, they differ essentially by how the code gets deployed to production.

Automated testing

Automated tests are tests that can be run without the need of human intervention in a repeatable way, at any time. You typically have to write down a script to test some assertions or validate the behaviour of your application. The script is then run by a machine which provides the results as an output. Automated testing is a key part of CI, but it is not enough by itself.


You practice continuous delivery when your codebase is always deployable, ready to go to production in one click. While it is recommended to deploy to production as soon as you get a green build, you may decide to slow down the releases on purpose for business reasons.


Continuous deployment happens when every change to the main branch that passes the CI tests gets pushed to production without the need for human interaction. This often results in many deployments per day which provide fast feedback to the development team.

Benefits of continuous integration

Investing in CI results in fast feedback on code changes. Fast as in "within minutes" fast. A team that relies primarily on manual testing may get feedback in a couple hours, but in reality, comprehensive test feedback comes a day–or several days–after the code gets changed. And by that time more changes have occurred, making bug-fixing an archeological expedition with developers digging through several layers of code to get at the root of the problem.


アジャイルチームは、デスマーチも英雄も必要とせずに、優れた品質のソフトウェアを迅速にデリバリーします。これを可能にするのが CI です。

Protect quality with continuous builds and test automation


以下の 2 つのことを実践してこの状況から脱出できます。

継続的なビルド:変更したらすぐにプロジェクトを作成する。理想的なのは、各ビルド間における変更セットを 1 つまでとすること。

Test automation: Programatic validation of the software to ensure quality. Tests can initiate actions in the software from the UI (more on that in a moment), or from within the backend services layer.

この 2 つの実践はピーナツバターとジャムだと思ってください:別々でもおいしい、一緒でもおいしい!継続的インテグレーションにより継続的なビルドとテストの自動化を組み合わせ、各ビルドで確実にコードベースの品質も評価できるようになります。

And remember: to fully realize the benefits, a team must also have the discipline to pause development and address breakages right away. The energy a team invests (and make no mistake: it's an investment) in writing tests and configuring the automation is all for naught if builds are allowed to languish in a broken state. Protecting the investment in CI and protecting the quality of the code base are one and the same thing. 

Testing in CI: Unit, API, and functional tests

CI の実行には 2 つのフェーズがあります。ステップ 1 ではコードのコンパイルを確実に行います。(あるいは、インタープリタ型言語の場合はすべてをひとつにまとめます。)ステップ 2 では、コードが設計通りに機能するか確認します。最も確実なのは、製品のすべてのレベルを検証できる一連の自動化テストを実施することです。 



難点:ユニットテストではソフトウェアのコアコンポーネントしか検証しません。つまり、一緒に稼働する複数のコンポーネントを含めたユーザー ワークフローを反映していません。


API テスト

良いソフトウェアとはモジュール式で、複数のアプリケーションにまたがる作業を明確に分別できます。API は複数の異なるモジュールがそれぞれ通信し合うエンドポイントであり、API テストはひとつのモジュールから他のモジュールへとコールすることで検証を行います。

Benefits: Generally easy to write, run fast, and can easily model how applications will interact with one another.

難点:コードの簡易なエリアでは、API テストが複数のユニットテストの再現になってしまうことがあります。

API はアプリケーションのパーツ間のインターフェースであるため、リリースの準備の際には大変便利です。リリースしようとしているビルドが一旦すべての API テストをパスすれば、カスタマー向けの出荷に相当な自信が持てます。


機能テストは、コードベースとモジュールのユーザーワークフローのより大きな範囲をテストします。ウェブアプリケーションでは、例えば、HTTPUnitSelenium なら、ユーザーインターフェースと直に相互作用して製品をテストできます。


Drawbacks: Slower than unit tests, and sometimes report false negatives because of network latency or a momentary outage somewhere in the technology stack.

実際のユーザーワークフローに近づくにつれ、自動化テストのスピードが落ちていくことがあります。HTTPUnit は、本格的なウェブブラウザではないため、より速く実行できます。Selenium は、ウェブブラウザと同じ速度でしか実行できませんが、複数のウェブブラウザで並行して実行できる利点があります。このような難点もありますが、機能テストは極めて有益なうえ、人為テストよりも断然速くフィードバックを提供してくれます。




Atlassian では、開発者を常にイノベーティブに保ち、コードベースは健全に保つ努力をしています。開発者の「内部フィードバック ループ」– 変更を作成してからテスト結果を取得するまでの所要時間 – 短縮を重要視しています。

自動化テストの実行により、ビルドの追加や期間の延長が可能です。戦略のひとつは、複数のサーバーまたは「ビルドエージェント」にまたがって自動化テストを並行して実施することです。そうすれば、CI サーバーで実際に 2 件、20 件、たとえ 200 件でも同時にテストを実行できるのです。クラウド技術を使用すれば、テストパッケージが大きくなるのに合わせ、開発チームのニーズに見合ったスケールへと CPU を容易に拡張できます。ですが、CPU は無制限ではありません。コードの各エリアを重複しない様に完全にテストします。重複テストはビルド期間を長引かせます(CPU も無駄に使用します)。エンジニアが早くゴーサインを得られれば、バックログの次の項目へ早く進むことができます。 

ブランチングと CI:理想的な組み合わせ

マージが厄介である故に、多くのチームがブランチングを避けています。Git のような最近のバージョン管理テクノロジーを使用すれば、ブランチングもマージも簡単になります。確実にプライマリのコードライン(Git 用語でいう "master")を健全に保つには、開発全般で同じレベルの継続的インテグレーションと安定したバージョンのブランチを同様に実行します。ビルドがブランチに送られれば、チームは確実にコードのアップストリームへマージできます。

With branching, continuous integration, and test automation, teams can be productive and innovative while still protecting code quality. If you're ready to take the next steps, check out our step-by-step guide to getting started with CI.

This is agile development at its best: delivering working software regularly, with minimal technical debt and without compromising ingenuity.

Dan Radigan
Dan Radigan

Agile has had a huge impact on me both professionally and personally as I've learned the best experiences are agile, both in code and in life. You'll often find me at the intersection of technology, photography, and motorcycling. Find me on Twitter! @danradigan