2009-08-11 8 views
3

DDL/DMLおよびPL/SQLスクリプトをソース管理(Microsoft Visual Studio TFSを使用しています)に格納する方法に関する推奨事項やガイダンスを探しています社内でSaaSアプリケーションを開発しました。Oracle DDL/DMLスクリプト、ソース管理のPL/SQL

私たちは、非常に単純なDev/Mainブランチモデルに基づいたプロジェクトを担当する7人までの開発者からなるチームを持っています。スクリプト間には依存関係(主に実行順序)があります。

同様の状況でうまくいったことは何ですか?

+1

にアクセスできますか?http://stackoverflow.com/questions/706026/706596#706596とそれからのさまざまなリンクを確認しましたか? – dpbradley

+0

私は、スクリプトの整理とその後のデプロイメント、優先順位の問題の扱いなどに関するガイダンスやベストプラクティスをもっと探していますが、質問の参考に感謝します。 –

+0

私はこの[関連するスタックオーバーフローポスト]にいくつかのコメントを入れた(http://stackoverflow.com/questions/706026/how-do-you-work-on-oracle-packages-in-a-collaborative-version-controlled -environ/7122534#7122534) –

答えて

0

DDLスクリプトはソース管理下に置いていましたが、DMLの場合はと似たようなものを使用しましたが、私たちはPerlで書かれているのでちょっと厄介でした。

0

私たちのソース管理における足の簡素化外観は次のようになります。

\DatabasePatches 
    \Core 
    \Data 
\DatabaseSource 
    \Core 
    \SchemaA 
    \SchemaB 
    \SchemaC 

DDL作業の特定のチャンクのために書かれたとDML /移行がデータパッチの下にチェックインしてコアパッチの下でチェックされています。パッチ・ラベルの一部はシーケンス番号であり(パッチを今後挿入するたびに10を手動で追加する)、パッチは「DATAPATCH01530 - migrate of xyz.sql」と呼ばれることがあります。

新しい環境に展開するときは、すべてのコアパッチが実行され、データパッチが実行されます。コアパッチの次の部分で重要なDMLがある場合、そのコアパッチに含まれることがあります。

パッチが新しい場所で初めて実行されると、ファイルはソースコントロールでFINALとマークされます(PVCSを使用し、FINALというユーザーでファイルをロックします)。矛盾を引き起こします。追加の変更は、別個のパッチに含める必要があります。

ストアドプロシージャ、関数、パッケージなどは、DatabaseSourceレッグの下に保存され、チェックインされます。スクリプトを実行する前にこれらのオブジェクトが宣伝されているかどうかを保証することはできませんので、スクリプトでスタブを作成することで対応します(例:SELECT '1' FROM dual、パッケージにはダミープロシージャが含まれます)存在し、特権などを与えることができます。実際のオブジェクトが昇格されると、それはスタブを置き換えて特権を保持します。

0

LiquiBase(http://en.wikipedia.org/wiki/LiquiBase) LiquiBaseは、データベースの変更を追跡、管理、適用するためのオープンソースデータベース非依存ライブラリです。 (XMLベース)

これは独自の方法でスクリプトを注文できるビルドシステムを備えています。 あなたが必要とするのは、正しい順序でインクルードするだけです。私はそれが助けなければならないと思う。

このツールを使用してデータベースDMLを追跡し、PLSQLの変更をGITバージョン管理で追跡します。

0

なぜDDLスクリプトを保持しますか? もう一度それらを使用することはできません。それらを生産と比較せずに信頼することはできません。 私はDDL(良いアイデアのように聞こえる以外の)を保つ唯一の理由は、各スキームを1つのファイルに入れて完全なベースラインを比較できることです。これにより、展開の前にdiffを実行して変更を確認することができます。

私は多くのプロジェクトでDDLをチェックしていますが、何がプロダクトではなくソースコードチェックアウトの上に変更を加えることでそれを発見しました。私たちは変化を失った。

DBは、フロントエンドのソースコードとは異なります。データベースに接続してsql-plusやtoadを通じて変更を加えて緊急の問題を解決することができれば、ソースコード管理に変更を加えることはありません。 DBAは変更を加えることができます....

私の意見では、それは良いとは言えますが、実際にはうまくいきません。

+0

あなたが説明している問題は、バージョン管理が適切かつ一貫して使用された場合に有益な理由のいくつかです。人々が緊急対策を講じても、適切な変更管理手順に従うべきであり、バージョン管理ツールではそれが可能になります。 – Tim

1

Oracle DatabaseにPL/SQLコード(またはCREATE OR REPLACEコマンドで作成できる他のオブジェクト)を管理できるツールを構築しました。 GitをOracleデータベースにフックします。

コミット、リセット、分岐、クローニング、マージ、プルなど基本的なGitタスクを実行できます。Gitoraは自動的にデータベースのPL/SQLコードを更新します。

テーブルを処理しないため、これはまだ手動タスクです。

私たちは誰でも無料でGitoraを利用できるようにすることを決めました。それは14年12月に出ています。サインアップしてwww.gitora.com