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

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

Dan Radigan Dan Radigan

継続的インテグレーション (CI) へチームがコミットすることがアジリティを手に入れる近道です。それは(特にチームが未だ CI を受け入れていない場合)脅迫的に聞こえるかもしれません。しかし、いいニュースもあります。コードベースの継続的インテグレーションも自動化テストフレームワークも、利用しているテクノロジーに関わらず、実践できる可能性があるのです。

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.

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.

That is decidedly not fast.

Protect quality with continuous builds and test automation

わたしたちのうち何人が、最新のソースコードをダウンロードして、コンパイルされていないことに気づいたり、重要なバグに気づいたりしてるでしょう?何と生産性の悪い!

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

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

テストの自動化:品質を保証するためのソフトウェアのプログラム検証。テストはソフトウェアの UI (このあとすぐに説明します)またはバックエンドのサービス層から開始できます。

この 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 では、コードが設計通りに機能するか確認します。最も確実なのは、製品のすべてのレベルを検証できる一連の自動化テストを実施することです。 

Unit Tests

ユニットテストは、コードの中でもコアコンポーネントに極めて近いところで実行します。品質を保証する防御の第一線となります。

Benefits: Easy to write, run fast, closely model the architecture of the code base.

Drawbacks: Unit tests only validate core components of software; they don't reflect user workflows which often involve several components working together.

ユニットテストはコードの動作を明確にするため、開発者はコードのその部分の最新状況をユニットテストからレビューできます。

API テスト

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

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

Drawbacks: In simple areas of the code, API tests can mimic some unit tests.

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

機能テスト

Functional tests work over larger areas of the code base and model user workflows. In web applications, for example, HTTPUnit and Selenium directly interact with the user interface to test the product.

Benefits: More likely to find bugs because they mimic user actions and test the interoperability of multiple components.

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:理想的な組み合わせ

Many teams avoid branching because of painful merges. With newer technologies in version control like Git, both branching and merging become easy. To ensure that the primary code line ("master" in Git parlance) remains healthy, run the same level of continuous integration on all development and stable version branches as well. When the build passes on a branch, the team has the confidence to merge that code upstream.

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.