[解決済み] ソース管理からどのようにデータベースを構築するべきか？

どのプラクティスが本当にベストなのか、いくらか主観的であることは承知していますが、何が効果的であるかについての良い対話は、多くの人々にとって役に立つと思われます。

このトピックで懸念される領域について、いくつかお勧めの質問を挙げてみました。これらは決定的なリストではなく、私が何を求めているかを理解するのに役立つ、人々のための出発点です。

1. テスト環境と本番環境の両方をソース管理から構築する必要がありますか。
   
   
   • 両方とも自動化を使用して構築すべきでしょうか - それとも、安定し、完成したテスト環境からオブジェクトをコピーすることによって本番環境を構築すべきでしょうか？
   • デプロイメント スクリプトにおいて、テスト環境と実稼働環境の潜在的な違いにどのように対処しますか?
   • デプロイメント スクリプトがテスト時と同様に本番環境でも効果的に機能することをどのようにテストしますか?
2. どのような種類のオブジェクトをバージョン管理すべきでしょうか。
   • 単なるコード (プロシージャ、パッケージ、トリガー、Java など) ですか?
   • インデックス？
   • 制約事項?
   • テーブル定義?
   • テーブル変更スクリプト? (例: ALTER スクリプト)
   • すべてですか？
3. バージョン管理されるべきではないオブジェクトの種類は？
   • シーケンス?
   • グラント?
   • ユーザーアカウントは？
4. データベース オブジェクトは、SCM リポジトリ内でどのように整理されるべきですか？
   • 変換スクリプトや ALTER スクリプトのような 1 回限りのものをどのように扱うか。
   • データベースからオブジェクトを削除する場合、どのように対処しますか?
   • 誰が の推進 オブジェクトを開発レベルからテストレベルへ昇格させるのは誰でしょうか？
   • 複数の開発者からの変更をどのように調整しますか？
   • 複数のシステムで使用されるデータベースオブジェクトの分岐をどのように処理しますか?
5. このプロセスに合理的な例外があるとすれば、それは何ですか?
   • セキュリティ上の問題ですか？
   • 非識別化に関するデータですか？
   • 完全に自動化できないスクリプト？
6. プロセスに弾力性を持たせ、強制力を持たせるにはどうしたらよいでしょうか？
   • 開発者のエラーに？
   • 予期せぬ環境問題へ？
   • 災害復旧のため？
7. DB-SCMの利点が本当にコストを正当化することを、どのようにして意思決定者に納得させるのですか？
   • 逸話的証拠？
   • 業界研究？
   • 業界のベストプラクティスの推奨？
   • 公認の権威へのアピール？
   • コスト/ベネフィット分析？
8. このモデルでは、誰がデータベース・オブジェクトを所有すべきですか？
   • 開発者ですか？
   • DBAですか？
   • データアナリスト？
   • 1人以上？

どのように解決するのですか？

ご質問に対する回答です。

1. テスト環境と本番環境の両方をソース管理から構築する必要がありますか? はい
   • 両方とも自動化を使用して構築すべきでしょうか。それとも、安定し、完成したテスト環境からオブジェクトをコピーすることによって本番環境を構築すべきでしょうか。
   • 両方とも自動化します。環境間でデータをコピーしないでください。
   • デプロイメントスクリプトでテスト環境と本番環境の潜在的な違いにどのように対処しますか？
   • テンプレートを使って、環境ごとに異なるスクリプトを作成する（例：外部システムの参照、データベースの連携など）
   • デプロイメントスクリプトがテスト時と同様に本番環境でも効果的に機能することをどのようにテストしますか。
   • 本番前の環境でテストします。本番環境の完全なコピー (データベースやその他のシステムの可能性もあります) でデプロイメントをテストします。
2. バージョン管理されるべきオブジェクトの種類は？
   • 単なるコード (プロシージャ、パッケージ、トリガー、Java など) ですか?
   • インデックス？
   • 制約事項?
   • テーブル定義?
   • テーブル変更スクリプト? (例: ALTER スクリプト)
   • すべてですか？
   • すべて、そして。
     • 静的データ (ルックアップリストなど) を忘れないでください。
     • データベーススクリプトの最新版のみを保持し（もちろん、バージョン管理されています）、そして
     • ALTERスクリプトを保存します。1つの大きなスクリプト(または001_AlterXXX.sqlという名前のスクリプトのディレクトリ。自然なソート順で実行するとバージョンAからBにアップグレードされる)
3. バージョン管理されるべきではないオブジェクトの種類は？
   • シーケンス?
   • グラント?
   • ユーザーアカウントは？
   • を参照してください。 ユーザー/ロール (または技術的なユーザー名) が環境間で異なる場合でも、テンプレートを使用してスクリプトを作成できます (1. を参照してください)。
4. データベース オブジェクトは、SCM リポジトリ内でどのように整理されるべきですか？
   • 変換スクリプトや ALTER スクリプトのような 1 回限りのものをどのように扱うか。
   • 2を参照してください。
   • データベースからオブジェクトをリタイアさせる場合、どのように対処するのですか？
   • DBから削除、ソース管理から削除 trunk/tip
   • 開発レベルからテストレベルへのオブジェクトの昇格は、誰が責任を持つべきでしょうか？
   • dev/test/release スケジュール
   • 複数の開発者からの変更をどのように調整するのですか？
   • 開発者ごとに別々のデータベースを作らないようにしてください。 ソース管理を使っていますよね？ この場合、開発者はデータベースを変更し、スクリプトをチェックインします。完全に安全にするには、夜間ビルド時にスクリプトからデータベースを再作成してください。
   • 複数のシステムで使用されるデータベースオブジェクトのブランチングをどのように扱うのですか？
   • タフなもの：何としても避けたい。
5. このプロセスに合理的な例外があるとすれば、それはどのようなものですか？
   • セキュリティ上の問題ですか？
   • 特に毎日/毎晩のDB再構築を自動化している場合は、開発用に許可することができます。
   • 個人を特定できないようにする必要があるデータですか？
   • 完全に自動化できないスクリプト？
   • リリース情報/ALTERスクリプトと一緒に文書化し、保存します。
6. どのようにすれば、プロセスに弾力性と強制力を持たせることができるのでしょうか。
   • 開発者のエラーに？
   • ゼロからのデイリービルドでテストし、増分アップグレード（ALTERを使用してバージョンAからBへ）と結果を比較する。結果のスキーマと静的データの両方を比較する。
   • 予期せぬ環境問題に?
   • バージョン管理、バックアップの活用
   • は、特にデプロイメントの前に、PRODデータベーススキーマをあなたが考えているものと比較します。SuperDuperCool DBA はチケットシステムにはないバグを修正したかもしれません。）
   • ディザスタ リカバリのため？
7. DB-SCMの利点が本当にコストを正当化することを、どのようにして意思決定者に納得させるのですか？
   • 逸話的証拠？
   • 業界研究？
   • 業界のベストプラクティスの推奨？
   • 公認の権威へのアピール？
   • コスト/ベネフィット分析？
   • のようなソフトを買うのにお金が必要な場合は別として）開発者とDBAが同意すれば、誰も説得する必要はないと思います。 dbGhost のようなソフトウェアを買うお金が必要でなければ）。
8. このモデルでデータベースオブジェクトを所有するのは誰ですか？
   • 開発者ですか？
   • DBAですか？
   • データアナリスト？
   • 1人以上？
   • 通常、DBAはモデルを承認します（チェックイン前またはコードレビューの一部として後）。彼らは間違いなくパフォーマンスに関連するオブジェクトを所有しています。しかし、一般的にはチームがそれを所有します[そしてもちろん雇用者も:)。