（この記事は、CloudBees社 Blog 「7 Ways to Know You’ve Aced Continuous Integration」2018年3月9日 Brian Dawson 投稿の翻訳記事です。）
昨年のJenkins Worldで個人的に印象に残った場面の1つは、Jez Humbleの基調講演で、どれだけの人が本当に継続的インテグレーション（CI）を実践できているかについて、聴衆に挙手で示してもらったときのことでした。その場には、他のどんな場所でも集められないほど熱心なDevOpsのプロばかりが集まっていたので、全員が完全に継続的インテグレーションをマスターしていると思ったとしても不思議はありませんでした。
Humbleはいくつかの重要な質問をしました：
- 組織のメインパイプラインに定期的にフィードバックをしていない人はいますか？
- 10分以内にソフトウェアの問題を修正できない人はいますか？ できない人、しない人は手を下げてください
- 質問のたびに、かなりの人が手を下げていきました。最終的には、ほんのわずかな数の手だけが上がっていました。そのすべてはJenkinsユーザーでした。
Humbleが伝えたかったことは：継続的インテグレーションを実践していると思っている人のうち、かなりの割合の人が、実際には正しく実践できていないということです。
Humbleは聴衆に向けて「継続的インテグレーションは本当に難しい」と語りました。「多くの人々が、自分たちがすでにやっていることに合わせて、継続的インテグレーションの定義を修正してしまいます」
本当に継続的インテグレーションができているか？これは重要な問題です。なにしろ、継続的デリバリー（CD）とDevOpsは市場をゆるがし、企業に大きな競争優位性をもたらしています。継続的デリバリーは、継続的インテグレーションという実証済みの正しいプラクティスの上に構築されます。継続的デリバリーの利点を理解しようとする企業が、継続的インテグレーションの概念を完全に理解するという時点でつまずいていることがよくあります。
Jenkins Worldの基調講演でHumbleが述べたように、継続的インテグレーションを正しく行っている組織は、必ずいくつかの基本的なルールに従っています。たとえば、開発者の作業コピーは少なくとも1日に1回、できれば1日に数回、共有のメインラインと同期されます。各インテグレーションは自動化されたビルドによって検証され、できるだけ迅速にエラーを検出します。これらの手順に従っていない組織は、実際には継続的インテグレーションを適切に行えていません。
継続的インテグレーションは開発チームのプラクティスですが、組織全体に実質的な利益をもたらします。継続的インテグレーションの実現を担当するエンジニアは、そのような利益を達成するために、他の組織が行っている最新のプラクティスを模倣しようとします。しかし実現の過程で問題に突き当たるのです。
彼らは、他の組織がどのように継続的インテグレーションを実施しているかについて聞き、自分の組織内で同じことをできるかどうかを判断します。しかし、すべての組織はそれぞれ異なっています。DevOpsチームは、自社内での理想的な継続的インテグレーション像を思い描いているかもしれませんが、それは一般的に受け入れられているCIの定義に厳密には収まらない場合があります。
継続的インテグレーションの基本原則に従っていない組織は、正しく機能する最新のビルドを定期的に提供するのは難しい という問題に陥ることでしょう。時間が経つにつれて、イニシアチブは勢いを失い、チームメンバーは消極的になっていきます。変化に抵抗感のある人々（だいたいの人がそうです）は、変化の恩恵が目に見えなければ、どんな小さな変化でも受け入れられず、古い習慣に戻ってしまうでしょう。そうなると、たくさんの問題がでてきます。ビルドは依然としてエラーだらけ。チームは継続的インテグレーションへの信頼感をなくします。致命的なまでに時間を無駄にしてしまったので、プロジェクトを立て直す必要があります。
継続的インテグレーションを正しく実装していない組織は、しばしば文化的な問題に直面します。エンジニアは技術的な問題を解決するのに長けていますが、CIに必要なのは文化の転換です。文化は変わりにくいものです。継続的インテグレーションツールを導入すれば、CIの特徴を表すチェックリストのほとんどの項目にチェックを付けることができるでしょう。しかしCIを成功させるには、どのように作業し、 どのように連携するかを変える必要があります。 チームの文化が変わらなければ、継続的インテグレーションを実現する過程で困難にぶつかるでしょう。
結論：継続的インテグレーションを行うことは、上等なスーツの上にレインコートを着るようなものです。継続的インテグレーションの原則が提供するレインコートがプロジェクトを保護してくれるという確信があるからこそ、厳しい納期に対応し、会社がリリースする新しいアプリケーションがすばらしいものになると約束できるのです。レインコートが防水でなければ、スーツはだいなしです。CIもこれと同じです。プロジェクトを水に対して無防備にしておけば、水没してしまうのです。
正しく整備されたCIプロセスはエラーを完全に排除するように聞こえるかもしれませんが、実際はそうではありません。継続的インテグレーションそのものは、エラーを許容するように設計されたプロセスです。求めるのは、開発者が頻繁に（そしてすみやかに）失敗できるシステムを作り、エラーを早期にすばやく修正できるようにすることです。継続的インテグレーションは、強風が吹く道に設けられたガードレールのようなものです。開発者は、ビルドが路肩に近づきすぎても安全に保護されるため、安心してスピードを出すことができます。
継続的インテグレーションの基本原則とプラクティスは、マーティン・ファウラー（Martin Fowler）が継続的インテグレーションという用語を導入したときから、少なくとも15年の歴史を持っています。正しくCIを実践するために組織が従うべき7つのプラクティスを以下に示します。
- メインラインへのコミット：これは継続的インテグレーションの基本中の基本です。コミットのたびにビルドを実行するよう自動ビルドをセットアップするのは簡単です。しかし、頻繁にコミットする文化がなければ、何の役にも立ちません。開発者が3週間コミットを控えていたり、3週間にわたってブランチで作業していたなら、インテグレーションを遅らせているということであり、原則に違反しています。ビルドが壊れた場合、どこで壊れたかを突き止めるのに、3週間分の作業をしらみつぶしに調べなければなりません。
- 単一のソースリポジトリの維持：複雑なアプリケーションでは、開発者はブランチを作成して、トランク（ブランチ）またはメインから変更を隔離することがよくあります。ブランチは複雑さを増大させ、全員が単一のソースに基づいて作業するのを防ぎます。チームは少なくとも1日に1回、できれば変更のたびにトランクまたはメインにコミット/マージする必要があります。
- ビルドの自動化：これは、ほとんどの組織でうまくいっているプラクティスです。しかし、CIを行っていると主張する人の中には、スケジュール化されたビルド（つまり夜間ビルド）を実行しているだけだったり、継続的にビルドしているものの、各ビルドをテストまたは検証していないというケースがあります。ビルドを検証していなければ、継続的インテグレーションを行っているとは言えません。
- ビルドへ自己テストを組み込む：検証プロセスの第一歩は、問題があるビルドは確実に失敗するとわかることです。次のステップは、ビルドの成果物が動くかどうか、およびビルドが期待どおりに動作しているかどうかを判断することです。このテストは、ビルドプロセスの一部として含める必要があります。テストは、高速な機能テストおよび非機能テストで構成されます。
- すばやくビルドする：アプリケーションのビルドに時間がかかりすぎると、開発者は頻繁に変更をコミットすることを嫌ったり、変更をまとめてコミットするようになります。どちらの場合も、エラーの原因をすばやく突き止めるのが不可能になります。すばやくビルドし、すばやく統合することで、変更をすばやく分離することができます。実行に時間がかかると、その間にさらに何十件もの変更が発生する可能性があり、問題をすばやく見つけるのが難しくなるでしょう。
- クローンでのテスト：検証プロセスは、意図した環境でソフトウェアが期待どおりに機能するかを検証します。別の種類の環境でテストすると、結果が間違っている可能性があります。
- 壊れたビルドをただちに修正する：開発チームが問題を早急に見つけ出し、ただちに修正することが重要です。昔、トヨタは作業員が問題を発見したときにロープを引っ張って製造プロセスを止めることができる「Stop the Line」方式を導入しました。CIは、ビルドが検証され、継続的にコミットされるプロセスを構築します。そのため、何か問題が生じた場合も、修正するのは簡単です。
組織が真の継続的インテグレーションを実現する上で、直面するさまざまな課題があるにせよ、ソフトウェア開発コミュニティが、業務の真の価値を創出する最新のプロセスに従って、どれほど長い道のりを歩んできたかを知ることは重要です。変革を起こし、DevOpsプラクティスを改善するために多くの人たちが努力しています。CIの最大の障害は、レガシー技術に対する文化的、感情的、技術的な愛着です。これらは変化の敵です。「『できない』と言う文化」を乗り越えられたとしても、伝統的な習慣という重荷を背負ったまま進むのは大きな邪魔になります。
組織が直面するもう1つの課題は、手持ちの札を実際以上によく見せようとすることです。誰もがCIのような方法論を使用して業務を変革したいと考えていますが、自分たちのプロセスにはまだまだ改善の必要があるということを正直に話したがる人はほとんどいません。
継続的インテグレーションが業界用語になってから10年以上が経ちましたが、これを正しく行うための努力は今も続いています。