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

継続的インテグレーションは、ソフトウェア開発において一般的な手法です。カンファレンスでは多くの開発者がその利用方法について語り、ほとんどの開発組織で継続的インテグレーションツールが使われています。しかし、優れた手法には認定プログラムが必要であることは周知のとおりです。幸いにも、それは存在します。継続的デリバリーとDevOpsにおける第一人者の一人によって開発され、その結果として非常に迅速に管理できるにもかかわらず、非常に洞察に満ちたものであることで知られています。成熟した技術ではありますが、十分に知られていないため、この手法のファンとして、この認定プログラムを読者の皆さんと共有することが重要だと考えました。継続的インテグレーションの認定を受ける準備はできていますか？そして、テストを受けることで明らかになる衝撃的な真実にどのように対処しますか？

私の記事を定期的に読んでいる読者は、これがパロディ記事ではないかと思っているかもしれません[1]。確かに、少し茶化して冒頭の紹介文を書きました。しかし、どんな良いジョークにも真実の核が隠されています。適切な継続的インテグレーションのための驚くほど優れたテストは、Jez Humbleによって作成されました。彼は確かに継続的デリバリーの第一人者です。それはまた迅速なテストであり、彼はしばしば講演中に聴衆に実施します。唯一の問題は、彼がそれを認定テストとして言及しているのを聞いたことがないということです。これは、彼が金儲けの計画に対するビジョンを欠いていることを示しています。

彼は通常、継続的インテグレーションを実施している場合は手を挙げるよう聴衆に求めることから認定プロセスを開始します。通常、聴衆のほとんどが手を挙げます。

次に、チーム全員が少なくとも毎日、共有メインライン（通常はgitの共有master）にコミットしてプッシュしている場合は、手を挙げたままにするように求めます。

半数以上の手が下がります。

次に、そのようなコミットごとに自動ビルドとテストが実行される場合は、手を挙げたままにするように求めます。残りの半分の手が下がります。

最後に、ビルドが失敗した場合、通常10分以内にグリーンに戻るかどうかを尋ねます。[2]

最後の質問で、残っている手はごくわずかです。それらは彼の認定テストに合格した人々です。

それはシンプルな質問のセットですが、継続的インテグレーションの本質を捉えています。全体の考え方は、誰も他の人とは大きく異なるコードベースで作業していないということです。継続的インテグレーションとは、チームがコードの現状を真に把握し、大規模でリスクの高いマージを回避し、人々が必要なだけリファクタリングできることを意味します。

非常に多くの人々が最初に手を挙げる理由は、継続的インテグレーションがフィーチャーブランチに対して「継続的インテグレーションサーバー」を実行することを意味するという一般的な見方があるからです。しかし、エクストリームプログラミングの一部としてKent Beckによって最初に記述され命名された継続的インテグレーションは、ツールとは何の関係もありません。当初は人間のワークフローであり、Jim Shoreは優れた議論を行い、それがそうあるべきだと主張しました。ソースコードリポジトリに対してデーモンプロセスを実行するという考えは後になって生まれました。それは有用ではありますが、人々が毎日コミットする共有メインラインで実行される場合にのみ、継続的インテグレーションです。それ以外の場合、たとえばすべてのフィーチャーブランチでそのようなプロセスを実行することは、名前を貶めるCIシアターであり[3]、努力に見合うメリットをもたらさないワークフローを生み出します。