運用環境で使用されているUAT / QA /テストサービスを停止する方法
背景：一般に公開されているWebサイトで使用されている、大規模な組織の内部部門向けのWebサービスを開発しています。私とこれらの部門の同僚の間には地理的な違いがあるため、ほとんどの通信は電子メール、電話、スカイプなどで行われます。
私の開発プロセスは、チームと私だけがアクセスできるテスト環境で開発することです。これは問題なく、うまく機能します。
私と私のチームの他のメンバーがサービスに満足したら、ローカルドメイン（より広いLANエリア）にアクセスできるUAT /テスト環境にアップロードして公開し、別のオフィスのeコマースの同僚がフロントエンドのWebサイトをテストできるようにします。 /アプリケーションに対して。
ここで問題が発生します。テストが開始され、しばらくしてからeコマースの同僚が自分のチームまたはチームの知識（明らかな通信の問題）なしでこのUATサービスを使用するように本番環境/ライブ環境を更新します。 UATでサービスが中断し、eコマースの文句が何かが変更されたときのみ、私はそれを見つけます。
サービスは、タイトル/ドメイン名にUATで明確にラベル付けされています。ライブ環境で使用しないようにUATサービスを提供するときは明確に指定しました。テストなどの通知を受け取ります。次に、すべての関係者がサービスに満足したら、関連する変更管理プロセスを実行して、ライブプロダクションにアップロードします。環境。
UATサービスが制御できないライブ環境で使用されないようにするために使用する必要があるプロセス、方法、ヒント、アドバイスはありますか？
Davidb、私は問題が実際に何であるかを掘り下げてみます。
eコマースの同僚は、自分のチームが知らないうちにこのUATサービスを使用するように本番環境/ライブ環境を更新します（私が知っている明らかなコミュニケーションの問題）。
ここでは問題ありませんあなた。なぜあなたは彼らが彼らの環境で何をしているか気にしていますか？
uATで何かが変更され、サービスが停止し、eコマースが不満を言っています。
おそらくこれがあなたが気にする理由ですよね？ちょっと待って。生産でUATサービスを使用するという決定が生産上の問題につながる場合、eコマース部門は誰に不平を言う必要がありますか？この決定を下した人たちへ-eコマース部門へ！あなたはそれに全く関わっていません。
問題には技術ではなく解決策があり、個人の態度を変える必要があります。 eコマースからのそのような苦情を受け入れないでください、あなたはその責任を負いません。
完璧な世界では、コードは、それがテスト用か本番用かを知りません。同じ完璧な世界では、準備が整う前にサービスを運用に使用するよりも、同僚がよく知っているでしょう。
世界は完璧ではないため、本番環境になるまでサービスの食欲をそそる必要があります。
いくつかのアイデア：
@BartvanIngenSchenauがコメントで提案したように、おそらく週に1回データベースをリセットできます。これはテスト環境であるため、完全に合理的であり、間違いなく必要です。 定義により、テスト環境には本番データはありませんしたがって、あなたはあなたが望むように行う権利の範囲内です。
サービスを積極的にテストしていないときは、サービスを停止することを検討してください。
サービスにその出力を「透かし」に入れます。作成した文字列の多くに「TEST」を追加します。
環境へのIPフィルタリングアクセスについて、ネットワークサービス担当者と話し合ってください。
以下は、Dan Pichelmanの提案と一部重複するいくつかのオプションです。
- ネットワークのセグメンテーション。本番とテストの間で通話が交差するのを防ぎます。これは、さまざまな理由で逆方向にも適しています
- クライアント証明書。認証にクライアント証明書を使用すると、サービスに接続しているホストがわかります。
理想的には、これらの両方を実行します。最初はおそらくより信頼性があります。 2つ目は機能しますが、実稼働環境にあるサーバーを切り替えることができれば、ゲームを実行できます。特に次のラウンドのテストが行われるとき、それは彼らにとって苦痛でしょう。内部CAがある場合、クライアント証明書はかなり簡単なはずです。
本当にこれは変更管理の問題のようです。そのグループは、適切に実行できない場合、本番環境の構成を制御できません。彼らが直接それを行っておらず、誰かが彼らの要求に応じてこれを行っている場合は、そのグループに連絡し、これを行うことで、あなたが持っていると私が推測するポリシーに違反していることを指摘する必要があります。これにはあらゆる種類のセキュリティ問題があります。あなたはそれを人々をまっすぐ怖がらせるために使うことができます。何かがうまくいかなければ、それは彼らに戻ってくるであろうことを彼らに認識させます。
ファイアウォールやVLAN。
本番環境とDev/QA/UAT環境の間にファイアウォールがあり、本番サービスがDev/QA/UATインスタンスに接続できないようにする必要があります。または、本番サービスは本番VLANにデプロイされ、開発VLANまたはQA VLANにアクセスできません。
ええ、それを扱うのは面倒なことかもしれませんが、それはそれらの種類の問題が発生するのを防ぐことによって解決します。
組織内のリリースと展開のプラクティスには一般的な問題があると思います。
あなたのチームがサービスを開発するとき、それは通り抜けます：
- ビルド
- パッケージング
デプロイメントのパッケージ化の一部として、パッケージが作成されます。次に、パッケージを使用してさまざまな環境に展開します。各環境には、固有の構成があります。
それでは、2017年1月13日のビルドから作成されたパッケージXがあるとします。
- パッケージX-UAT構成
- パッケージX-PROD Config
PRODがUATを指すようにすることはできません。パッケージ（この場合はX）を、PROD構成を使用する実稼働環境にデプロイするようにプロモートします。
環境の境界を越えないように、構成は異なるURL、データベースなどを指します。
パッケージは、サービスにポイントされている環境ではなく、環境に昇格されます。
1つの選択肢は、管理コントロールパネルを作成することです。適切な承認があれば、適切なバックエンドコードでサービスをオン/オフにする一連のスライダースイッチを用意して、アクセシビリティを実装できます。
免責事項：私の現在の雇用主では継続的な統合を行っているため、私のアドバイスはそのような環境からのものです。うまくいけば、あなたが使えるものがあるでしょう。
より詳細なUATを検討しましたか？各変更が個別にUATを受ける場合、存続期間の短いUAT環境が多数存在するため、URLを区別する必要があります。機能名とインスタンスIDの組み合わせを使用しますが、これは事実上ランダムです。
UATコードを本番データベースにフックすることで問題が発生したことは一度もありませんが、誰かがこれを実行するためにそれを頭に入れて、どういうわけか必要な変更を行う権限を取得できた場合、安定したターゲットを見つけることは不可能です-彼らが見つけるターゲットさえあるとき。