問題タブ [staging]

Web アプリケーションが実稼働環境で使用されるようになると、拡張機能やバグ修正で更新するのに非常に苦労します。主な理由は、CMS システムの設計における初期の欠陥です。通常、各製品環境を更新するために何時間も費やす必要があり、エラーや長時間のデバッグが何度も発生します。私は泣き言を言っているように見えるので、議論の客観的な部分に戻りましょう。

この欠陥は、コンテンツとプログラミング機能がデータベースに一緒に保存される方法に起因します。つまり、基本的にデータがどのように表示され、データ自体がデータベースに保存されるかです。いくつかのファイル システムの変更がありますが、コンテンツに関連するものではありません。また、アプリケーション自体が、データベースで追跡できない多くの参照を作成します。

アプリケーションがエンドユーザーと利害関係者によって使用されていることがわかるように、開発チームは手動で変更を本番環境に公開する必要があります。

もう 1 つの問題は、データベースが変更されると、アプリケーションがファイル システムを動的に変更することです。そのため、開発環境と本番環境の両方が異なり、それらを同期するためにデータを移動するか、開発チームが多くの手作業を行う必要があります。

もっと詳しく説明したり、さらに例を挙げたりできます。必要な場合はコメントをください。

php/mysql Web 開発の適切なワークフローについて考えています。

ヒントを得た人はいますか？

のデータベースが3つあるとします。

• 製造
• 演出
• 開発者

私の知る限り、ステージングデータベースは本番データベースと同期している必要がありますが、

開発中は、 Devデータベースでやりたいことが何でもでき、スキーマを変更できます。さて、ここに鶏が先か卵が先かという問題があります。

ステージングでテストするには、Devデータベースで行われた変更に応じてステージングデータベーススキーマを変更する必要があります。ただし、ステージングデータベースは本番環境と同期している必要があります。

どうやってこの問題を回避しますか？

Rails アプリ用のステージング サーバーをセットアップしたいと考えています。私は git と github、Cap を使用し、Apache/Passenger で VPS を使用しています。ステージング サーバーの構成とそれとやり取りするプロセスの両方に関する限り、ステージング セットアップのベスト プラクティスについて興味があります。本番サーバーと可能な限り同一にする必要があることはわかっていますが、パブリック アクセスを制限するとそれが制限されるため、私が使用するためだけにセキュリティを確保するためのヒントも役立ちます。

もう 1 つの具体的な質問は、VPS 上に仮想ホストを作成して、ステージング サーバーを本番サーバーと一緒に配置できるかどうかです。ただし、これを回避する理由があるかもしれないと感じています。

ステージング テーブルは、rpc (Java RMI や何らかの Web サービス呼び出しなど) またはメッセージング キュー (JMS など) がより適切なソリューションである場合に使用されるアンチ パターンですか? それとも、ステージング テーブルの方が適している問題はありますか?

明確にするために：

ステージング テーブルとは、プロセスによってレコードがテーブルに追加され、2 つまたは複数のプロセスによって読み取られ、処理される場合を意味します。間隔の終了ステータス (1 日の終わり、支払い期間の終了など) を反映することを意図したテーブルについて言及しているのではありません。ほとんどの場合、ステージング テーブルのスキーマは、顧客やアカウントなどのアプリケーション データ型を厳密に模倣しています。

このアンチパターンの潜在的な原因:

1) 2 つのプロセスの所有者間のビジネス ユニット ウォールは、ステージングへの書き込みまたは読み取りを行うプロセスが変更されるのを防ぎます。

2) ステージングへの書き込みまたはステージングからの読み取りプロセスの信頼性が低いため、開発者は「何かが失敗した場合に」データの損失を防ぐためにテーブルを使用するようになります

3) 知識の欠如または DGAS (^%$@ を与えないでください) の態度

経営陣は、メイン Web サイトにサービスを提供するために、IIS7 を搭載した Windows 2008 64 ビットを採用することを決定しました。

彼らは、IIS6 を使用する Windows 2003 サーバーでステージングしたいと考えています。　[編集]はい、32ビットはステージングのために計画されているものです[編集終了]

セキュリティの問題を超えて、どのような問題を提起すべきかを知りたいです。ステージングでは、ライブ環境と同じサーバーを選択する必要があることを示唆しています。

私はこのような素晴らしい記事を読みましたが、いくつかの箇条書きで何か言いたいことがあります

ステージング環境とライブ環境は同じであるべきであり、ベテランの開発者なら誰でも簡単に理解できますが、私の問題は、すでに決心しているように見える上層部の管理者にこれを説明しようとしているということです...

[編集] @ルーク:

基本的に、かなり頻繁に更新される Web サイトであり、ライブ環境にデプロイする前に、サイト全体をステージングしてテストする必要があります。

サイトはマーケティング部門 (非開発者) の手に委ねられ、展開前にサイトに問題がないことを確認してもらいます。

[編集++] コードは ASP.NET で、3 つの重要な顧客注文ページで使用されています。

ありがとう、

リック

私は他の開発者と一緒に開発、ステージング、本番サーバー環境を使用しています。

現在、変更を加え、開発サーバー（パーソナルコンピューター）でテストし、変更に満足してクライアントまたは内部レビューに表示したい場合は、リポジトリに変更をコミットし、sambaを介してステージングサーバーの作業コピーを更新します（tortoiseSVN）またはssh。

これは本当に退屈で繰り返しになります。コミット後のフックでリモートステージングサーバーを更新することを検討していますが、唯一のオプションは、SSHのフックにユーザー資格情報をハードコーディングするか、ユーザーアカウントでネットワークマウントを作成することです。最初のコミットからステージングサーバーにユーザー認証を渡して更新またはその他の提案を行う方法はありますか？

他のセットアップソリューションを歓迎します。

私は自分のリリースストレージサーバーを作成することを考えています。これを行う前に、作成する代わりに統合を確認するために人々が何を使用するかを知りたいと思います。

では、内部アクセス用にビルドを保存するために何を使用しますか？

アーティファクトをアップロードしてから、さまざまなタグで参照できるWebアプリを探しています。これにより、アーティファクトをコンポーネントごとにグループ化したり、車両をリリースしたりできます。また、準備や昇進によるビルドごとのアクセス制御も必要です。

ステージングとは、ユーザーのコミュニティがアクセスできるように、ビルドされたアーティファクトをサーバーに配置することと定義します。アーティファクトは通常、アプリケーションまたはライブラリとドキュメントのいずれかを含むzipファイルです。ユーザーコミュニティは、開発者、QA、およびサービスの提供/運用です。基本的に、作成者、チェッカー、外部ユーザー。

アーティファクトを個別にリリースし、リリースビークルでグループとしてリリースします（たとえば、リリース1.1にはfoo 1.0.1とbar1.0.7が含まれています）。アーティファクトによっては、アクセスを制限したい場合があります。オペレーションはプレリリースされたビルドにアクセスできないようにする必要があり、限定された可用性リリースをダウンロードしたユーザーを追跡したい場合があります。

ですから、私が持っていないものを追加できるように、優れた拡張可能なデザインで私が望むことのほとんどを実行するツールを見つけたいと思っています。

ビルド後にビルドを管理するための優れたツールを知っている人はいますか？

例は次のとおりです。

• クイックビルド/ラントビルド
• チームフォージ
• フォージを構築する
• JiraとConfluenceのセット
• ソナタイプネクサス
• 自家栽培
• 分岐を使用してdev->Qa->GAからのビルドを促進するSVNリポジトリ

最近、Django アプリをライブにプッシュしました。サーバー上のステージング サブドメインにアプリを構築しました。ライブに移行したとき、ステージング サブドメインのファイルをメイン サイトにコピーし、ステージング データベースを作成して、古いステージング サイトを新しいステージング データベースに向けました (新しいライブ サイトは元のデータベースに向けたままにします)。これは Apache の下の mod_python にあります。

両方のサイトに固有の SESSION_COOKIE_NAME 設定を作成し、ライブ サイトでは SESSION_COOKIE_DOMAIN を ".sitename.com" に、ステージング サイトでは None に設定しました。

私たちが見ている問題は、ライブ管理者のユーザーが編集を行っており、それが (表示されているように) ステージング サイトに保存されていることです。ユーザーは、リクエスト中に管理サイトから「ランダムに」ログアウトされます。

ここで明らかに間違っていることはありますか？サブドメインが「staging.sitename.com」にあるため、SESSION_COOKIE_DOMAIN を「www.sitename.com」に制限する必要がありますか? 現在稼働中のデータベースに古いセッション情報を残しましたか (この問題が発生する前に、./manage.py clean を実行して稼働中のデータベースからすべてのセッションを削除しました)。

ありがとう

1 つの CMS と 3 つのスレーブ サーバーを備えた段階的な環境があります。

パブリッシュが成功したときにステージング モジュールによって呼び出され、すべてのインデックスとリンク データベースを再構築するページをスレーブ サーバーに作成したいと考えています。

私は使用できることを知っています：

リンクデータベースを再構築します。

サイトコア コンテキストにアクセスできる別のプロセスで上記のコードを取得する方法と、Web データベースのすべてのインデックスを別のバックグラウンド スレッドで再構築する方法を教えてください。

ありがとう