そのため、私は継続的インテグレーション プラクティスの開発に取り組んでいます。私たちは .Net/MSSQL ショップです。まもなく VS2012 になります。プロジェクトをコンパイルするためにmsbuildを使用して、CIサーバー用のCruiseControl.Netに落ち着きました。ソース管理にはSVNを使用します（後でGitに切り替える可能性がありますが、それは別の議論です）。私は、InstallShield を使用してコード パッケージ (通常は Web アプリやバッチ実行可能ファイル) を QA および実稼働サーバーに展開することに傾いています。(CCNet はこれらの MSI を CI の一部として構築します。)また、プロジェクトに単体テストを含め始めており、CCNet と統合された NUnit を使用して、チェックイン時にそれらを自動的に実行します。
これまでのところ、これは標準の Web アプリ/exe 開発で機能します。それが (まだ) 適合していないのは、MSSQL 変更管理、またはその欠如です。私たちがこれをどのように行ったかは、かなりカウボーイでした。一部の人々は Migrator.Net を使用しています。他の人は、Redgate で SQL Compare を実行し、スクリプトを生成するだけです。さらに、手書きの SQL スクリプトを持っている人もいます。SVN にある場合とない場合があります。データベースレベルでの「ソース管理」とは、基本的に「データベースのバックアップを持っている」ことです。 ブー、ヒス。言うまでもなく、CI およびデプロイとの一貫性が必要な場合は、何かを決める必要があります。これまでのところ、変更管理と展開を処理するために VS SQL プロジェクトを使用することに傾いています。
注: 私たち (開発者) は、変更をプッシュすることは想定されていません。システム管理者はそれを行います。そのため、コードや SQLをデプロイするために何も実行できません。
だから、解決すべき2つの問題（私は思う）：
CIサーバーがデータベースのCIバージョンを吹き飛ばして、単体テストをテストできるようにするために使用する「手法」。私は、VS2012 SQL プロジェクトでそれができると決めました。CCNet は、データベースを再作成する db プロジェクトに対して msbuild を実行できます。これはかなり簡単です。
QA および本番環境用の変更スクリプトを生成する方法は? これは私が立ち往生しています。
VS はスキーマを比較してから SQL スクリプトを生成できますが、これは sqlcmd に依存しています。そのため、システム管理者はコマンド プロンプトから sqlcmd を実行して展開する必要があります...おそらく理想的ではありません。右？
msbuild を再度実行してデプロイすることもできますが、データベースを再作成するのではなく、変更をデプロイするだけです。
では、ここでのオプションは何ですか？管理者が実行し、SVN にチェックインするための自己完結型のものが必要です。データベースの展開用に別の msi を作成する必要がありますか? CCNet/msbuild は、システム管理者がダブルクリックして実行できる、データベースの変更 (再作成ではない) 用の別の種類の「展開パッケージ」を作成できますか?
皆さんはこれをどのように処理しますか？
ありがとうトム