小規模なWebチームのローカルデータベース開発プロセスを設定する方法

バックグラウンド

私は、約4人のプログラマーと4人のデザイナーから成る小規模なWebチーム向けに新しい開発プロセスの作成に取り組んでいます。将来的にチームを成長させる可能性があることは明らかです。当社の製品は、当社が設計およびホストするクライアントWebサイトを強化する中央アプリケーションです。

以前は、1つの開発データベースを使用して、開発サーバーでFTPを介して作業していました。それは「働いた」^*私たちのプロセスを成熟する時間ですので、しばらくの間、私たちは新たな方向に動いています。

Percona Server 5.5を使用していますが、これはデータベースにとらわれず、コストを低く抑えることを考えたものでなければなりません。

目標：

私は、以下を念頭に置いて、データベース開発のための継続的インテグレーション（CI）プロセスの作成を検討しています。

1. 開発者には、開発コードを実行するためのデータのローカルコピーがあります
2. データベース構造を以前の変更セットにロールバックできる
3. 新機能スキーマの変更とスキーマ設計修正の変更を区別できる
4. テストのためにデータベース構造をローカルで変更可能

初期コンセプト

SVNとLiquiBaseを使用して以下のプロセスをスケッチしましたが、完全に削除され#4ます。

• トランクから「開発」ブランチを作成する
• 中央の「開発」データベースサーバーは「開発」ブランチから実行されます
• ローカル開発者は、開発ブランチのスレーブとしてセットアップされます（#1上記を提供）
• LiquiBaseをチェンジは（この開発サーバーへのスレーブとして動作しているローカルマシンにトリクルダウンします）中央開発用データベースを更新するために、ポストcommitフックを実行する開発ブランチに定期的にコミットしている（LiquiBaseをが提供する#2上で）
• 機能またはスキーマの修正がQAに進む準備ができたら、DBA（me）は開発ブランチからトランクに適切な変更をマージします。この行為は、ステージングデータベースサーバーに適用するSQLスクリプトを作成します。
• ステージングサーバーはTRUNKを反映する必要があります。TRUNKは、本番と同じ構造に加えて、QAにある変更を含む必要があります
• ステージングサーバーでsqlスクリプトを実行した後、変更に対していくつかのQAを実行します。
• すべてが正常に見える場合は、構造にタグを付けます。これにより、DBAによって本番環境で手動で実行される.sqlスクリプトが生成されます（必要に応じてオフピーク時間）。

このプロセスでは、すべての開発者が同じ「開発」ブランチから実行する必要があります。つまり、データベーススキーマのバージョンは常に1つだけです（これが必要かどうかはわかりません）。

また、スキーマへの変更はローカルでテストできず、正しく行わないと他の開発者に影響を与える可能性があります。この環境では、開発者は新しいテーブルを追加するかもしれませんが、既存の構造を変更することはめったにありません。DBAとして、設計修正は私によって行われます。しかし、修正をローカルでテストできないことは、プロセスの最大の問題です。

上記のプロセスを微調整して、ローカル開発を可能にしながら、データの比較的最新のコピーを維持するにはどうすればよいですか（提案されたプロセスの複製によって提供されます）。先週までデータを最新にする必要はありません。

環境を管理する

単一のデータベースバージョンに強制されることは絶対に望まないでしょう。必然的に複数の開発作業ストリームがあり、開発作業ストリームとは無関係に現在の実稼働環境にパッチを適用するための要件を持つ十分な開発者がいます。

Liquibaseまたは手動プロセスを使用して、バージョンをアップグレードするパッチスクリプトを作成できます。手動プロセスから始めて、パッチのQAにスキーマ比較ツールを使用することをお勧めします。自明ではない複雑なデータベースのクリーンで自動化された透過的な同期は、少しユートピア的です。

中央のデータモデルは、どんなシステムでも好きなように保管できます。退屈なエンタープライズリポジトリツールのすべてを使用して、テーブルスクリプトを作成しました。テーブル作成スクリプトは、Subversionなどの通常のソース管理ツールでうまく機能します。すべてのリポジトリツールがバージョン管理に適しているわけではありません。

マスターデータモデルリポジトリとして使用するものは何でも、そのモデルから環境を展開するためのかなりクリーンなメカニズムが必要です。環境への展開が容易になるように構成する必要があります。また、リリースされたバージョンから次のバージョンにパッチを適用するメカニズムも必要です。

私がやったこと

過去に開発環境を管理していたときに、次のことを行いました。特にハイテクではありませんが、バージョン管理と自動ビルドに対応しているため、環境を特定のバージョンに簡単に展開でき、多数の環境を維持することは非常に実用的です。

中央リポジトリの維持：これは、バージョン管理システムに保持されているデータベース作成スクリプトのセット、またはデータモデリングツールのリポジトリモデルである可能性があります。好きなのを選びな。このモデルには、多くの手動介入なしでスクリプトから環境を展開できるビルドメカニズムが必要です。

参照データがたくさんある場合は、そのためのロードメカニズムが必要になります。実行方法に応じて、データベースまたは一連のファイルに保存できます。ファイルの利点は、コードベースと同じバージョン管理システムからバージョン管理およびラベル付けできることです。ソース管理リポジトリ内の多数のCSVファイルとバルクローダースクリプトで、これを簡単に実行できます。

開発環境を展開するための1つのオプションは、適切なバージョンにパッチを適用した本番データベースのバックアップを取り、開発者が開発環境に復元できるようにすることです。

簡単に展開できるようにする：他のCIビルドプロセスと同様に、データベースは単一のスクリプトから展開可能でなければなりません。データベース接続をパラメータ化できるように設定するか、スクリプトが場所に依存せず、接続を介して実行されるようにします。

パッチスクリプト：各リリースバージョンのスクリプトをロールフォワードし、おそらくロールバックする必要があります。

リポジトリモデルからテスト環境を構築します。これにより、リポジトリと同期していない環境での開発がテストで確実に捕捉されます。

展開プロセスのテスト：自動化されたパッチスクリプト。ただし、作成されたスクリプトはテスト可能である必要があります。スキーマ比較ツールは、パッチスクリプトの生成に使用しなくても、これに非常に適しています。

• テストしたリポジトリモデルビルドを使用して参照環境を作成する

• 本番リリースのバックアップまたは現在のリリースバージョンに基づくビルドのいずれかを使用して、スモークテスト環境を作成します。

• スモークテスト環境に対してパッチスクリプトを実行します。

• スキーマ比較ツールを使用して、スモークテスト環境と参照環境を比較します。パッチスクリプトにより、2つのデータベースが同一になるはずなので、違いを調査できます。

このプロセスの好きなところ

これは少し重く、かなり官僚的で不透明な運用環境に展開するために設計されました。ただし、次の長所があります。

• 開発者は必要な場所をいじることができます。

• 開発の複数のブランチとストリームに対応できます。

• 展開スクリプト自体は、反復可能な方法でテストできます。これは、再現性を示すことができるため、展開バンフをシャットダウンするのに非常に役立ちます。

• スキーマ比較ツールは、展開自体のQAを提供します。

• テストは常にリリースされる予定のものに対して行われ、これにより、同期がとれていない環境から生じる問題をキャッチします。

• リポジトリモデルとパッチスクリプトに基づく展開により、制御されていないゴミが開発環境から本番環境に誤って移行されることはありません。

• 多くのプロセスは自動化できますが、デプロイメントパッチスクリプトを手動で準備およびテストすることが望ましい場合があります。

• 環境は安価であり、簡単に導入でき、簡単に導入できます。

• 開発者は、単純なビルドおよび展開プロセスに適したシステムを作成する必要があります。

• 開発者は基本的なデータベース管理タスクを習得する必要がありますが、テスト環境と運用環境はnoobの間違いから隔離されています。

要件への対処方法

1. 開発者は、開発コードを実行するためのデータのローカルコピーを持っています
   
   。展開スクリプトまたはDBイメージは、利用可能な任意のバージョンから環境をセットアップできることを意味します。

2. データベース構造を以前の変更セットに
   
   再度ロールバックでき、デプロイメントスクリプトでソートされます。DDLを使用するか、制御されたプロセスで作成されたデータベースバックアップイメージをテストすることにより、開発者は環境を特定のバージョンにアップグレードできます。

3. 新機能のスキーマの変更とスキーマ設計の修正の変更を
   
   区別できる共通バージョンへのパッチは、svnツリーの別のフォークで維持できます。データベースのバックアップを参照環境として使用する場合、ソース管理プロジェクトの分岐と同じフォルダー構造でどこかに保存する必要があります。

4. テスト
   
   のためにデータベース構造をローカルで変更できるシンプルな展開プロセスにより、開発者は環境をローカル状態に簡単に復元したり、比較を行ったり変更セットを作成したりするための参照環境を立ち上げることができます。