ライブWebサイトの展開バグの数を減らすために何ができますか？

多くの皆さんがこの問題を経験していると確信しています。WebサイトまたはWebアプリケーションが実行中であり、ライブです。次のバージョンをアップロードしたいが、設定ファイルで値をfalseに設定したり、データベースに別のレコードを挿入したり、20個以上のパラメーターにカウントされることがある多くのマイナーな処理を行うなど、すべてを理解していません。

新しいバージョンをアップロードするとすぐに、すべてが壊れます。現在、問題の修正には最大20分しかかかりませんが、許容できる全体的なストレス、および会社への財政的および信用上の損害は忘れられない場合があります。

新しいバージョンの展開の初期構成から生じるこれらのタイプのバグを減らす方法は何ですか？

PS：チェックリストについては言及しないでください。すでにリストがあります。チェックリストの問題は、常に更新されるべきですが、更新されないということです。

2つのこと：

• テスト展開を行うライブ環境と同様のステージング環境。
• 展開後のこの環境の十分なテスト。自動化および非自動化。

他にもできることがあります。

Troy Huntによる自動展開に関する5部構成のブログシリーズを読むことをお勧めします。彼が使用するツールはMSスタック固有ですが、概念は普遍的です。

なぜ誰もバージョン管理について言及していないのだろうか？これは、更新/アップグレード中のトラブルからあなたを救う最も重要な方法の一つです。

まず、デプロイメントはリポジトリの安定ブランチの単なるクローンにする必要があります。構成ファイル、SQLファイル、インストール/更新スクリプトなど、すべてをバージョン管理する必要があります。

次に、「なんらかの」ステージング領域が必要です。ローカルサーバー、作成したばかりの一時的な仮想クラウドサーバー、非常にシンプルな仮想ホストのセットアップ、または完全なカスタムアプリケーションメインアプリと共に維持します。この「ステージング領域」と「開発領域」の違いは、前者が実際のデプロイメント環境をより厳密にモデル化（またはシミュレート）することです。たとえば、Apacheモジュールを使用してPHP 5.3.xで開発できますが、ホストはFCGIを使用したPHP 5.2.xであるため、ステージング領域は同じである必要があります。

次に、最初に開発環境で更新を記述してテストします。これらの変更をステージングエリアリポジトリにマージし、再度テストします。この時点で、配置に合わせて設定を変更できます。バージョン管理されているため、何も失われず、問題が発生した場合はいつでも元に戻すことができます。

最後に、ライブ展開コピーのステージング領域の変更をマージします。

ステージング領域の複雑さは、アプリの複雑さと範囲を反映する必要があります。しかし、いずれにしてもバージョン管理は不可欠です。

もちろん、バージョン管理を使用しない場合は（これは当てはまりません）、Logoでデータベースを作成するのと同じくらい単純です。

提案されているように、ステージングシステムを使用します。これにより、ライブ環境で変更をテストする機会が与えられます。

これは別のポイントをもたらします：テスターがいます。自分で書いたものをテストしても、他の人が私のアプリケーションをテストするときほどのバグは見つかりません。

もう1つは、展開プロセスを自動化することです。ant migrateを使用してdb移行を行い、capistranoなどを介してsvnから最新バージョンを自動的にデプロイします。何かをデプロイする場合、クリックするだけでそれ以上行う必要はなく、すべてが自動的に行われます。特に、構成のセットアップが必要なWebサイトの場合、展開に必要な手動手順は悪夢であり、何かがうまくいかない可能性があります。

AおよびBシステムを使用し、Bのアップグレードおよびテスト中にロードバランサーを使用してすべての要求をAにルーティングし、Aの更新中にすべてをBにルーティングすることを検討してください。

ボーナスポイントについては、Cを追加し、システムが地理的に離れていることを確認してください。これにより、地震が同時に2つ発生することはありません。

多くのアプリケーションでは、これが過剰であることを認めます。

また、必要なトランザクション管理も複雑になりますが、問題は克服できません。

はい、すべての手順を実行するテストまたはステージング環境が必要ですが、個別の環境用に個別の構成ファイルを保持する必要があります。

Environments
|_property_files
    |_ dev
        |_ com.bla.util
        |    |_ example.properties
        |_ com.bla.beans
        |    |_ someconfig.xml
    |_ test
        ....
    |_ production
        ....
|_database_updates
    |_ dev
        |_ insert_new_static_data.sql
        |_ ...

...

基本的に、ビルドおよび展開スクリプトでは、XMLファイルなどの環境固有のメタデータファイルを取得し、パッケージ化する前にビルド場所でそれらを置き換える環境プロパティを取得します。さらに、私の展開スクリプトでは、データベースの更新でSQLファイルを探し、その環境用に構成されたデータベースでそれらを実行します。

カスタムビルドタスクでこれを行うこともできますが、実際にはいくつかのJUnitテストを使用してこれを実行します。SQL例外が発生すると、テストは失敗し、展開は失敗します。一般的に、SQLスクリプトにはインテリジェンスがあり、必要なデータが既に環境に存在する場合、挿入または更新をスキップします。

特定の環境で実行する必要があるバッチまたはシェルスクリプト用の同様のディレクトリもあります。

あなたの質問のすべてはこれです：それらは常に更新されるべきですが、更新されません。

これらの構成は自動化されたビルドと展開を促進するので、それらを更新しないとビルドが失敗し、マネージャーからメールで通知されます。チームがコンパイルするコードをチェックインするのと同じくらい重要なのは、特定のリリースのビルドと展開の構成を維持することです。どちらの違反でもビルドが壊れます。

要するに、継続的インテグレーション（CI）原則のより大きな採用は、実稼働リリースの痛みを取り除くのに役立ちます。

1）最初にテストサイトに展開し、変更をテストします

2）すべての構成を構成ファイル（Web構成など）に入れます。この構成は、アプリケーションに固有であり、上書きされることはありません。変更は、テストとは異なるものを変更することを忘れるのではなく、意図的に行われます。

運用前環境を整え、自動テストを使用するための上記の優れた提案に加えて：

コードベースの複雑さを軽減します。一般に、コードが少ないと、バグが少なくなり、バグを見つけるのが簡単になります。これが、リファクタリング、懸念の分離などの背後にある哲学です。

コードベースをセグメント化します。一般的なアプローチの1つは、次のように分けることです。

• ゆっくりと変化し、サイト全体で共有されるいくつかのコアパーツ
• 葉の多くの部分はより速く変化する可能性がありますが、それぞれがサイトの小さな部分にのみ影響を与えます

コードベースをこのように理解することにより、バグが最も劇的な影響を与えるため、開発とテストをコア部分に集中させることができます。

適切に実行されたリリースは、計画とコミュニケーションに関するものです。したがって、リリースを実行する前に、次の質問を考慮してください。

1. リリースにはどれくらい時間がかかりそうですか、リリースの進行中に人々が私の製品とやり取りし続けるのにリスクはありますか？システムにリスクがある場合は、システムをオフラインにし、代わりに「現在メンテナンス中のシステム」メッセージを表示することを検討してください。

2. 事前にリリースについて通知する必要がある顧客はいますか？サービスの中断の可能性、またはリリースの進行中のパフォーマンスの低下について彼らに伝える必要がありますか？個人的に、私は常に、過剰なコミュニケーションを行い、公開ブログまたは同様の会場での今後のリリースまたはメンテナンスの時間をすべての顧客に伝えます。

3. リリースが失敗した場合の緊急時の計画は何ですか？たとえば、リリースが不十分な場合、システムをロールバックして、オフラインになる時間を最小限に抑えるようにシステムを復元する必要がありますか？もしそうなら、リリースをロールバックする手順はよく文書化されていますか？または、問題が発生した場合のトラブルシューティングを支援するために、電話または手元に適切な人を配置する必要があります。個人的には、リリースの計画にアプローチする最善の方法は、リリースで何かがうまくいかないと想定することだと思います。そのようにして、私はこれらの問題のいくつかを事前に考えさせられました。

次に、リリースの実行に関しては、リリースをスムーズに実行するための最良の方法の1つは、途中で遭遇するすべてを練習、練習、練習し、文書化することです。。そのため、新しいコードを運用環境に展開する前に、安全で適切にサンドボックス化されたステージング環境にコードを展開することを最初に練習してください。実稼働環境への展開を担当する担当者に、ステージングへのテスト展開を実行してもらいます。これがあなたの服のリハーサルであることを考慮し、これが本物であるならあなたがするようにあなた自身を行います。すべての手順を文書化してください。実行するすべてのコマンド、実行するSQLコード、変更するファイル、およびそれらの変更方法を文書化します。手順の各ステップについて、手順が正しく実行されるかどうかを確認します。何らかの問題が発生した場合は、それを解決するために行ったことを文書化します。

その後、プラクティス展開が完了し、メモを確認して、エラーを排除するためにプロセスを改善できるかどうかを確認します。その後、もう一度やり直してください。「このマシンにログインし、このコマンドを実行し、データベースにログインしてこのSQLコマンドを実行し、その後...」などの簡単な指示シートに従って、リリースの実行が決まりきったものになるまで練習を続けます。

上記のリストは、リリースをスムーズに実行するために運用チームまたはリリース管理チームができることです。しかし、リリースのリスクを最小限に抑えるためにエンジニアリングは何ができますか？

1. リリースを小さくしてください。簡単に言えば、リリースに含まれるコード変更のセットが複雑になるほど、リリースのリスクが高くなります。同時期に少数の大規模リリースを行うのではなく、多数の小規模リリースを計画することで、運用チームを支援します。

2. テスト、テスト、テスト。QA環境でコードをテストするだけでなく、ステージング環境を使用してソフトウェアもテストします。多くの場合、コード自体にはほとんどまたはまったく関係のないバグがありますが、環境自体の構成（またはこの2つの組み合わせ）にある根本的な原因があります。これらの問題を見つけるには、本番環境、つまりステージングを厳密に反映した環境でコードをテストする必要があります。

最後の言葉として、時には最も重要なことは、物事がうまくいかないようにするために私たちがすることではなく、物事がうまくいかないときに私たちがどのように行動するかです。そのため、運用の透明性を中心に企業内に文化を構築することが重要だと思います。顧客から問題を隠そうとしないでください。Twitterを積極的に使用して、opsチームが現在認識し、解決に取り組んでいる問題があるかどうかを顧客に知らせてください（Lighthouseはこれで素晴らしいです！）。サービスの「ステータス」ページの公開を検討してください。顧客はこのページを参照して、何か問題があるかどうかを確認できます（TypePadがその良い例です）。結論としては、常に通信過剰の側に誤りがあります。あなたの顧客はそれに感謝します。

ここでの多くの回答は、問題に対する特定のソリューションの実装方法をすでに示していますが、私が知る限り、本当の問題はウェブサイトを適切に移行/更新することではありません。その背後にある設計/アーキテクチャが壊れやすい可能性があります。

その場合は、システムのアーキテクチャを調整して、構成設定が変更されたり適切に設定されていない場合でも適切に機能し続けるように十分に堅牢であり、発生した場合に適切に低下するように調整する必要があります。理想的には、新しいデータベース列を必要とする方法で新しい機能を追加したり、古い機能を変更した場合、列が欠落していてもサイトは機能します（新しい機能がないか、古い機能が劣化した形式である可能性があります） 。あなたのクライアントはお金を失うべきではありません-最悪の場合、彼はあなたが入れた改善から新しいお金を得ていないかもしれません。

システムが非常に脆弱で構成設定がこのような深刻な問題を引き起こす可能性がある場合、プログラムの更新が問題の唯一の原因となることはありません。別のソース。