9

私が取り組んでいるプロジェクトは、データベースとコードをアジャイルにし、一緒に構築してデプロイできるようにするためのソリューションを考え出そうとしていました。

アプリケーションはコードとデータベーススキーマ、およびデータベースコードテーブルの組み合わせであるため、コードと一緒にバージョン管理されたデータベースがない限り、アプリケーションの完全なビルドを実際に行うことはできません。

アジャイル/スクラム環境でコードと一緒にデータベース開発を行うための優れたアジャイル手法をまだ思い付くことができていません。

これが私の要件のいくつかです：

  1. システムの完全なビルドに対応するsvnリビジョン＃を使用できるようにしたい。
  2. データベースのソース管理にバイナリファイルをチェックインしたくありません。
  3. 開発者は、コードを継続的インテグレーションサーバーにコミットし、システム全体とデータベースを一緒に構築できる必要があります。
  4. ビルドサーバーで元のビルド以外の再構築を行わずに、さまざまな環境への展開を自動化できる必要があります。

（更新）もう少し説明するために、ここにいくつかの情報を追加します。

膨大な量のコードを含むレガシープロジェクトであるため、OR/Mツールはありません。アジャイルデータベースの設計情報を読みましたが、そのプロセスは単独で機能しているようですが、アクティブなコード開発と組み合わせることについて話しています。

これが2つのシナリオです

  1. 開発者は、データベースの変更を必要とするコード変更をチェックインします。自動ビルドが失敗しないように、開発者はデータベースの変更を同時にチェックインできる必要があります。

  2. 開発者はDBの変更をチェックインします。これにより、コードが破損するはずです。自動ビルドを実行して失敗する必要があります。

最大の問題は、これらのものがどのように同期するかです。「データベースの変更をチェックインする」などのことはありません。現在、DB変更の適用は、コード変更が絶えず行われている間、誰かがしなければならない手動プロセスです。それらは一緒に作成され、一緒にチェックされる必要があります。ビルドシステムはシステム全体をビルドできる必要があります。

（更新2）ここにもう1つ追加します：

本番環境を停止することはできません。パッチを適用する必要があります。本番データベース全体を再構築することは受け入れられません。

4

5 に答える 5

3

データベーススキーマを構築し、必要なブートストラップデータを追加するビルドプロセスが必要です。スキーマ生成をサポートするO/Rツールを使用している場合、その作業のほとんどは自動的に行われます。ツールで生成されないものは何でも、スクリプトに保持します。

継続的インテグレーションの場合、理想的には、「ビルド」にはデータベースの完全な再構築と静的テストデータのリロードが含まれる必要があります。

ORMツールがないのを見たばかりです...これが私が以前働いていた会社で持っていたものです

db/
db/Makefile (run `make` to rebuild db from scratch, `make clean` to close db)
db/01_type.sql
db/02_table.sql
db/03_function.sql
db/04_view.sql
db/05_index.sql
db/06_data.sql

必要に応じて配置します...*.sql構造を生成するために、これらの各スクリプトが実行されます。開発者はそれぞれDBのローカルコピーを持っており、DBの変更は単なる別のコード変更であり、特別なことではありません。

ビルドプロセス（Java、C、C ++）がすでにあるプロジェクトで作業している場合、これは第二の性質です。ビルドプロセスがまったくないような方法でスクリプトを使用している場合、これは少し余分な作業になります。

于 2008-12-12T23:07:29.003 に答える
2

「「データベースの変更をチェックインする」などというものはありません。」

実際、データベースの変更をチェックインできると思います。秘訣は、単純な (バージョン管理されていない) スキーマとテーブル名の使用をやめることです。

スキーマ全体 (またはテーブル) にバージョン番号が添付されている場合は、簡単にバージョンをチェックインできます。

データベースのバージョンには派手なメジャー マイナー リリースがないことに注意してください。アプリケーション ソフトウェアの「メジャー」リビジョンは、通常、互換性の基本的なレベルを反映しています。その基本レベルの互換性は、「同じデータ モデルを使用する」と定義する必要があります。

そのため、アプリ バージョン 2.23 と 2.24 はバージョン 2 のデータベース スキーマを使用します。

バージョン チェックインには 2 つの部分があります。

  1. 新しいテーブル。たとえば、MyTable_8 は特定のテーブルのバージョン 8 です。

  2. 移行スクリプト。たとえば、MyTable_8 には MyTable_7 から MyTable_8 へのスクリプトが含まれており、データを移動し、デフォルトまたは必要なものを提供します。

これにはいくつかの使用方法があります。

  • 互換性のあるアップグレード。null を許可する列を追加するためにテーブルを変更するだけの場合、バージョン番号は変わりません。

  • 互換性のないアップグレード。null 以外の列 (初期値が必要) を追加したり、テーブルの基本的な形状や列のデータ型を変更したりすると、大きな変更が行われ、移行スクリプトが作成されます。

古いデータは、変更手順の最後に明示的に削除されるまでそのままであることに注意してください。テストを実行して、すべてが機能していることを確認する必要があります。

最初に名前を変更し、次に (1 週間後に) 最後にドロップします。

于 2008-12-15T01:44:31.647 に答える
1

O / Rマッピングツールが、デフォルトの構成から必要なテーブルを構築し、不足している列を追加できることを確認してください。これはあなたのケースの90％をカバーするはずです。

他の10％は

  • データが挿入された後に追加された列の欠落値への対処
  • バージョン間でより根本的な変更を行う必要があるまれなケースのために、データ移行スクリプトを作成します
于 2008-12-12T23:00:50.560 に答える
1

DBDeploy オープン ソース プロジェクトを参照してください。http://dbdeploy.com/

データベース変更スクリプトをチェックインできます。その後、適用されていないすべての変更を含む統合された変更スクリプトが生成されます。サイトはプロセスをかなりよく説明しています。

このプロジェクトは、前述の Martin Fowler の記事の手法に基づいています。私は、Martin が記事の基にしたプロジェクトに参加していました。DbDeploy は、私たちが使用したプロセスの非常に優れた実装です。

于 2008-12-15T02:08:40.787 に答える
1

Ruby on Railsの移行機能は、まさにこのニーズに対応するために開発されました。アプリケーションに Rails を使用していない場合は、これと同じ概念が選択したフレームワークに移植されているかどうかを確認するか、それを読んで、同じ種類の機能を実装する簡単なスクリプトを作成できるかどうかを判断することができます。

于 2009-11-18T21:56:33.380 に答える