開発が必要な複数の機能がありますが、どの機能をライブにするかは管理者が決定します。これには、ユーザー ストーリー/変更ごとにスクリプトが必要です。しかし、DB スキーマの変更を TFS のユーザー ストーリーにリンクするにはどうすればよいでしょうか?
今あるもの:
ユーザー ストーリー/タスクを使用した TFS CC.net Buildserver
私は SSDT の調査を行いました。しかし、どうすればこれをTFSとリンクできますか?
読んでくれてありがとう、
アンディ。
開発が必要な複数の機能がありますが、どの機能をライブにするかは管理者が決定します。これには、ユーザー ストーリー/変更ごとにスクリプトが必要です。しかし、DB スキーマの変更を TFS のユーザー ストーリーにリンクするにはどうすればよいでしょうか?
今あるもの:
ユーザー ストーリー/タスクを使用した TFS CC.net Buildserver
私は SSDT の調査を行いました。しかし、どうすればこれをTFSとリンクできますか?
読んでくれてありがとう、
アンディ。
データベース スクリプト (または、その方向に移動することを選択した場合は SSDT プロジェクト) が TFS バージョン管理にチェックインされている限り、 と の間に深いつながりがchangesets
ありwork items
ます。コードをチェックインする前に保留中の変更を確認する場合、作業項目 (つまり、ユーザー ストーリーまたはタスク) を関連付けるオプションがあります。Visual Studio 2012 を使用している場合、作業項目の関連付けは次のようになります。
経由でチェックインしている場合は、次のようになりますWindows Explorer
。
相互に独立したシステムに変更を加えると、非常に複雑になる可能性があります。私が見つけた最善の解決策は、展開後に機能を有効または無効にする「機能トグル」を作成することです。トピックとして継続的デリバリーを見てみましょう。Jez Humble はこのテーマについて素晴らしい本を書きました。
データベース スキーマの変更は、機能の有効化または無効化よりも複雑になる場合があります。拡張/縮小モデルを使用することをお勧めします。事前に新しい構造をデータベースに追加し、それを中断しない方法で本番環境にデプロイします。次に、その構造に依存する機能を有効にすると、それは既にそこにあります。何かを削除した後にデータベース スキーマをクリーンアップする必要がある場合は、他のソフトウェアの変更と一緒に帯域外で「契約」サイクルを実行して、テストの表面積を減らすことができます。