5

私の過去および現在のWeb開発ポジションでは、ステージング/ベータおよび本番/安定環境でデータベースを共有しています。

何が起こっているのかについての私の理解は次のとおりです。

  • ステージング/ベータ版は、一般の人々がステージング/ベータ版にアクセスできないことを除いて、基本的に本番環境/安定版のサーバーと同じです。

  • QAのテストが、本番/安定データの独自のサニタイズされたサブセットコピーでコードの次の反復に合格したら、開発の次のステップは、コードの次の反復が本番/安定データのフルセットで機能することを確認することです。既存の本番/安定したWebサイトを壊す-それがステージング/ベータの目的です。また、企業は、ベータテスターに​​、世界中で見られるのと同じデータを使用してコードをテストさせることができます。次に、ベータテスターが親指をあきらめたとき、それはコードの古いイテレーションから新しいイテレーションへの単純な切り替えであるはずです。

私の直属の部下の一人はこれを「におい」と呼んでいました。彼は、Staging/BetaにはProduction/Stableのデータベースの完全なコピーが必要であると提案しています。したがって、QA中にキャッチされなかったStaging / Betaコードに本当に問題がある場合でも、Production/Stableのエクスペリエンスには影響しません。それがこれらの2つのリンクでの答えでした：

だからここに私の質問があります：どのような場合にステージング/ベータとプロダクション/ステーブルがデータベースサーバーを共有する必要がありますか？それとも、私の現在および以前の会社が間違ったことをしている/安い/などですか？

よろしくお願いします。

4

2 に答える 2

3

リソースの共有は、十分なリソースがない場合にのみ実行する必要があります:)

私はあなたの直属の部下に同意しなければなりません。あなたが遭遇する可能性のあるいくつかの問題、そしてそれらはそれほど珍しいことではありません：

  1. テストのプロセスは、本番環境からリソースを盗みます。
  2. 新しいコードが壊れて、リソースを消費しすぎています（＃1のバリエーション）
  3. 新しいコードには、本番スキーマと簡単に共存できない新しいスキーマが必要です。
  4. ベータ版の変更をインストールする過程で、本番環境を壊します。

ステージング/ベータ版を個別にホストしないことをどのように言い訳できるのか、私にはよくわかりません。

于 2013-01-08T23:33:37.220 に答える
3

目標は次のようです。

  1. ユーザーのサブセットに新しいバージョンを許可する（アジャイルワークフローに最適）
  2. 両方のバージョンが同時に実行されるため、データの損失や一意のキーの損失/重複を回避できます

私は同じような環境にいますが、上記を可能にする文書化された開発ライフサイクルを見つけることができないようです。A/Bテストと「カナリアリリース戦略」のクロスだと思います。

テストと本番の間の4番目の環境でこれを解決しました（実際には本番ですが、ベータと呼びます）。

  1. アルファ開発者テスト。これは、開発者がブランチをプッシュしてコードをマージする場所です。
  2. QA/ステージングユーザーテスト。これは、新しいバージョンがリリースされた後の本番環境と同じになります。）
  3. ユーザーのサブセット向けのベータ版の制作。（「ベータ」の制作データがあると監査人が緊張するので、より良い名前を考え出そうとしています。「カナリア」が飛ぶかどうかはわかりません...しゃれは意図されていません。
  4. www（一般提供）

ショーストッパーは、ステージング/ QAとは別の本番環境であるため、（このコンテキストでは）ベータ版になることはありません。

この回答が気に入った場合は、リリースサイクルまたは展開戦略に私にちなんで名前を付けることができます:)

于 2016-10-27T16:27:40.160 に答える