Pythonによるテスト駆動開発, 3rd Edition

章25 CI ：継続的インテグレーション

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

サイトが大きくなるにつれ、機能テストを全て実行するのにかかる時間がどんどん長くなる。 このままでは、テストを面倒に感じてやめてしまう危険がある。

それを防ぐために、機能テストの実行を自動化する方法がある。 「継続的インテグレーション」、つまりCIを設定するのだ。 そうすれば、日々の開発作業では、その時点で作業中のFTだけを実行すればよい。 他のテストはCIが自動的に実行し、何かを誤って壊してしまった場合に通知してくれる。

単体テストは十分に高速なままにしておくべきだ。 そうすれば数秒おきにローカルで全テストスイートを実行し続けられる。

注記

継続的インテグレーションは、1990年代に ケント・ベックの エクストリームプログラミング（XP） 運動によって普及した手法だ。

後述するように、CI設定における大きな不満点は フィードバックループがローカル作業より大幅に遅いことだ。 進捗に応じて、可能な範囲でこれを最適化する方法を模索する。

デバッグ作業では再現性のテーマにも触れる。これはCI環境の挙動をローカルで再現できるようにする考え方だ。本番環境と開発環境を可能な限り類似性を持たせるのと同様の試みである。

現代の開発ワークフローにおけるCI

我々がCIを利用する理由はいくつかある：

• 前述の通り、このテストスイートは、 ローカルで実行するには大きくなりすぎた場合でも、 辛抱強くフルスイートを実行できる。

• デプロイ／リリースプロセスにおける「ゲート」として機能し、 全てのテストを通過していないコードがデプロイされるのを防ぐ。

• プルリクエストワークフローを採用するオープンソースプロジェクトでは、 未知の貢献者から提出されたコードをマージする前に、 全てのテストを通過させる手段となる。

• 企業環境では（残念ながら）このプルリクエストプロセスと関連するCIチェックが、 チームが全てのコード変更をマージするデフォルトの方法として使われるケースが増えている。¹

CIサービスの選択

初期のCIは、サーバを構成することで実装されていた。 （おそらくオフィスの隅の机の下に置かれたサーバだ） そのサーバには、毎日終了時にメインブランチから全コードを取得するソフトウェアと、全コードをコンパイルし全テストを実行するスクリプトがインストールされていた。 このプロセスは「ビルド」と呼ばれるようになった。 そして毎朝、開発者は結果を確認し、失敗したビルドに対処していた。

この手法が広まり、フィードバックサイクルが速くなるにつれ、CIソフトウェアは成熟した。CIは今や一般的なクラウドベースのサービスとなり、GitHubのようなコードホスティングプロバイダーとの統合を想定して設計されている。あるいは、同じプロバイダーがディレクトリを提供している場合もある。GitHubには「GitHub Actions」があり、まさにそこに存在するため、おそらく最近のオープンソースプロジェクトで最も人気のある選択肢だろう。 企業環境では、CircleCI、Travis CI、GitLab などの他の解決策に出会うこともあるだろう。

CI サーバをダウンロードして、自分でホストすることは、今でもまったく可能だ。 この本の第 1 版と第 2 版では、当時人気があったツールである Jenkins の使用法を紹介した。 ...