継続的デリバリーができていない10の兆候

この記事でご紹介する開発プラクティスの多くは、当たり前のように感じられるかもしれません。しかしこれらを行っている場合、実は継続的デリバリーを全く行っていないことになります。

この記事でご紹介する開発プラクティスの多くは、当たり前のように感じられるかもしれません。しかしこれらを行っている場合、実は継続的デリバリーを全く行っていないことになります。ここでは、チームを助ける10のテクニックを学んでみましょう。

1. 「アジャイル」会議で「リリース」が詳細に計画される

継続的デリバリー（CD）とは、"1年を通して12回のリリースを緻密に計画する "という意味ではありません。継続的デプロイとは、終わりのない、継続的な、ノンストップな、といった意味です。アジャイルは、毎月のリリースサイクルが貴重と考えられていた10年前に、開発チームが達成を熱望していたものです。現在は毎日の本番デプロイが当たり前になっています。リリース管理に関連する全ての計画、会議、承認、チケット、また一般的なポリシーは、今日の世界では実際にあなたのビジネスを遅くするか、止めてしまうでしょう。

2022年、全ての競合他社が自動車に乗っているときに、馬に乗っていたいとは思わないでしょう。

2. Trunkにコミットしない

ブランチ、コミット、マージ、コンフリクトの解決、これら全てのタスクは作業を遅らせます。CDの要点は、独立したソフトウェアコンポーネントを、並行して働く開発チームを使って、速く、頻繁に配布し、デプロイすることです。

ビルド、テスト、デプロイのパイプラインが失敗したら、中断し、何が起こったかを理解し、それを修正し、そこから学ぶべきです。これは本番環境で起こっていることで、なぜ開発中やテスト中に起こらないのでしょうか？Trunk にコミットすることで、CD に必要な正しいチームの行動と緊急性を促すことができます。

3. ビルド／デプロイメントの修正に30分以上かかる

デプロイメントパイプラインの要点は、本番環境が停止する前にビルドを終了させることです。デプロイメントパイプラインやテストが失敗した場合、それは”stop-the-world”イベントとして扱われるべきで、全員が停止し、集中し、ビルドを修正し物事を進めるようにします。本番環境のカナリアやデプロイに障害が発生した場合、即座にロールバックするか、迅速な修正で前進させることができるはずです

今日もHarnessでは、迅速なロールバックを実践しています。Harnessで発見されたバグは、数時間ではなく数分で修正されます。あるとき、午前8時45分にバグが報告され、あるエンジニアがその数分後に通勤中のCaltrainでバグを修正したことがあります。その直後、別の開発者がスマートフォンを使ってBARTに乗りながら修正をプッシュしました。

4. デプロイメントパイプラインの完成に数時間かかる

新しいビルドやアーティファクトが完璧であるとします。そのアーティファクトがすべてのデプロイメントパイプラインの段階（開発、QA、ステージング）を経て本番環境に昇格するまでに、どれくらいの時間がかかりますか？1時間？2時間？6時間？もっと長いですか？

デプロイメントパイプライン（およびステージ）のフィードバックループは、数時間単位ではなく、数分単位で行われる必要があります。そのためには、テスト／ツール／フィードバックの自動化を進め、デプロイメントパイプライン全体で手動タスクと承認を排除できるようにします。例えば、あるパイプラインのステージが成功したら、ステージが失敗するまで自動的に次のステージに移行する必要があります。

5. デプロイがテストで失敗することはほとんどない

デプロイの95%が開発/QA/ステージングで成功した場合、何かが間違っています。デプロイメントパイプラインに基本的なテストカバレッジが欠けているか、既存のツールセットと統合されていないかのどちらかです。ツールに多額の資金を投資しているのであれば、なぜそれらを統合して活用し、パイプラインを把握しないのでしょうか？

例えば、多くのお客様がAPM（AppDynamics、New Relic、Dynatraceなど）やログ分析（Splunk、ELK、Sumo Logicなど）を活用して、デプロイにおけるパフォーマンスや品質の低下を特定するのに役立てています。Harnessではこれを「継続的検証」と呼んでいます。

6. デプロイとデバッグに何人もの人を必要とする

デプロイプロセスを自動化する可能性は十分にあります。自動化というのは、20人の異なる担当者が書いたデプロイスクリプトをつなぎ合わせて、ある段階で数百行を微調整したりリファクタリングしたりしたことを意味します。

そのため、何か問題が発生すると、デプロイのデバッグとトラブルシューティングに何人もの人が必要になります。あるお客様は、以前のデプロイプロセスを「村の運動」と表現し、15人で6時間かけてデバッグしたそうです。
 

次にデプロイするときは、関係者の数を数え、その数にデプロイプロセスの所要時間をかけてみてください。人材を総動員するデプロイは、お金も時間もかかります。

7. 専任のデプロイ／リリースチームを持っている

複数の開発チームや製品チームがある場合、避けるべきことは、デプロイのボトルネックとなるチームを持つことです。チケット、変更管理、承認、ハンドオフ、ドキュメント作成など、デプロイのタイムラインを遅らせるアクティビティーがさらに増えていくためです

デプロイ／リリース チームが 1 日に複数のデプロイを行い、最初のデプロイがうまくいかなかった場合、おそらく次の 6 時間をデプロイとデバッグに費やすことになり、他のデプロイメントパイプラインのボトルネックになります。これは、顧客の要求に応えるチームの能力を低下させるだけです。

8. 開発者が自分のコードをデプロイ／デバッグしない

CI/CDがうまく機能している組織の多くは、DevOpsチームがデプロイ時に使用するデプロイメントパイプラインを構築しています。大切なことなので、もう一度お伝えします。DevOpsはツール／自動化／フレームワークを管理し、開発者はこのPlatform as a Serviceを利用して、自分たちのコードをデプロイできるようにします。Harnessでは、これをCD-as-a-Serviceと呼んでいます。

開発者が自分のコードをデプロイできるようにすると、何か不具合があったときに、開発者が自分のコードをデバッグするようになる、ということが自然に起こります。これは非常によいことです。もしコードが本番環境で失敗した場合、迅速にトラブルシューティングを行うには、適切な目、状況、知識が必要です。また、ロールバックができない場合は、自動的にロールバックする機能も必要です。

デプロイがうまくいかないと、デプロイ／リリースチームがDevOpsチームやSREチームの足を引っ張ってしまうという話を、お客様からよく聞きます。

9. 導入のビジネスインパクトが分からない

CI/CDを行う理由は、人材や技術、ツールに莫大なお金をかけるためではありません。ビジネスを成長させ、競争力を高めるために行うのです。

組織はCI/CDを導入することで、アプリケーションやサービスが競合他社よりも優れたサービスや体験を提供できるようになります。それ以上でも以下でもありません。

あなたのビジネスのために新しいサービスに毎月100万ドルを費やし、あなたのチームは毎日本番デプロイを行っていると想像してみましょう。そのようなデプロイが、あなたのビジネスにどのようなプラスの影響を与えたのでしょうか？さらに重要なこととして、デプロイによるマイナスの影響を知っていますか？もしそうなら、どの程度でしょうか？Winston Churchillも、"どんな戦略であっても、時折その結果を見るのはよいことだ"という言葉を残しています。

10. DevOpsをCDだと思っているあなたへ

そうではありません。DevOpsは文化や考え方であるのに対し、CDは安全、迅速、かつ持続可能な方法でソフトウェアを提供するためにチームが従うプラクティスや原則のセットです。DevOpsの文化はCDの原則を容易にしますが、魔法のようにアプリケーションを再設計し、より多くのコンポーネントをより頻繁にクラウドにデプロイできるようにするものではありません。

Harnessのお客様の大半は、「ビンテージ」なモノリシック・アプリケーションからクラウド・ネイティブなマイクロサービスへ移行しています。CI/CDは、その移行を支援する中核となる取り組みです。DevOpsはよく知られた取り組みですが、これは人、文化、透明性、そしてチーム間のコラボレーションが重要なのです。ツールやテクノロジーの問題ではありません

Harness付きCDの採用

以上が、組織がCDを適切に活用していないことを示す、最も一般的な10の兆候です。他のチームはどのような間違いを犯しているでしょうか？

HarnessがあなたのチームにCDを導入するお手伝いをする方法についてもっと知りになりたい場合は、今すぐ無料デモにお申し込みください。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。