すべてのデプロイが別の物語になるとき：アドホックデリバリーの罠

あなたは小さなチームで働いている。おそらく5〜6人。アプリは動いている。ユーザーは満足している。デプロイは行われているが、その方法について誰も深く語らない。ある開発者はFTPでサーバーにファイルをコピーする。別の開発者は自分のノートPCからスクリプトを実行する。さらに別の開発者は本番環境に直接ログインして変更を加える。

誰も文句を言わない。なぜなら、たいていの場合はうまくいくからだ。うまくいかなくなるまでは。

「デプロイのやり方を知っている」人が休暇に入った。緊急のバグ修正をリリースしなければならないが、誰も手順を把握していない。デプロイにかかる時間は20分のはずが3時間になる。誰かが本番データベースに対して誤ったSQLコマンドを実行してしまう。元に戻す方法はない。

これがデリバリー成熟度のレベル1、アドホックである。すべてが手動。毎回すべてが異なる。そしてプロセス全体が、文書化や自動化されたものではなく、誰が対応可能かによって左右される。

個人依存の問題

アドホックなデリバリープロセスの最も明確な兆候は、知識が共有システムではなく個人の頭の中に存在することだ。一人の人間がデプロイの知識を独占すると、その人がボトルネックになる。その人が休暇に入ればデプロイは止まる。その人が会社を辞めれば、知識も一緒に去ってしまう。

たとえドキュメントが存在しても、たいていは古くなっている。誰かが6ヶ月前にREADMEを書いた。それ以来、デプロイ手順は5回変更された。誰もドキュメントを更新しなかった。新しいチームメンバーは試行錯誤と、それらしき人への質問によって学んでいく。

次のフローチャートは、アドホックなデプロイが予測不可能な経路に分岐し、それぞれがリスクを伴う様子を示しています：

flowchart TD A[開発者がデプロイを開始] --> B{どの方法？} B --> C[FTPでサーバーにファイル転送] B --> D[個人のスクリプトを実行] B --> E[本番環境を直接編集] C --> F[ファイルが不完全な可能性] D --> G[スクリプトは1台のマシンでしか動かない] E --> H[誤ったSQLコマンドのリスク] F --> I[デプロイが静かに失敗] G --> J[他の開発者は実行できない] H --> K[ロールバック不可] I --> L[担当者休暇中 - 修正不可] J --> L K --> L L --> M[デプロイに数時間かかる]

これは無能さの問題ではない。小規模チームはリスクが低いため、この方法でうまくやっていけることが多い。しかしチームが成長するにつれて、ひび割れが目に見えるようになる。すべてのデプロイが新しい冒険となる。10分で終わるのか2時間かかるのか、誰にも予測できない。

手動デプロイ：二度と同じものはない

アドホックな環境では、標準的なデプロイ手順は存在しない。各開発者が独自の方法を持っている。ある人はSSHでサーバーに接続し、最新コードをプルしてサービスを再起動する。別の人はWebインターフェースからzipファイルをアップロードする。さらに別の人は自分のマシンでしか動かないローカルスクリプトを実行する。

単一の信頼できる情報源がないため、デプロイが正しく行われたかを誰も検証できない。何かが失敗すると、デプロイ担当者は推測を始める。異なるコマンドを試し、サービスを再起動し、ログを確認し、何かがうまくいくことを願う。行き詰まれば、もっと知っているかもしれない他の誰かに電話する。

このアプローチは月に一度のデプロイなら機能する。週次や日次でデプロイする必要がある場合、苦痛になる。プロセスが改善されることがないため、すべてのデプロイが同じリスクを抱える。同じミスが繰り返される。同じ解決策を再発見するために時間が無駄になる。

セーフティネットのないデータベース変更

レベル1でのデータベース管理は特に危険だ。スキーマ変更は本番データベースに直接適用される。開発者がデータベースサーバーにログインし、ALTER TABLE文を実行し、何も壊れないことを願う。

マイグレーションスクリプトはない。バージョン追跡もない。ロールバック計画もない。変更が問題を引き起こした場合、同じ開発者が手動のSQLコマンドを実行して元に戻す方法を考え出さなければならないが、それが機能するかどうかはわからない。

チームは現在どのバージョンのスキーマが動作しているかを知る方法がない。2人の開発者が同時に変更を行うと、何かが壊れるまで競合は検出されない。本番データが失われたり、破損したり、不整合な状態のまま放置されたりする可能性がある。

記憶に依存するインフラ管理

サーバーは手動でセットアップされる。誰かがログインし、パッケージをインストールし、サービスを設定し、手作業で設定を調整する。アプリケーション設定はバージョン管理下ではなく、サーバー上のファイルに存在する。サーバーがダウンした場合、チームは再作成に必要なすべての手順を記憶していなければならない。

Infrastructure as Codeはない。自動プロビジョニングもない。再現可能なセットアッププロセスもない。チームは記憶、付箋、そして元のサーバーをセットアップした人の善意に依存している。

これはサーバーが1〜2台の場合に機能する。スケールが必要な場合、障害からの復旧が必要な場合、またはテスト用に環境を複製する必要がある場合、管理不能になる。

チームがレベル1に留まる理由

レベル1に留まることは、怠惰やスキル不足の兆候ではない。多くのチームが正当な理由でここに留まっている：

  • チームが非常に小さく、手動プロセスで十分に速い。
  • デプロイの頻度が低く、痛みが継続的ではない。
  • アプリケーションが重要ではなく、障害の影響が小さい。
  • チームに他にもっと緊急に感じられる優先事項がある。

これらの理由は短期的には理にかなっている。しかし、それらは隠れたコストを生み出す。すべての手動デプロイはリスクを伴う。すべての文書化されていないステップは依存関係を生み出す。すべての直接的なデータベース変更はデータ損失の可能性を高める。

問題はチームが何か間違ったことをしていることではない。問題は現在のアプローチがスケールしないことだ。チームが成長し、デプロイがより頻繁になり、アプリケーションがより重要になると、アドホックプロセスは負債となる。

最初のステップはツールを買うことではない

レベル1から脱却するために高価なツールや複雑なパイプラインは必要ない。最初のステップはよりシンプルで難しい：現在のプロセスが信頼できないことを認め、デプロイ中に実際に何が起こっているかを文書化し始めることだ。

自動化する前に、何を自動化するのかを知る必要がある。パイプラインを構築する前に、手順について合意する必要がある。CI/CDプラットフォームを購入する前に、自身のワークフローを理解する必要がある。

アドホックから脱却するための実践的チェックリスト

この説明に自分のチームを当てはめられるなら、ここから始めよう：

  • すべてのコマンドとすべての判断ポイントを含む、デプロイの正確な手順を書き出す。
  • 重要な知識を誰が保持しているか、その人が不在の場合に何が起こるかを特定する。
  • 誤って実行された場合に障害を引き起こす可能性のあるすべての手動ステップをリストアップする。
  • 現在のデータベーススキーマと変更の適用方法を文書化する。
  • すべてのパッケージ、設定、依存関係を含むサーバーセットアッププロセスを記録する。

これは完璧なドキュメントを作成することではない。見えないものを見えるようにすることだ。プロセスが書き留められれば、リスクがどこにあるのか、自動化が実際にどこで役立つのかがわかる。

具体的な takeaways

アドホックデリバリーは、うまくいかなくなるまでは機能する。デプロイが失敗し、誰も修正方法を知らない、または知っている人に連絡が取れない瞬間、手動プロセスのコストが明らかになる。前進する道は、まだツールや自動化ではない。現在の方法が脆弱であることを認め、何をしているのかを書き留め、最終的により良くできるようにすることから始まる。