チームごとにデプロイ方法が異なる問題
多くのエンジニアリング組織において、デプロイは共有された機能ではありません。それは個々の習慣の集まりです。チームAは誰かのラップトップから実行されるシェルスクリプトを持っています。チームBは2年前に構築されたパイプラインを持っていますが、壊れるのが怖くて誰も触りません。チームCは、あるシニアエンジニアが慣れていたという理由で、まったく異なるツールを使用しています。結果は予測可能です。デプロイに一貫性がありません。あるチームは5分でリリースできますが、別のチームは2時間かかります。あるチームは自動ロールバックを備えていますが、別のチームは手動でバックアップから復元しなければなりません。
この状況はスキルの問題ではありません。共有されたデプロイシステムが存在しないことが問題です。各チームが独自のデプロイパスを構築すると、組織はすべてのデプロイが同じ安全チェックに従うことを保証する能力を失います。あるチームではセキュリティスキャンがスキップされるかもしれません。別のチームでは統合テストがオプションかもしれません。承認プロセスも異なります。そして何か問題が発生したとき、問題がコード、設定、それともデプロイプロセス自体のどれにあるのかを特定するのが難しくなります。
認知負荷の問題
チームがデプロイ方法について考えなければならないたびに、実際に重要なこと、つまり機能が正しいか、データベースの変更が安全か、インフラストラクチャの設定が適切か、という点から集中力がそがれます。デプロイはルーティンではなく、気を散らすものになります。
これは、アプリケーションコードとインフラストラクチャの両方を扱うチームにとって特に厄介です。設定すべき環境変数、ローテーションすべきシークレット、実行すべきマイグレーションスクリプト、そしてそれらを実行する順序を覚えておかなければなりません。精神的オーバーヘッドは積み重なります。そして何かを忘れるとデプロイは失敗し、チームは製品の修正ではなくプロセスのデバッグに時間を費やすことになります。
問題はチームが不注意であることではありません。問題は、デプロイに関する知識が個人、スクリプト、そして時代遅れのドキュメントに散在していることです。単一の情報源は存在しません。毎回のデプロイが新たに解決すべき問題のように感じられます。
ツールではなくサービスとしてのプラットフォームエンジニアリング
プラットフォームエンジニアリングは、すでにテストされ、安全で、使いやすいデプロイパスを提供することでこの問題に対処します。考え方はシンプルです。チームはデプロイ方法を理解する必要はありません。環境設定、バージョントラッキング、ロールバック手順について心配する必要もありません。プラットフォームがそれらの懸念事項を処理します。
しかし、プラットフォームはツールではありません。それはサービスです。チームはプラットフォームがJenkins、GitLab CI、GitHub Actions、その他何で動作するかを気にしません。彼らが気にするのは、プラットフォームが安全かつ迅速に、そしてすでに処理されるべきことを考えずにデプロイするのに役立つかどうかです。プラットフォームが複雑すぎたり、硬直的すぎたりすると、チームは独自の回避策を見つけるでしょう。そして組織は一貫性のないデプロイという出発点に戻ります。
優れたプラットフォームはゴールデンパスを提供します。それは最も推奨されるデプロイ方法であり、ほとんどのチームにとってほとんどの場合に機能します。しかし、特定のニーズを持つチームのためのカスタマイズも可能にします。コンプライアンス要件の厳しいアプリケーションを扱うチームは、追加の承認ステップが必要かもしれません。リスクの低い内部ツールに取り組むチームは、より迅速にデプロイできるかもしれません。プラットフォームは、すべてのチームにゼロからすべてを再構築させることなく、これらの違いに対応する必要があります。
デプロイプラットフォームが実際に提供するもの
デプロイプラットフォームは単なるパイプラインではありません。それは、チームがゼロからインフラを構築することなく利用できる一連の機能です。実用的なプラットフォームが通常含むものは次のとおりです。
例えば、再利用可能なGitLab CIジョブテンプレートは次のようになります。
.deploy-template:
stage: deploy
script:
- run-security-scan
- run-integration-tests
- deploy-canary --percentage 10
- wait-for-health-check
- promote-to-production
rules:
- if: $CI_COMMIT_BRANCH == "main"
variables:
DEPLOY_ENV: "production"
artifacts:
reports:
security: gl-security-report.json
チームはこのテンプレートを自身のパイプラインに組み込むことで、すべての安全チェックを再実装することなく継承できます。
チームがコードを書き、設定を保存し、環境を管理する方法とすでに統合された標準パイプライン。チームがコードを特定のブランチにプッシュすると、プラットフォームは自動的にビルド、テスト、デプロイの各ステップを実行します。チームはパイプラインスクリプトをゼロから記述する必要はありません。
各環境の一貫性を保証する環境管理。ステージングと本番環境は、誰かが手動で設定を変更したために乖離してはいけません。プラットフォームは、環境が毎回同じ方法でプロビジョニングおよび設定されるように強制する必要があります。
すべてのデプロイで自動的に実行されるセキュリティおよびコンプライアンスチェック。これには脆弱性スキャン、シークレット検出、ポリシー適用が含まれます。チームはこれらのチェックを実行することを覚えておく必要はありません。プラットフォームがデプロイプロセスの一部として実行します。
テストされ信頼性のあるロールバック機能。デプロイが失敗した場合、プラットフォームは手動介入なしに以前の正常な状態に戻す方法を提供する必要があります。これはコードだけでなく、データベースマイグレーションやインフラストラクチャの変更にも適用されます。
デプロイイベントを監視およびアラートに接続するオブザーバビリティ統合。デプロイが発生すると、プラットフォームはチームがデプロイの健全性を理解するのに役立つシグナルを発する必要があります。これにより、不良デプロイの検出までの時間が短縮されます。
一貫性と柔軟性のバランス
プラットフォームエンジニアリングに関する最大の懸念は、すべてのチームを同じ型にはめることです。これは妥当な懸念ですが、優れたプラットフォームが何をするかについての誤解でもあります。
硬直的すぎるプラットフォームはチームに拒否されます。彼らはそれを迂回し、独自の回避策を構築するか、完全に無視するでしょう。柔軟すぎるプラットフォームは混沌とし、各チームが異なる方法で使用し、組織は達成しようとしていた一貫性を失うことになります。
バランスは、ほとんどのケースで機能するゴールデンパスを提供しつつ、明確な理由がある場合にチームが逸脱することを許可することにあります。逸脱は明示的であり、偶発的であってはなりません。チームが異なる承認フローを必要とする場合、それを設定できるようにする必要があります。チームがデプロイ前に追加のテストを実行する必要がある場合、それを追加できるようにする必要があります。しかし、基本パスはデフォルトであり、最も簡単に使用できるオプションであるべきです。
デプロイプラットフォーム構築のための実践的チェックリスト
デプロイプラットフォームの構築または改善を検討している場合、取り組みを導くための短いチェックリストを以下に示します。
- プラットフォームは、チームがデプロイ前に行わなければならない決定の数を減らしていますか？
- チームはドキュメントを読んだり、他のチームに助けを求めたりせずにデプロイできますか？
- プラットフォームはすべてのチームに同じセキュリティおよびコンプライアンスチェックを強制していますか？
- ロールバックは文書化されているだけでなく、自動化されテストされていますか？
- チームはプラットフォームを壊すことなくデプロイプロセスをカスタマイズできますか？
- プラットフォームは、チームがデプロイ後に問題を検出するのに役立つシグナルを発していますか？
- プラットフォームは、カスタムパイプラインを構築する代替手段よりも使いやすいですか？
これらの質問のいずれかに対する答えが「いいえ」の場合、プラットフォームはまだその目的を果たしていません。
本当の目標
プラットフォームエンジニアリングは、管理を集中化することではありません。摩擦を取り除くことです。チームがデプロイプロセス自体について考えずにデプロイできるようになると、実際に構築しているものに集中できます。機能をより迅速にリリースし、障害からより確実に回復し、運用オーバーヘッドに費やす時間を減らすことができます。
優れたプラットフォームの尺度は、統合するツールの数や機能の数ではありません。尺度は、チームがためらうことなく使用することを信頼するかどうかです。チームがコードをプッシュし、プラットフォームが残りを処理することを認識できるとき、組織は個々のデプロイ習慣から共有されたデプロイ機能へと移行しています。それが、デプロイがリスクではなくなり、ルーティンになるポイントです。