1

私は小さな会社の開発者で、一貫した変更管理に苦労しています。開発者以外のスタッフが、実稼働インストールでストアド プロシージャとトリガーを微調整しているという問題に直面しています。これらの変更は、開発チームがデータベースの変更がソース管理に組み込まれていることを確認するために使用するプロセスから外れたため、アップグレードを適用すると上書きされます。

技術的および個人的な観点から、この問題にどのようにアプローチすることをお勧めしますか?

編集 1: 現在のプロセスの背景を少し説明すると、これに役立つ可能性があります。継続的インテグレーション サーバー (TeamCity) を使用して、チェックイン時にインストール アーティファクトとラベル svn を生成しています。残念ながら、不正なスキーマの変更を止めることは私の能力を超えているため、オーバーライド可能なトリガー/sp 定義を可能にする設計パターンを見つけたいと思っています。

4

2 に答える 2

0

明確に分離する必要があります:

厳密な ACL によってリリース環境が保護されており、正式に任命された人がデプロイや変更を行うことを防いでいる場合、本番環境での微調整は不可能です。
その展開プロセスが自動化されている場合、すべての変更は適切なチャネルを通過します。これは、単純な「プッシュ ボタン」プロセスでホットフィックスを展開するのに十分であることを誰もが知っているからです。

ただし、ソース管理でその修正を取得して展開するのが複雑な場合は、通常、本番環境で直接調整する必要があります...

于 2011-05-23T21:37:57.293 に答える
0

特に本番環境では、ストアド プロシージャとトリガーを変更する権限を制限します。先に進んで、不意を突かれないように最初に知らせますが、すべての不正な変更から本番環境を明確に保護してください。

于 2011-05-23T21:39:11.273 に答える