可能な限り最善の方法で解決するためにフィードバックを使用できる問題に行き詰まっています。
この問題は、ソース管理 -> 自動ビルド -> デプロイを中心に展開しています。基本的にALM（アプリケーションライフサイクル管理）。
MS SQL データベースを備えた ASP.NET Web アプリケーションという製品があります。この製品は、実稼働環境の複数の仮想マシンにまたがる関連データベースを使用して、何百もの Web サイトで実行されています。現在、Web アプリケーションとデータベースは、IIS 7 と SQL Database Server 2008 R2 を搭載したサーバーで実行されています。製品自体は、Team Foundation 2012 でソース管理されています。
何年もの間、製品の新しいバージョンのリリースは年に 1 回か 2 回でした。これからは、より頻繁にリリースすることに集中するため、製品の ALM の戦略が必要になります。
現在の展開戦略:
リリース間の開発期間中、SQL 更新スクリプトは手動で作成され、データベースの変更が行われるたびにスクリプトが更新されました。アプリケーションをデプロイする準備が整うと、開発者のマシンでコンパイルされます。使用されたすべての変更を含むデータベースは、.BAK ファイルにバックアップされます。Web アプリケーション、.BAK ファイル、および更新 SQL スクリプトがパッケージ化 (.zip) され、デプロイの準備が整った運用環境にアップロードされます。
既存の実行中の製品を更新します。
- ターゲット Web サイトの物理フォルダーに Web アプリケーションをコピーして貼り付けます。
- web.config ファイルを更新する – 接続文字列とアプリケーション
- 変数。SQL Management Studio を介して更新スクリプトを実行します。
これは、顧客ごとに何百回も行われます。
これは非常に退屈でエラーが発生しやすい作業であり、私はまったく好きではありません!
代わりにやりたいことは次のとおりです。
- Team Foundation のデータベース プロジェクトとしてデータベースをソース管理する
- Team Foundation 2012 Build Server を使用して Web アプリケーションを自動的にビルドします。
- ビルド サーバーからの出力を、SQL Server に対して実行される自動生成された SQL 更新スクリプトと共に、運用環境の複数の Web サイトに展開します。
私は自分のお尻をグーグルで調べてきました-ビルド、展開、自動SQL更新スクリプトなどに関する断片を見つけるだけです.
データベースをソース管理し、TFS Build Server を使用することは、部分的に正しい方向だと思います。TFS ビルド サーバーからの出力を使用して、展開自体を簡単かつ制御された方法で行う方法について、私は非常に混乱しています。
理想的には、TFS ビルド サーバーを使用して、最新バージョンの Web アプリケーション、最新バージョンのデータベース、前のビルドから現在のビルドまでの自動生成された SQL 更新スクリプトを含む配置後のスクリプトを含むパッケージを作成したいと考えています。これは、nuget パッケージなどに含めることができます。次に、展開を管理する追加の Web アプリケーション (ターゲット、バージョン、iis Web サイト、SQL サーバー、web.config 接続文字列など) を作成できるようにしたいと考えています。
これを達成する方法について誰かアドバイスはありますか？これどうやってやるの？