HoneycombのCTOであるCharity Majors氏の投稿は、人々がCI/CD (継続的インテグレーションと継続的デプロイメント) について話すとき、彼らが継続的インテグレーション (CI) についてのみ話しており、それでは十分ではないと主張し、継続的デプロイメント (CD) に関する議論を再開した。
議論では、その重要性だけでなく、実際にそれを使用している組織の数もカバーした。Majors氏は、CDがないと、開発者はコードを評価し改善するのに必要なタイムリーなフィードバックを得ることができないと書いている:
その間隔が機能的なフィードバックループになるのに十分短くなるまで、あなたがすることは機能不全の兆候を管理することだけです。遅延が長ければ長いほど、これらの兆候がより多く現れ、チームが障害対応に走り回るのにより多くの時間を費やします。
チームが更新をバッチ処理してデプロイを手動で実行すると、Majors氏は「ソフトウェア開発の死のスパイラル」につながると話す。タイムリーなフィードバックがないと、プロセスはより困難になる一方で、新しいコードのリリースに必要な時間が長くなる。したがって、チームは追加された複雑さを管理するためにより多くのリソースを必要とする。Majors氏は、このサイクルの中断または断ち切る最善の方法は、CDを使用してバッチを解消し、より高速なフィードバックサイクルを作成することだ。
Travelersのソフトウェアエンジニアリング担当副社長であるEster Peña氏は、コードをプロダクション環境にデリバリーする時間の短縮と、緊密なフィードバックループを強調した:
アプリは、30分以内にPRからプロダクション環境に移行する必要があります。
もちろん、できます。もちろん、規制の厳しい業界でもそうです。私はダウ30の保険会社で働いていますが、できます。
Majors氏の投稿は、Hacker Newsで活発な会話を引き起こした。あるスレッドは、CDを使用しているチームがごくわずかであることが本当に真実かどうかを質問するコメント投稿で始まった:
私は過去... 15年間、CIとCDを行うチームやプロジェクトに携わってきました。
確かに、私たちのデプロイメントプロセスは、最良の場合 (異なるブランチのデプロイメントをシリアル化するため) 10〜15分でしたが、集合的な「私たち」がCDを実行していないという著者の印象はどこから来るのでしょうか。
このスレッドに対するいくつかの回答は、大規模なチームがCDに必要なコードの迅速なマージとビルドをうまくネゴシエートできるかどうかを尋ねた。他の人々は、厳しく規制された業界でCDが可能かどうか疑問を呈した。しかし、あるコメント投稿者の回答は、そもそもなぜCDを実装する必要があるのかという疑問を提起した:
ただし、技術/エゴのベンチマークとしてCDを使用しないでください (またはFacebook / Googleへの憧れ)。これがビジネスにいくつかのメリットをもたらすことに同意できる場合は、それを実行してください。例えば、リスクの軽減、スループットの向上などです。また、本当により高速にデリバリーするには、プロセスのボトルネックを調査し、オーバーヘッドを取り除く必要があります。私はブログのこのラインが本当に好きです:
「CI/CDを達成したチームは、他のチームよりも優れたエンジニアですが完成していません。あなたに約束します。彼らは私たちの他のメンバーよりもプロセスにもっと注意を払っているチームです。」
数年前、『Continuous Delivery (継続的デリバリー)』の共著者であるJez Humble氏は、Software Engineering Radioとのインタビューで、より高速なコードデリバリーに移行するための文化的および工学的なボトルネックについて説明した:
... これは開発者にとって大きな文化的変化です。しかし、これは非常に重要なフィードバックループでもあります。開発者が完全なコードを開発するだけでなく、プロダクション用のコードを準備することの意味を理解する必要があることを意味します。そして、それは開発者が実際にそれを理解するために非常に重要です。なぜなら、スケーラビリティと可用性、有用なログメッセージの書き込み、ページや例外のページだけでなく、データのアーカイブなどの関心事について本当に考える必要があるからです。開発者は、これらの関心事を念頭に置いてソフトウェアを構築する必要があります。
独立したソフトウェアコンサルタント兼スピーカであるPete Hodgson氏は、組織のニーズによっては、CDの背後にある努力はそれだけの価値がないかもしれないと主張している:
しかし、人を追い出すのは費用がかかることがわかりました。テストとデプロイメントのプロセスを完全に自動化するには、多額の投資と継続的な投資が必要です。テストとデプロイだけでなく、変更をロールアウトした後、エンジニアがプロダクションのメトリックを目視するだけに頼ることができなくなるため、洗練されたプロダクションの監視とアラートも必要です。
Majors氏の投稿はいくつかの活発な会話を引き起こしたが、チームがCI/CDを新しい質問ではないと言ったときに、継続的インテグレーションと継続的デプロイの両方を本当に意味しているのかどうか。OTomatoのCEOであるAnton Weiss氏は、2020年に「自分をだますのをやめよう、私たちがCI/CDと呼んでいるのは実際はCIだけ」というタイトルの投稿をした。彼はMajors氏と同じく、CI/CDのCD部分を実際に実装しているグループはほとんどないと主張した:
すべての変更をプロダクション環境に安全かつ定期的にデプロイすることを妨げるものは何かと尋ねられたとき、誰もが独自の理由を持っているようです。組織的、文化的、歴史的、技術的、契約的.. 「ああ、継続的デリバリーは必要ありません。実際、ほとんどの企業は実際にはそれを必要としない」と言って否定する人までいます。
CDをめぐる議論は、多くの分野をカバーしている。「真の」CI/CDとは何かについて議論する人もいれば、一部の業界や状況では実用的ではない、または不可能であると主張する人もいる。