極度の不安を感じることなく、本番の展開を自動化するにはどうすればよいですか？

当店では、ソース管理にSVNを、CIにCruiseControlを使用して、開発、テスト、および統合環境への自動ビルドと展開を処理しています。

これはすべてスムーズに機能しますが、ハードウェアとリソースの制約により、統合環境は運用環境のような2サーバーの負荷分散環境ではありません。それ以外はすべて同じですが、それが統合環境と実稼働環境の唯一の違いです（ただし、大きな環境です！）

理論的には、違いはアプリサーバーのわずかに異なる構成であり、デプロイスクリプトはビルドアーティファクトを1つだけではなく2つのサーバーにドロップするだけでよいのですが、なぜ本番デプロイを自動化するのにそんなに緊張するのでしょうか？！

私は一般的にコントロールマニアではありませんが、手作業でプロダクションにプロダクションを展開する必要性を常に感じています。私はこれが一般的に本当に悪いこと™であると同僚から聞いたが、彼らはそれに対して主張をすることに失敗した。

手動で行うと、正しいファイルを物理的にコピーしていること、アプリサーバーを物理的にシャットダウンし、正常に終了したことを確認できます。正常に起動し、展開が成功したことを確認してください。それは私に心の安らぎを与えます。

自動スクリプト化された運用展開のこのOR引数に対する引数は何ですか？

これに対するいくつかの明白な議論があります。

1. 去るとどうなりますか。これらの情報はすべて慎重に文書化されていますか、それとも主にあなたの頭の中にありますか。自動化されたスクリプトは、他の誰かが引き継ぐためのはるかに良い場所です。

2. 誰でも間違いはある。展開を行う人が疲れていて、何にも注意を払わない時が来るでしょう。はい、理想的には、展開は多くの時間のある幸せで穏やかな場所でのみ行われます。実際には、緊急の修正を展開しようとすると、急いでストレスを感じることがあります。これは間違いを犯す可能性が最も高い時間であり、最も費用がかかります。展開が単一のスクリプトである場合、ミスの可能性は限られています。

3. 時間。展開がより複雑になると、実行する必要がある量が増加します。スクリプトはキックオフ、手動チェック、そして手動スイッチオーバーを必要とします（これも自動化できますが、私はいくつかの妄想を共有します:)。

プロセス検証による自動化と自動化の信頼性という最高の世界を手に入れることができます。

展開のスクリプトを作成します。次に、プロセスを開始し、ファイルが削除されたことなどを手動で確認します。つまり、自動化されたステップ1〜Xが実際に行われたことを確認するために、独自のQAスクリプトを作成します。

ここで重要なのは、なぜ検証プロセスをスクリプト化できないと思いますか？

私のデプロイスクリプトは、アーカイブをプッシュしてサービスを再起動するだけではありません。展開の各ステップで多くの色分けされた情報を印刷し、最後にイベントの概要を提供します。プロセスが稼働中であること、ホームページが200ステータスコードを提供していること、すべてのマシンとサービスがお互いに正常に見えることを知らせてくれます。次に、ログファイル、4xxおよび5xxレベルのエラー、および主要なサイトメトリックを監視するスクリプトの一部ではない別のサービスを使用します。その後、急激な悪影響が急増した場合、可能な限りあらゆる媒体（電子メール、txtメッセージ、およびアラーム）で怒鳴ります。

それとテストを実行しているCIサーバーの間で、私は文字通りこのレベルの自動化を展開し忘れています。プロセスの信頼性が高いため、プッシュ後にサイト上の単一のページを閲覧することさえしません。これにより、必要な頻度でデプロイできるだけでなく、プロジェクトの新しい開発者がライブを更新できます。乗船して数分以内にサイト。過去には、すべてを渡すマスター/トランクブランチへのコミット後に、CIサーバーを実稼働環境に自動展開することさえしました。それは私が自分のツールにどれほど自信があるかです。

あなたもする必要があります。

また、リモートデバッグを使用して実稼働マシンを実行し、それらを手動でステップ実行しますか？適切なスクリプトを作成することは、プログラムを作成することと同じです。あなたが持っているすべての問題は、監視し、チェックする必要があることを示しています。

問題が発生した場合は、適切なロールバック手順を経て、メッセージを送信する必要があります。発生したすべてのものは、後で記録することができます。スクリプトをバージョン管理し、テストケースを設定できます。

ただし、コマンドを手動で実行している場合、これらの利点はありません。代わりに、欠点のリストがあります。

• あなたは良いログを持っていません、シェルの履歴はカウントされません
• 他の誰もそれをする方法を知りません
• ステップを見逃します
• チェックは時々しか行われません
• 展開するいくつかのアイテムが見落とされる可能性があります、私は前にそれをやったことがあります
• もっと時間がかかります
• プロセス中に中断される可能性があります

適切なスクリプトは、シェルですべてを入力した場合とほぼ同じです。これが、bashスクリプトがある理由の1つです。あなたがしていることを信頼しているのなら、なぜすべてを記録し、それを締めることができないのですか？より良いチェック、より速いチェック、より多くのチェックは、コンピューターが行うので起こります。

prod環境で新しいことを試してみると、少し緊張しているのがわかります。潜在的な災害を警戒することはGood Thing ^TMです。

自動化されたスクリプトはGood Thing ^TMでもあり、注意深くアプローチする限り、危険を最小限に抑え、恐れを減らすことができるはずです。だから私のアドバイスはこれです。

• チェックリスト/テストセットを準備（および統合envで練習）して、テストが機能したかどうか、何か問題が発生したかどうかをすばやく確認できるようにします。詳細なログがこれに役立つ場合があります。
• すべてをバックアップします。手動でのロールバックを準備して練習し、問題がひどくなった場合に回復できるようにします。
• prodで実際に実行する前に、できる限りテストします。統合envを使用することで、これに加えて良い方法のように思えます。
• 初めて使用する場合は、目立たない、影響の少ない変更で実行してください。マイナーアップグレードまたはパッチのようなもの。問題は、フォールアウトを最小限に抑えることです。最初の実行では、目立ったメジャーアップグレード（CEOとすべての競合他社が見ている）を選択しないでください。

ベルトの下でいくつかの成功した実行を取得したら、自信が高まり、すぐに手動展開をどのように管理したか疑問に思うでしょう。

本番環境への手動展開に対する最大の議論は次のとおりです。あなたは人間であり、間違いを犯します。あなたが悲しみを引き起こす何かをするのを忘れる時があることは間違いないでしょう。適切に作成された自動展開には、同じ傾向はありません。混乱した運用展開を引き続き行うことができるのは事実ですが、それは自動化された展開に解決する必要のあるバグがあるためです。

私の経験では、実稼働環境への自動展開の利点は非常に大きいです。最大のものは、協力しない手動の展開プロセスを行おうとするのではなく、週末に楽しい時間を過ごすことができることです。

とは言っても、運用環境の展開を自動化するための重要なポイントは次のとおりです。

• 一度に全部しないでください！自動化された展開をゆっくりと書き始めます。最初に個別の非実稼働環境をセットアップし、そこで展開を自動化してみてください。自動化された展開に自信が持てたら、運用展開を検討することができます。
• 非常に頻繁にリリースとデプロイを開始してください！4か月間リリースされるコードがない場合、自動展開を行う方がはるかに簡単です。週に複数回、小さな機能とバグ修正をリリースします。このリリーススタイルの利点は控えめに言ってはいけません！
• 自動化されたテストに依存して、実稼働環境が機能することを確信できます。繰り返しますが、これには時間がかかりますが、非常に重要です。自動テストは、手動の受け入れテストよりも常に優れています。確かに、手動の受け入れテストは問題ありませんが、自動化されたテストは、運用環境に展開する必要があるかどうかを知るのに役立ちます。これらは、自動化された継続的な配信のこのプロセス全体を可能にするキーです。テストに合格しなかった場合、実稼働環境にデプロイしないことを知っています。

ライブサーバーでスクリプトを実行します。それは機能し、数回正常に機能することを確認した後、完全に自信を持ちます。

しかし、真剣に、あなたは展開スクリプトよりも間違いを犯す可能性が高くなります。

コンピューターは間違いを犯さない、人々は犯す。

スクリプトを1回作成し、徹底的にチェックし、1行ずつ確認します。それ以降は、デプロイするたびに機能することを確認できます。

手でやると、間違いを犯すことになります。たぶん、あなたがしなければならないことすべてを書きましたが、間違いを犯すのはとても簡単です。web.configファイル以外のすべてのファイルをコピーする必要がありますか？いつかそれを上書きすることは間違いありません。スクリプトはこの間違いを犯しません。

極度の不安を感じることなく、本番の展開を自動化するにはどうすればよいですか？

本番デプロイメントを自動化するときに経験する極端な不安は、おそらく2つの信念に基づいています。

1. いずれにせよ、いくつかの展開手順が失敗し、自動化されたスクリプトがそれを見落とす可能性がありますが、ユーザーまたは別の人間は障害から迅速に回復できます。

2. 見落とされた生産の失敗は劇的な結果をもたらします。

失敗を回避する以外に、2についてできることはほとんどありません。そのため、1に注目しましょう。

存在をわずかに改善する安価なソリューションは、インストールの各ステップの終わりに検証を待つ半自動展開手順を使用することです。半自動ソリューションを使用すると、一貫性や再現性などの全自動ソリューションの利点を享受できますが、現在使用している進行状況を監視し、エラーから回復する機会も得られます。

半自動化されたスクリプトとそのビオトープ（回帰テストなど）は、インストール手順で発生する障害とそれらから回復する方法について収集している知識の媒体としても機能します。

私が気に入っているのは、ステージングまたはQAで展開をテストし、prodで実行するとまったく同じ手順が実行されることを知っていることです。

手動で行う場合は、ステップを忘れたり、順序を間違えたりする方が簡単です。

...ハードウェアとリソースの制約により、統合環境は本番環境のような2サーバーの負荷分散環境ではありません。それ以外はすべて同じですが、それが統合環境と実稼働環境の唯一の違いです（ただし、大きな環境です！）

上記を考えると、私はおそらくあなたと同じくらい不安になるでしょう。

SLBに展開する自動スクリプトの確認とテストを一度行ったことがありますが、負荷分散セットアップで事前にテストすることなく、手動で作業を行いたいと考えています。

製品のようなテストのセットアップに加えて、私の安心に大きな影響を与えたもう1つのことは、製品の展開が、開発者である他のチームによって行われたことです。

• プロジェクトの1つで、開発チームの代表として展開を支援していました。展開する前に、彼らは私の指示を確認していましたが、展開中に問題が発生した場合に相談できるようにオンラインで座っていました。当時、私はその分離に感謝することを学びました。
   
  速くなったわけではありません（なぜだろうか？私は彼らよりも頻繁に5x-10xの展開をテストしました）。大きな違いは焦点にあった。つまり、私の頭は常に「主要な」もの（コーディング、デバッグ、新機能）によって読み込まれます。展開に適切に集中するには気が散りすぎます。それとは対照的に、彼らの主なものは単なる生産メンテナンスであり、彼らはそれに集中していました。
   
  集中すると脳がどれほど良く機能するかは驚くべきことです。これらの人たちは、とても気配りが行き届いていて、私よりも間違いをずっと少なくしてくれました。彼らは私よりもそのことをよく知っていました。彼らは、私自身のテスト展開をより簡単にする1つまたは2つのことさえ教えてくれました。

コードを任意の環境に移動するために使用する展開スクリプトを構築します。まったく同じ展開プロセスを使用して、コードをdev、qa、ステージング、そして最終的に本番に移行します。1日に複数回devに展開し、毎日QAに展開しているので、展開スクリプトが正しいことを確信しました。基本的に、それを頻繁に使用することで、地獄をテストします。

1. 簡素化する。変更プロセスはrsyncファイルであり、SQLスクリプトを実行するだけで、それ以上のことはありません。
2. 自動化。
3. テスト。

自動化する理由は、テスト可能で再現性のあるものを取得し、予想されるすべての状況で正しく動作することを信頼できることです。

コンテキストの変更に関しては、引き続きバックアウトプランが必要であり、同様に自動化する必要があります。

環境が非常にデリケートな場合に発生するプロセスを引き続き観察する必要がありますが、手動で再現することはできないため、絶対に行わないでください。

自動化スクリプトを使用して実稼働環境に展開することは完全に可能です。ただし、これを確実に行うには、いくつかのことができる必要があります。

1. 以前のバージョンに確実にロールバックします。
2. 展開が正常に適用され、有効なトラフィックに応答しているという肯定的な確認を取得します。
3. 同じスクリプトを使用する、開発とQAに匹敵する環境があります。

スクリプトにはいくつかの利点があります。たとえば、午前2時と疲れているためにコマンドを逃すことはありません。

ただし、スクリプトは失敗する可能性があります。障害はスクリプトの設計にある場合もありますが、ネットワークまたは電源障害、ファイルシステムの破損、メモリ不足などが原因である可能性もあります。

そのため、スクリプトを実行した後、ライブトラフィックを有効にする前に、新しい展開が実行され、要求を実行および処理していることを確認する定義済みのテストフェーズに従うことも重要です。

1. 何かがうまくいかない場合は、最初に展開のためにより大きなウィンドウを使用

2. 展開プロセスを2つの部分に分けます。a。バックアップ（手動）-これにより、展開中に問題が発生した場合に自信が得られます。

   b。展開（自動化）

初めて自信を持って展開できたら。バックアッププロセスも自動化できます。