私が取り組んでいるソフトウェア システムは、医療費請求システム、大量のデータとデータ テーブル、およびストアド プロシージャです。
私は記事「より良いコードへの 12 ステップ」を読んでいて、The Joel Test #2 で次のように述べています。
これは展開ビルドを意味するのでしょうか (顧客が展開を更新できるようにするため)。
今、私が直面している主な問題は、ワンステップのデータベース更新をどのように行うかということです。
現時点では、データベースに変更を加えると、すべての変更が記録され、データベース更新スクリプトに追加されます。このスクリプトは、デプロイ トゥ カスタマー ビルドが作成されるときにバージョン番号を取得します。
これを行う簡単な方法はありますか？データベーススキーマを「前後」に見て、私が言及したような更新スクリプトを作成するスクリプトまたはアプリケーションはありますか?
それとも、これは誰もが行う方法であり、信じがたいですが、もっともらしいと思います.
自動化されたシステムはエラーを減らし、展開のビルド時間を大幅に短縮します。その方法を知りたいです。
経験できるさまざまなレベルの複雑さがあります。
手動で作成した更新スクリプトがあり、それらをさまざまなサーバーに簡単に適用する方法を探している場合は、SSW Consulting によるSSW SQL Deployを確認してください。そのシナリオを非常にうまく処理できます
データベース差分アプローチをより多く行う傾向がある場合は、Red Gate のSQL Compare (前述) とSQL Packagerが優れた組み合わせになります。古いものと新しいものの間でデータベースを比較し、EXE または C# プロジェクトとして素敵なパッケージに変更を適用できます。
真のエンド ツー エンドのよく考えられたアプローチが必要な場合は (多少の学習曲線があります)、Innovartis の DBGhostアプローチをチェックしてください。これは、データベースの開発と増分更新を処理する方法論/手法全体です。それは非常に強力で、非常に有望に見えます - しかし、それはちょっとオール・オア・ナッシングのアプローチです: それを受け入れてエンドツーエンドで使用するか、使用しないか
これが少し役立つことを願っています！
redgate には、データベースを比較し、同期するスクリプトを生成するSQL Compareツールがあります。以前は使用していましたが、最近、説明したのと同じプロセスを使用して手動スクリプトに切り替えました。一意のバージョン番号を持つ手動のきめの細かいスクリプトを使用すると、うまくいきました。
アップグレード スクリプトは単体テストに統合されているため、継続的インテグレーションの一環としてコードと共にテストされます。これは「ワンステップでビルドを作る」ための重要な部分だと思います。
このブログ記事を見てください。いくつかのプロジェクトで任意の DB バージョンからこのタイプの単一更新スクリプトを使用しましたが、非常にうまく機能します。
http://blogs.msdn.com/danhardan/archive/2007/03/30/database-change-scripts-mambo-style.aspx
ワークフローに合わせてワークフローを少し調整したり、テンプレートの .sql ファイルを更新したりする必要があるかもしれませんが、全体として、このアイデアは DB 展開へのかなり堅実なアプローチであることがわかりました。
編集：この手法をどのように使用したかについて詳しく説明します。基本的に、私の DB リビジョン スクリプトはすべてソース管理に入れられます。次に、ビルド ボックスのビルド後のステップとして、この Mambo ツールがスクリプト ディレクトリで実行され、スクリプトがトランザクションに含まれる単一のスクリプトにロールバックされ、何か問題が発生した場合にロールバックできるようになります。次に、インストーラーは十分に賢く、既存のデータベースに対して実行する .sql スクリプトを探します。
これが機能する理由は、ロールアップされたスクリプトが、個々のスクリプトであった各部分が目的のデータベースに対して既に実行されていることを確認するためです。その結果、最新のスクリプトのみが実行されます。これに対する注意点は、スクリプトがソース管理にチェックインされて展開されると、追跡テーブルはスクリプトが実行されたと既に認識しているため、スクリプトを編集できないことです。これまで取り組んできたプロジェクトでは問題ありません。スクリプト フォルダーに別のスクリプトを追加するだけだからです。
うまくいけば、私はプロセスを理解するのに十分なほどよく説明しています. 実際にはそれほど複雑ではなく、アプローチがプロジェクトに適用できる場合は非常に便利です。
最初の質問に対する回答「これは展開ビルド (顧客が展開を更新できるようにするため) を意味するのでしょうか?」
Joel Test #2 は、本番環境への展開ではなく、開発中の継続的な統合のためのものだと思います。
本番環境でのデータベースの変更に関しては、トランザクションのロールアウトの一部として、またはデータベースのバックアップ後にスクリプトを使用してすべてを行う必要があります。ロールアウトで何かが失敗した場合に、常に戻ることができるようにしたいと考えています。
相互に依存する一連のパッチとしてデータベースを開発します。次に、 https://github.com/LuvDaSun/sqlpatch (by me)のようなツールを使用して、デプロイ用の sql ファイルを作成します。
sqlpatch は、パッチを正しい順序で並べ替え、同じスクリプトが 2 回実行されたとしても、すべてのパッチが 1 回だけ実行されるようにします。
この戦略は、ci/cd 環境でのデータベースの展開に使用できます。これにより、展開がブランチへのプッシュと同じくらい簡単になります。
Microsoft 自身は、SQL 2012 でデータ層アプリケーションを、データベースの展開とアップグレードのための無料オプションとして導入しました。
私はこのツールを使用しており、本番環境への展開も含めて気に入っています。
データベースを同期するアプリケーションもありますが、自分がしていることをやったほうがいいと思います。データベースを更新するスクリプトを作成すると、エラーを処理してトランザクションを実行することができます。これはベストプラクティスと見なされます。