5

私たちの会社は「稼働」日が近づいています（そしてQA部門の日付を取得しています）。私はこれをサポートするための適切な運用プロセスを定義しようとしています。私の大きな考慮事項は、必然的に発生した展開/構成の地獄を回避する方法です。QA、ステージング、および実稼働環境でビルドを正常にインストールおよび構成できるように、プログラマー以外のユーザーにビルドを渡すための優れたソリューションを見つけた人はいますか？

私たちの完全な環境は、異種のスケジュールされたタスク、Windowsサービス、およびWebサイトの混合で構成されており、これらはすべて、並列展開によってスケールアウトできます。ありがたいことに、構成の手段は一貫しています。残念ながら、すべて.NET web/app.configファイルを介して管理されています。私の経験では、QAと運用担当者は、それらを変更しようとすると常に混乱します（XMLは、ほとんどの人にとって驚くほど扱いにくいです！）

これが私が検討しているオプションです：

machine.configファイルの使用

これは私が実際に行ったことのないことですが、有望に見えます。環境によって異なる可能性のあるすべてのアプリケーションのすべての設定を含むmachine.configテンプレートを作成すると、管理者は1つのファイルにすべての変更を加えて、環境内の各マシンにデプロイできます。

長所：
これにより、システムの展開に必要な手順の数が減る可能性があります
短所：
構成スキーマの変更を何らかの方法で文書化する必要がある
不明：
カスタム構成セクションおよびアセンブリを参照するその他の構成拡張機能を利用します。これには、マシンのGACに.NETアセンブリをインストールする必要がありますか？

ビルドプロセスで設定ファイルの操作を実行します

QA、ステージング、および本番環境をソフトウェア（仮想サーバーやLANなど）と同じように設定すると、QAは、構成を変更せずに、すぐに使用できるソフトウェアをステージング環境に直接移行し、ステージングを本番環境に移行できるはずです。 。この設定により、理論的には、誰も触れる必要のないQAの事前構成されたfoo.configファイルを渡すことができます。

長所：
エンジニアリングは、構成ファイルが有効であることを確認するのにより熟達しています。
短所：
エンジニアリングが本番構成を認識することは、セキュリティ慣行としては不十分であると見なされる場合があります（不十分な議論、IMHO）

ネットワークに一元化された設定リポジトリを用意する

これは私には魅力的ではありません。これは、最終的に失敗した3つの方法で試したためです。

  1. 以前の会社では、データベースに構成設定がありましたが、そのデータベースへの接続文字列を構成する必要があるため、もちろんすべてをそこに入れることはできません。また、展開前にデータベースが適切に更新されていることを確認することも同様に困難でした。
  2. 私たちが試したもう1つのアプローチは、一種の集中型レジストリとして機能するネットワークサービスを用意することでした。これはほぼ機能しましたが、ローカルキャッシュ、構成サーバーへのURLが適切に構成されていることの確認、そしてもちろん構成サーバーの構成には常に問題がありました。
  3. Active Directory？えっ！もっと言う必要がありますか？

考え？

私が検討しているオプションの使用にどの程度成功しましたか？あなたのためにうまくいったこれらの代替案はありますか？

4

5 に答える 5

3

私はいくつかのことをすると思います：

まず、ステージングサーバーを使用します。エンジニアリングの場合でも非エンジニアリングの場合でも、サーバーへのコードの「模擬展開」を実行し、そこからテストする場所を用意します。これは、テストするための明確な「本番環境のような」環境を提供するという優れた目的を果たし、デプロイメントのすべてを無意味にすることを恐れて、誰もが気まぐれで不安定になることなく、デプロイメントトレーニングを可能にします。ハードウェアの面ではもう少しコストがかかりますが、それが防ぐエラーからはおそらくそれだけの価値があります。

次に、構成ファイルが本当に複雑で、エンジニア以外の人が作成するのが難しい場合は、展開用の検証ファイルを作成するクイックツールを作成します。基本的なデプロイメントパラメーターを取得し、それらに対していくつかの検証を行い、すべてを適切な形式で保存する単純なWebサイトまたはクライアント側アプリでさえ、技術の低い人々を支援するという点で驚異的です。入力を検証するツールがあるという自信は、こうしたタイプの人々にとって非常に役立つ可能性があり、検証された結果を備えた整形式のXMLが常に得られることを知っていると、エンジニアの心配時間も節約できます。

于 2009-06-15T19:28:31.583 に答える
2

使用するビルドの後に実行されるカスタムexeがあります。

私たちのプロジェクトには4つの設定ファイルがあります

web.config-開発（ローカルボックス）
web.integration.config-アルファテスト（アルファサーバーで実行）
web.staging.config-ベータテスト（ベータサーバーで実行）
web.production.config-本番（本番サーバーで実行されます）

exeは、必要なファイルを除くすべてのファイルを削除してから、名前をweb.config...に変更します。

開発者以外（QA、DBAなど）が構成ファイルを操作することは許可されていません。本番環境の値（メールサーバー、SQLサーバー）に変更され、重大な問題が発生する可能性があるためです...

それは私たちにとって非常にうまく機能します

于 2009-06-15T19:34:34.847 に答える
1

企業が本番環境をミラーリングする展開スクリプトと仮想マシンを使用して、ボタンを押すだけで展開されるQAビルドとステージングビルドを用意しているのを見てきました。これを行うには、Powershellを使用できます。

于 2009-06-15T19:24:11.467 に答える
0

これを実装した前の会社：

  • 開発者は、アプリごとにマスター構成ファイルを作成します
  • マシン/環境固有のトークンを特定し、それらを別のファイルに移動します
  • CIマシンはチェックアウトを実行し、ファイルに新しいバージョン番号のタグを付け、テストを実行してから、変更管理担当者が制御する中央共有にアプリケーションをコピーします。
  • 変更管理により、洗練された展開ダッシュボードが表示されます。次に、必要なアプリ、要求されたバージョン、および要求された環境を選択します。次に、移動ボタンを押します。
  • デプロイメントアプリは、ステージングされたファイル共有からサーバーにすべてのファイルをロボコピーします。
  • 次に、デプロイアプリは、ビルドスクリプトでそれ以降のタスクを開始します。
  • NAntスクリプトは各ターゲットマシンにコピーされ、P/Invokeを使用して開始されました

すべては、Anthill、NAnt、Robocopy、および展開を調整する軽量のカスタムアプリを使用して実装されました。使用する

これの最大の利点は、手動での展開手順がほとんどなかったことです。開発者の展開以降、すべてが再現可能でテスト可能でした。

この目的のために、私たちは可能な限り隔離しようとしました。GACとmachine.configsを大幅に回避しました。いずれにせよ、すべてのアプリが必ずしも新しいバージョンの共有コンポーネントに移行することを望んでいなかったため、これが速度にかなり役立つことが時間の経過とともにわかりました。

于 2009-06-15T19:43:31.567 に答える
0

私は常に、ローカル駆動とデータベース駆動の設定ストレージを組み合わせて成功を収めてきました。マシン固有の設定は、アプリケーション固有の（ユーザー固有ではない）設定と同様に、マシン上のXMLファイル（これにはルートデータベースの接続情報が含まれます）に保存されました。他のデータベースの接続情報を含め、ユーザー固有または企業全体の設定はすべてデータベースに保存されました。つまり、この情報を含む単一のデータベースがあり、クライアントはこれを使用して他のデータベースに接続できます。これにより、ルートデータベースへの接続を除くすべてを一元的に維持することができました。

于 2009-06-15T19:30:23.623 に答える