複数の環境でデプロイメント(特にデータベースオブジェクトの変更)を同期する方法[複製]


7

私はDevOpsエンジニアであり、数か月前のチームのソフトウェアエンジニアです。開発者は、中央のOracle DBから、個々のラップトップのCentOS VMにDBを持つことに移行しました。中央DBからの移行は、DBAへの依存を減らし、データの不整合に起因する問題を排除することでした。

チームの全員とデータベースの共有と同期を確実にする計画は、各人が全員と変更スクリプトを共有することでした。問題は、Skypeを使用して通信を行うことです(スラックをセットアップするだけですが、まだ完全には使い始めていません)。DB変更スクリプトのテキストが投稿されることもありますが、見落とされる場合があります。もう1つの問題は、一部の開発者が変更の投稿を見逃していることです。さらに、新しいリリースは本番環境にデプロイされ、テストおよびデモ環境にはデプロイされません。

これは私たち、特に最近の私にとって深刻な課題となっており、デモの展開とプロダクションの展開を確実に同期させる責任がありました。同期に関する問題のほとんどは、変更スクリプトがないか、DBオブジェクトがないために、データベースが同期されていないことにあります。Oracleは私たちの好みのDBです。

デモ環境での一般的な展開は、アプリケーションのテストを含む非常に痛みを伴うプロセスであり、DBテーブルの列、関数、ストアドプロシージャの欠落が原因で問題が発生するため、欠落しているDBオブジェクトを探し、それらをDBに適用してから、すべての問題が解決されるまで続行します。

この問題を解決して、スムーズで痛みのない、時間のかからない展開を確実にするにはどうすればよいですか?アプリケーションをDockerに移行すると、DB同期の問題と、それに伴う開発者の規律の欠如を解決できますか?この分野で改善するためにどのようなプロセスを導入できるでしょうか?

回答:


9

スキーマ管理をアプリケーション自体に(またはそれと共に)統合します。

スキーマへの変更は、アプリケーションコードに沿ってコミットする必要があります(したがって、タグも付けられます)。

この質問には、すでにいくつかの可能性がリストされています:データベースの継続的な展開を可能にするプラクティスまたはツール

この種のツールを使用すると、h2や中央データベースなどのメモリ内データベースを使用し、起動時にアプリケーションにスキーマバージョン(DBに格納されている)を確認させると、アプリケーションの起動時に更新されたデータベーススキーマを取得できます。

これは、規律の問題を解決せず、新しいスキーマを作成する可能性があります。これには通常、スキーマの厳密なバージョン管理が付属しているため、バージョンを強制的にpre-commitフックで実行できますが、それは大変な作業です。


4

弊社では、VCS(Git)内でアプリケーションコードを管理し、使用するほとんどのアプリケーションは、アプリケーションに付属するセットアップスクリプト内からコアデータベースをインストールします。

データベースの拡張やデータベースのカスタマイズを行う必要がある顧客向けにアプリケーションを拡張またはカスタマイズする必要がある場合は、アプリケーションのデータベースレイヤー/ラッパーを通じてデータベース操作を実行するセットアップスクリプトをコードに添付します。 /運転者。

このようにして、コードがVCSリポジトリにマージされると、このコードをチェックアウトするすべての開発者がこれらのデータベースの変更を取得します。また、コードがマージされた後、これらのデータベースの変更はすべての環境(テスト、UAT、および運用ノード)で終了し、すべてのデータベースの変更がスムーズにロールアウトされます。

これは実装が簡単な方法です。さらに高度な管理の可能性が必要な場合は、データベースに固有のソース管理ツールに飛び込むこともできます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.