5

SQL ソース管理を開始しようとしていますが、いくつか質問があります。

これが私が目指していることです。これはうまくいくように見えますか？

  1. 開発データベース テーブル/プロシージャを変更する
  2. dev PC の dev git ブランチに commit する
  3. 変更を中央リポジトリにプッシュする
  4. 変更ごとに手順 1 ～ 3 を繰り返します
  5. dev ブランチを test ブランチにマージします
  6. テスト ブランチで SQL Source ConGtrol "Get Latest" を使用する
  7. 変更をテスト DB に適用する
  8. 手順 5 ～ 8 を繰り返しますが、テストからライブまで

注: - 「共有データベース」開発モデルを使用します。

質問:

  • これはうまくいくように見えますか？
  • SQL ソース管理はテスト データベースとライブ データベースに変更を適用できますか
    • または、開発サーバーがこのタスクを実行するために SQL Compare のコピーを購入する必要がありますか?

ここに画像の説明を入力

4

3 に答える 3

2

はい、これで問題ないと思います。従来、ブランチのマージに関する問題は移行スクリプトで問題を引き起こしてきましたが、Migrations V2 のベータ版ではこの問題だけでなく他の問題にも取り組んでいます。

何らかのビルド システムをリポジトリにリンクしている場合は、SQL 自動化パックを使用してテストするために展開する後半部分を自動化できます。たとえば、TeamCity のようなものは、マージを実行してトリガーし、テストを更新して、手動で行う必要があるのを防ぎます。

于 2013-10-10T14:44:44.690 に答える
2

データベースの変更のバージョン管理されたコピーをリポジトリからデプロイしているのは素晴らしいことです。これは、継続的デリバリーの実践として非常に優れていると思います。

あなたの質問についていくつかの提案があります (私は Red Gate の帽子をかぶっています)

  • 通常、SQL ソース管理をライブ環境に接続することはお勧めしません。変更を探すためにポーリングしますが、これはライブ システムでは望ましくない場合があります。推奨されるのは、代わりに SQL Compare を使用して、UAT/実稼働システムへの 1 回限りの展開を行うことです。または、Red Gate Deployment Manager製品に興味があるかもしれません。

  • テストでの共有/専用モードについて上記で質問します。開発ブランチで開発者用の共有データベースを使用してから、テスト ブランチで専用モデルを使用しているかどうかは問題ではありません。テスト データベースへの唯一の変更が 1 つの場所 (たとえば、git の展開) からのものである場合は、おそらくそのデータベースを専用モードで実行することをお勧めします。

私はあなたのものにいくつかの微調整を加えて図を描きました。CIサーバーを使用しているかどうかはわかりませんが、それがプロセスに収まる場所を追加しました. この図は、2 人の開発者に専用モードを想定していますが、代わりに共有データベースにすることもできます。

Red Gate SQL ソース管理 継続的なデータベース配信

于 2013-10-14T12:01:51.663 に答える
0

はい、正しい接続モデルを使用している限り、これは機能するようです。

Red Gate ではベスト プラクティスとは見なされていません (理由は次のとおりです)。彼らは、SQL Compare も購入することを望んでいます。

専用モデルを使用してすべてのデータベースに簡単に接続できますが、特定のオブジェクトを変更したユーザーを確認する機能は失われますが、ライブからパッチをマージできます.

私はこれを好みます：

  • 開発者は共有モデルを使用して接続します
    • 次に、各テーブル/プロセス/などを誰が変更したかを確認できます。
  • また、共有モデルを使用して開発サーバーに作業フォルダーを保持します。
    • これにより、get-latest を使用して、ライブからのパッチで dev を更新できます。

混合モデル機能がリリースされれば、より簡単になる可能性があります(ここで投票してください)。

変化の経路を示す図

于 2013-10-16T13:54:29.007 に答える