標準化されたCI/CD：パイプラインは統一されたが、手作業が多すぎる

パイプラインはある。全チームがそれを使っている。コードを入れるとビルドが走り、テストが実行され、デプロイが行われる。しかし、本番に変更を反映させるのは、いまだに歯を抜くような苦痛を伴う。パイプラインは存在するが、プロセスが遅い。誰かがすべての変更を承認しなければならない。QAはステージング環境を手動でテストしなければならない。本番デプロイには、誰かが決まった時間にコマンドを実行したり、ボタンをクリックしたりする必要がある。

これがCI/CD成熟度モデルのレベル2「標準化」である。組織は、各自がバラバラにやっていた混沌とした状態からは脱却した。共有パイプラインがあり、一貫性がある。しかし、デリバリーを遅くしている手作業がまだたくさん残っている。

標準化された状態とは

このレベルでは、パイプラインはもはや謎ではない。すべてのチームが同じフローに従う。コミット、ビルド、テスト、ステージングへのデプロイ、そして最終的に本番へ。誰も自分のラップトップで異なるツールや設定を使ってビルドすることはない。ビルド環境は統一され、テスト手順は定義され、デプロイプロセスは文書化されている。

しかし、ここに落とし穴がある。パイプラインはステージングで止まる。あるいは、手動承認が必要になる。または、誰かがスクリプトを実行する必要がある。自動化は存在するが、不完全である。重要なステップには人間が介在し続けている。

以下の図は、このレベルでの典型的なパイプラインの流れを示しています。手動のステップは赤で強調表示されています。

承認のボトルネック

このレベルでの最大の速度低下要因の一つは、承認プロセスである。本番に到達したいすべての変更には、特定の人物またはグループからの承認が必要である。その承認は、メール、チャットメッセージ、または簡単なミーティングを通じて行われるかもしれない。しかし、それが迅速に行われることはほとんどない。

承認する必要がある人物は、別の会議中かもしれない。休暇中かもしれない。インシデント対応で忙しいかもしれない。あるいは、何か問題が起きたときに責任を負いたくないだけかもしれない。そのため、変更はパイプラインの中で待機したままになる。数時間が数日に変わる。パイプライン自体は準備ができているが、プロセスが追いついていない。

これはツールの問題ではない。世界最高のCI/CDプラットフォームを持っていても、すべてのデプロイに人間の「はい」が必要なら、人間の可用性によってボトルネックが発生する。

手動テストが依然として存在する

標準化レベルのもう一つの兆候は、すべてのテストが自動化されているわけではないことだ。単体テストや結合テストはパイプラインで実行されるかもしれない。しかし、特定のシナリオでは、QAがステージング環境にログインし、テストケースを手動で実行し、レポートを作成する必要がある。

これによりサイクルが発生する。開発者が変更をプッシュする。自動テストはパスする。しかし、QAは機能を手動で検証しなければならない。問題が見つかれば、変更は開発者に戻される。開発者が修正し、再度プッシュし、QAが手動テストを繰り返す。イテレーションごとに時間がかかる。

問題は手動テストが無価値だということではない。複雑なユーザーフローやエッジケースなど、自動化が難しいものもある。問題は、小さな変更であっても、すべてのデプロイ前に必ず通過しなければならないゲートとして手動テストが扱われていることだ。これにより、デリバリープロセス全体が遅くなる。

デプロイは依然として手動ステップ

パイプラインが標準化されていても、本番へのデプロイは手動操作のままであることが多い。パイプラインが自動的にビルドとテストを行っても、本番にプッシュする段階になると、誰かがコマンドを実行するか、ダッシュボードでボタンをクリックしなければならない。

一部の組織では、今でもリリーススケジュールに従っている。パイプラインはいつでもデプロイできる準備ができているのに、週に一度または月に一度しかデプロイしない。その理由は多くの場合、恐れである。完全な自動化とプロセスへの確信がないため、チームは変更をまとめ、全員が問題に対処できるスケジュールされた時間帯にデプロイすることを好む。

これは理解できるが、パイプラインを持つ意味を損なっている。パイプラインは迅速にデプロイする能力を与えるが、プロセスがその能力を使うことを妨げている。

ドキュメントは存在するが、役に立っているか？

標準化レベルでは、ドキュメントが登場し始める。デプロイ方法、ロールバック方法、一般的なエラーの対処方法を説明したWikiページがあるかもしれない。しかし、このドキュメントはしばしば古くなっている。あるいは不完全である。あるいは、人々はそれを読むよりも同僚に尋ねる方を好む。

問題は、ドキュメントがプロセスの一部としてではなく、別個の成果物として扱われていることだ。一度書かれて、その後忘れられる。何かが変更されても、ドキュメントは更新されない。新しいメンバーがチームに加わると、ドキュメントからではなく、他のメンバーから学ばなければならない。

良い点：一貫性

これらすべての問題にもかかわらず、標準化レベルは前のレベルからの大きな改善である。最大の利点は一貫性である。すべてのチームが同じパイプラインを使用するため、ビルドとテストの結果は信頼できる。ビルドが失敗した場合、全員にとって同じ方法で失敗する。「自分のマシンでは動く」ということはもうない。すべての変更が同じ経路を通るからだ。

この一貫性により、デバッグが容易になる。何か問題が発生したとき、チームはどこを見ればよいか分かっている。パイプラインのログは標準化されている。環境設定は同じである。テスト手順は予測可能である。これにより、トラブルシューティングに費やす時間が減り、プロセスへの信頼が高まる。

悪い点：依然として遅い

しかし、欠点は明らかだ。手作業が多すぎると、すべてが遅くなる。手動のステップはすべて待機ポイントである。承認、手動テスト、手動デプロイ、時代遅れのドキュメント — これらすべてが、コードを書いてからユーザーに価値を届けるまでの時間を増やす。

このレベルのチームは、進歩したと感じることが多い。パイプラインがある。一貫性がある。しかし、デリバリーがまだ速くないことに不満を感じている。もっと良くできると分かっているが、どうすればそこに到達できるか確信が持てない。

レベル2のための実用的なチェックリスト

もしあなたがこのレベルにいるなら、以下を確認してみてほしい。

• すべての承認ステップは本当に必要か？テスト結果に基づいて自動化できるものはないか？
• どの手動テストを自動化してパイプラインに追加できるか？
• すべてのテストに合格した場合、本番へのデプロイを自動的にトリガーできるか？
• ドキュメントは、別タスクとしてではなく、デプロイプロセスの一部として更新されているか？
• チームはデプロイする前に誰かを待つ必要があるか？

これらの質問は、最大のボトルネックを特定するのに役立つ。目標は、すべての手作業を一度に排除することではない。最も遅延を引き起こしているステップを見つけ、一つずつ減らしていくことだ。

次のステップ：セルフサービス

標準化レベルは橋渡しの段階である。組織には正しい基盤がある。パイプラインは存在する。プロセスは一貫している。しかし、その潜在能力を最大限に活用できていない。次のステップは、チームが他者を待つことなく自分たちのデプロイを管理できるようになるまで、手作業を減らすことだ。

それがセルフサービスレベルである。チームは必要なときにデプロイでき、自動チェックが手動ゲートに取って代わる。承認はデフォルトではなく、例外ベースになる。テストは可能な限り自動化される。ドキュメントはプロセスから生成され、別途作成されることはない。

しかし、そこに到達する前に、パイプラインを持つことと高速なデリバリーを持つことは同じではないと認識する必要がある。標準化は一貫性をもたらす。次のステップはスピードをもたらす。

まとめ

標準化されたパイプラインは良いスタートだが、ゴールではない。チームが共有パイプラインを持っているにもかかわらず、承認の遅さ、手動テスト、スケジュールされたデプロイに依然として苦しんでいるなら、あなたはレベル2にいる。パイプラインの準備はできている。プロセスが追いついていない。今やるべき仕事は、デリバリーを遅くしている手動のステップを取り除くことだ。