極度の不安を経験することなく、本番環境への展開を自動化するにはどうすればよいですか？
当店では、開発、テスト、統合環境への自動ビルドとデプロイメントの処理に、ソース管理にSVN、CIにCruiseControlを使用しています。
これはすべてスムーズに動作しますが、ハードウェアとリソースの制約により、統合環境は本番環境のような2サーバーの負荷分散環境ではありません。他はすべて同じですが、それが私たちの統合環境と本番環境の間の唯一の違いです（ただし大きなものです！）。
理論的には、アプリサーバーの構成が少し異なり、デプロイスクリプトはビルドアーティファクトを1つではなく2つのサーバーにドロップするだけで済みますが、本番環境へのデプロイを自動化するのに緊張しているのはなぜですか。
私は一般的にはコントロールのフリークではありませんが、手動でプロダクションにプロダクションをデプロイするという飽くなき必要性を常に感じています。これは一般的にReally BAD Thing™であると同僚から聞いたことがありますが、彼らはそれに反対することはできませんでした。
手動で行うと、正しいファイルを物理的にコピーしていること、アプリケーションサーバーを物理的にシャットダウンしてサーバーが正常に閉じていることを確認でき、サーバーを物理的に再起動してから、ログを物理的に調べて、正常に起動し、展開が成功したことを確認してください。それは私に安心を与えてくれます。
これに対する引数は何ですかOR自動スクリプトプロダクションデプロイメントの引数？
これに対するいくつかの明白な議論があります。
あなたが去るとどうなりますか？このすべての情報は注意深く文書化されていますか、それとも主にあなたの頭にありますか？自動化されたスクリプトは、他の誰かがそれを引き継ぐためのはるかに良い場所です。
誰でも間違いはある。何も気にせず、展開をしている人が疲れる時が来るでしょう。はい、理想的には、展開は時間のある幸せで穏やかな場所でのみ行われます。実際には、緊急の修正を展開しようとするときに急いでストレスを感じる可能性があります。これは、間違いを犯す可能性が最も高い時期であり、最もコストがかかります。展開が単一のスクリプトである場合、ミスの可能性は限られています。
時間。展開がより複雑になるにつれて、実行する必要のある量が増加します。スクリプトはキックオフ、手動チェック、そして手動切り替えを必要とするだけです（これを自動化することもできますが、パラノイアの一部を共有します:)。
プロセス検証と自動化の信頼性により、最高の世界を手に入れることができます。
デプロイメントのスクリプトを作成します。次に、プロセスを開始し、ファイルが削除されたことなどを確認し、手動で確認します。つまり、自動化されたステップ1-Xが実際に発生したことを確認するためだけに、独自のQAスクリプトを記述します。
ここで重要なのは、検証プロセスをスクリプト化できないと思うのはなぜですか。
私のデプロイスクリプトは、アーカイブをプッシュしてサービスを再起動するだけではありません。展開の各ステップ中に色分けされた多くの情報を出力し、最後にイベントの概要を提供します。プロセスが稼働中であること、ホームページがステータスコード200を提供していること、すべてのマシンとサービスがお互いに正常に認識されていることがわかります。次に、ログファイル、4xxおよび5xxレベルのエラー、および主要なサイトメトリックを監視するスクリプトの一部ではない別のサービスを用意します。その後、劇的な負の効果のスパイクがある場合、可能な限りあらゆる媒体（メール、txtメッセージ、およびアラーム）を通じて私に向かって怒鳴り続けます。
テストを実行しているCIサーバーとの間で、私は文字通りこのレベルの自動化をデプロイし、忘れています。プッシュ後、サイトの1つのページを閲覧することすらありません。プロセスの信頼性が高く、これにより、必要な頻度で展開できるだけでなく、プロジェクトの新しい開発者がライブに更新できるようになります。乗船してから数分以内のサイト。以前は、すべてを渡すマスター/トランクブランチへのコミット後に、CIサーバーを本番環境に自動デプロイすることさえありました。それは私が私のツールにどれだけ自信があるかです。
あなたもそうするべきです。
また、リモートデバッグを使用して運用マシンを実行し、それらを手動でステップ実行しますか？適切なスクリプトの作成は、プログラムの作成と同じです。あなたが持っているすべての問題は、それを監視し、チェックする必要があることを示しています。
何か問題が発生した場合は、適切なロールバック手順を実行して、メッセージを送信する必要があります。発生するすべてのことを後でログに記録できます。スクリプトをバージョン管理し、テストケースを設定できます。
ただし、コマンドを手動で実行している場合は、これらの利点はありません。代わりに、欠点のリストがあります。
- 良いログがありません。シェルの履歴はカウントされません
- 他の誰もそれを行う方法を知りません
- 手順が失敗する
- チェックは時々行われます
- 展開するいくつかのアイテムが見逃される可能性があります
- もっと時間がかかる
- プロセス中に中断される可能性があります
適切なスクリプトは、シェルですべてを入力した場合とほぼ同じです。これが、bashスクリプトがある理由の1つです。あなたがしていることを信頼しているなら、なぜあなたはすべてを記録してそれを引き締めることができないのですか？コンピュータがそれを行うため、より良いチェック、より速いチェック、より多くのチェックが発生する可能性があります。
本番環境で何か新しいことに挑戦するのが少し緊張しているのは理解できます。潜在的な災害に注意することは良いことですTM。
自動化されたスクリプトも良いことですTM そして、注意深くそれに近づく限り、危険を最小限に抑え、恐れを減らすことができるはずです。だから私のアドバイスはこれです。
- チェックリスト/テストセットを準備（および統合環境で練習）して、それが機能したかどうか、何か問題があった場合はどうするかをすばやく確認できるようにします。詳細なログがこれに役立つ場合があります。
- すべてをバックアップします。手動ロールバックを準備して練習し、ひどくうまくいかなかった場合に回復できるようにします。
- 本番環境で実際に実行する前に、できる限りテストしてください。あなたの統合環境でこれと一緒に良い方法のように聞こえます。
- 初めて試すときは、目立たず、インパクトの少ない変更を加えてください。マイナーなアップグレードやパッチのようなもの。フォールアウトがうまくいかなかった場合、フォールアウトを最小限に抑えるという考え方です。最初の実行では、有名なメジャーアップグレード（CEOとすべての競合他社が監視しているもの）を選択しないでください。
いくつかの成功した実行がベルトの下で得られると、自信が高まり、すぐに手動での展開をどのように管理したのか不思議に思うでしょう。
本番環境への手動デプロイに対する最大の論点は次のとおりです。あなたは人間であり、間違いを犯します。あなたが悲しみの原因となる何かをすることを忘れる時があることは間違いありません。適切に作成された自動展開には、同じ傾向はありません。混乱したプロダクションデプロイを保持できることは事実ですが、それは自動デプロイに解決する必要のあるバグがあるためです。
私の経験では、本番環境への自動デプロイのメリットは計り知れません。最大のものは、協力しない手動の展開プロセスを行おうとする代わりに、週末に楽しんでもらうことです。
とはいえ、本番環境へのデプロイを自動化するための重要なポイントをいくつか紹介します。
- すべてを一度に実行しないでください！自動デプロイメントの作成をゆっくり始めます。最初に別の非運用環境をセットアップし、そこでデプロイメントの自動化を試みます。自動化されたデプロイメントへの信頼が高まったら、本番デプロイを検討することができます。
- 非常に頻繁にリリースとデプロイを開始してください！リリースされるのを待っているコードが4か月ない場合、自動デプロイメントを実行する方がはるかに簡単です。小さな機能とバグ修正を週に数回リリースします。このリリーススタイルのメリットは控えめに言っても過言ではありません。
- 本番環境が機能することを確信させるには、自動テストに依存してください。繰り返しますが、これは構築に時間がかかりますが、非常に重要です。自動テストは常に手動受け入れテストよりも優れています。確かに、手動の受け入れテストは問題ありませんが、自動テストは、運用環境に展開する必要があるかどうかを判断するのに役立ちます。これらは、自動化された継続的デリバリーのこのプロセス全体を可能にする鍵です。テストに合格しない場合は、本番環境にデプロイしない方がよいでしょう。
ライブサーバーでスクリプトを実行します。それは機能し、数回正常に機能するのを見た後、完全に自信を持っています。
真剣に、しかし、あなたは展開スクリプトよりも間違いを犯す可能性が高いです。
極端な不安を感じることなく、本番環境への展開を自動化するにはどうすればよいですか？
プロダクションデプロイメントを自動化するときに経験する極端な不安は、おそらく2つの考えに基づいています。
いずれにせよ、一部の展開ステップは失敗し、自動化されたスクリプトが見落とす可能性がある間、ユーザーまたは別の人間は失敗から迅速に回復できます。
見落とされている生産の失敗は劇的な結果をもたらします。
失敗を回避する以外に、2についてできることはほとんどないので、1に焦点を当てましょう。
既存のものをわずかに改善する安価な解決策は、インストールの各ステップの終わりに検証を待つ半自動のデプロイメント手順を使用することです。半自動ソリューションを使用すると、一貫性や再現性などの完全自動ソリューションの利点を享受しながら、現在慣れている進行状況を監視してエラーから回復する機会が得られます。
半自動化されたスクリプトとそのビオトープ（回帰テストなど）は、インストール手順で発生する障害とそれらから回復する方法について収集している知識の伝達手段としても役立ちます。
コンピューターは間違いを犯さない、人は間違いを犯す。
スクリプトを1回記述し、それを完全にチェックして、1行ずつ確認してください。それ以降は、デプロイするたびに確実に機能します。
手作業で行うと、間違いを犯しがちです。たぶん、あなたが書いた、あなたがしなければならないすべてのことを書きますが、間違いを犯すのはとても簡単です。 web.configファイル以外のすべてのファイルをコピーする必要がありますか？あなたはいつかそれを上書きすることに賭けることができます。スクリプトがこのミスを犯すことは決してありません。
私が好きなのは、ステージングまたはQAでデプロイメントをテストでき、製品で実行するとまったく同じ手順が実行されることを知っていることです。
手動で行うと、ステップを忘れたり、順序を乱したりする方が簡単です。
- 簡素化する。変更プロセスはrsyncファイルで、SQLスクリプトを実行するだけです。
- 自動化。
- テスト。
自動化する理由は、テスト可能で繰り返し可能なものを取得し、予想されるあらゆる状況で正しく動作することを信頼できるためです。
コンテキストの変更に関しては、バックアウト計画が必要であり、それも自動化する必要があります。
環境が非常にデリケートな場合に発生するプロセスを観察する必要がありますが、再現できないため手動で実行しないでください。
...ハードウェアとリソースの制約により、私たちの統合環境は、本番環境のような2サーバーの負荷分散環境ではありません。他はすべて同じですが、それが私たちの統合環境と本番環境の間の唯一の違いです（ただし大きなものです！）。
上記のように、私はおそらくあなたと同じくらい心配でしょう。
私はかつてSLBに展開する自動化スクリプトのレビューとテストを行いましたが、負荷分散されたセットアップで事前テストを行わない場合手動で行うことを好みます。
Prodのようなテストセットアップに加えて、私の心の平和に大きな影響を与えたもう1つのことは、prodの展開が他の開発者チームによって行われたことです-唯一の仕事は維持することでした本番環境。
- プロジェクトの1つで、私は開発チームの代表として展開を支援しました。展開の前に、彼らは私の指示を見直していました、そして展開の間、私は物事がうまくいかない場合に相談する準備ができているオンラインでただ座っていました。当時、私は分離を理解することを学びました。
それらが高速であったわけではありません（なぜそうなったのですか？私は、展開を5倍から10倍頻繁にテストしました）。 大きな違いがフォーカスされていました。つまり、私の頭には常に「メイン」のもの（コード、デバッグ、新機能）が読み込まれています。 。それとは対照的に、their主なものは単なる生産メンテナンスであり、彼らはそれに集中していました。
焦点を合わせると、脳がどれほど機能するかは驚くべきことです。これらの人たちは、彼らはとても気配りがあり、彼らは私よりはるかに少ない間違いを犯しました。彼らは私よりもそのことをよく知っていました。彼らは、私自身のテスト展開をより簡単にする1つまたは2つのことさえ教えてくれました。
コードを任意の環境に移動するために使用するデプロイメントスクリプトをビルドします。まったく同じデプロイメントプロセスを使用して、コードをdev、qa、ステージング、最後に本番に移動します。開発には1日に複数回、QAには毎日展開しているため、展開スクリプトが正しいという確信を得ました。基本的に、それを頻繁に使用することで地獄をテストします。
自動化スクリプトを使用して実稼働環境にデプロイすることは完全に可能です。ただし、これを確実に行うには、いくつかのことができる必要があります。
- 確実に前のバージョンにロールバックします。
- 展開が正常に適用され、有効なトラフィックに応答していることを確認します。
- 同じスクリプトを使用する、開発とQAに対応する環境があります。
スクリプトには、午前2時にコマンドを見逃すことがなく、疲れているなど、いくつかの利点があります。
ただし、スクリプトは失敗する可能性があります。失敗はスクリプトの設計にある場合もありますが、ネットワークまたは電源の障害、ファイルシステムの破損、メモリ不足などが原因である可能性もあります。
このため、スクリプトの実行後、ライブトラフィックが有効になる前に、定義済みのテストフェーズに従って、新しい展開が稼働中で、要求が処理されていることを確認することが重要です。