要点
- コミットから本番までの経路を、テストも含めて自動化する。
- ステージングを本番に近づけ、同じ成果物を両方にデプロイする。
- 修正よりも切り戻しを速くする。
- すべての指標ではなく、ユーザーが感じる症状でアラートを出す。
DevOpsはツールでも職種でもありません。パイプライン、環境、監視、復旧という実践的な習慣によって、リリースを良い意味で退屈なものにします。
本番までの自動化された一本道
すべての変更は同じ経路を通るべきです。ビルド、テスト、パッケージ化、ステージングへのデプロイ、そして同じ成果物の本番への昇格。手作業はリリースが失敗する場所なので、減らすたびにデプロイは安全になります。
- すべてのプルリクエストで型チェック、リント、テストを実行する。
- ビルドは一度だけ、同じイメージやバンドルを環境間で昇格させる。
- メインブランチへのマージ前にレビューを必須にする。
- パイプラインの設定をリポジトリで管理する。
一致した環境
本番でしか起きないバグは、たいてい環境の違いから生まれます。コンテナとInfrastructure as Codeでステージングと本番をそろえ、ステージングの現実的で匿名化されたデータが残りを見つけてくれます。
安全にリリースし、素早く回復する
小さく頻繁なリリースは理解しやすく、元に戻しやすくなります。データベースのマイグレーションは後方互換にし、前のバージョンが動き続けられるようにします。フィーチャーフラグを使えば、準備ができるまで公開せずにコードを出荷できます。
問題のあるリリースから回復するまでの時間を測りましょう。切り戻しが前向きの修正より時間がかかるなら、切り戻しに投資すべきです。
深夜3時に役立つ監視
CPUの急上昇のたびではなく、エラー、遅い応答、失敗したジョブ、表示できないページなど、ユーザーが体験することでアラートを出します。すべてのアラートは対応可能で、対応できる人に届くべきです。
- 主要なユーザー導線の死活監視。
- リリースの目印付きのエラー追跡。
- レイテンシ、エラー率、キューの長さのダッシュボード。
- 各アラートにリンクした対応手順書。
パイプラインに組み込むセキュリティ
依存関係を自動でスキャンし、シークレットはコードやパイプライン変数ではなく管理されたストアに置き、デプロイ用の認証情報には必要な権限だけを与えます。
参考になりましたか？次の記事をメールで受け取れます。