私の例で、招待なしに私の古い作品の1つでグループの前に突然現れた予期せぬ問題について、そして状況の迅速かつ効果的な解決のために、私たちが欠けていたものについて話したいと思います-一般的に、また否定的な経験-突然誰かが現在または将来便利になります。 私たちの会社では、このような問題の解決に「データベースの変更管理」という用語の下でより広くアプローチしているという事実にもかかわらず、私は上記の記事の用語分野に留まるようにします。
過去の経験-未解決の問題について
1997年に、私が入社した開発チームは、3か月以内に自動化技術を実装するソフトウェアパッケージを作成することを任されました。これは会社全体のビジネス活動の基盤を形成することでした。 それは長年の出来事であり、あなたの許可があれば、技術やビジネスプロセスの詳細や詳細には立ち入りません。 2つの独立した外部ソースから大量に提供される毎日受信したデータを処理および相互接続して、それらをリポジトリに蓄積し、顧客からの任意の要求に回答するための遅延を最小限に抑えることが重要であることが重要です-社内のマネージャーは、に基づいて多くの指標を予測します蓄積された情報量の遡及的分析。 このタスクは完了し、典型的な内部企業システムが作成されました。それは、それ以来現在まで機能しており、この期間全体を通して正常に変更およびファイナライズされています。
問題の最初の兆候は、IT部門の管理者がこのシステムのコピーを顧客のいずれかのデータセンターに転送するように命じたときに現れました。 同時に、通常の締め切りは「昨日」でした。 情報のソースは私たちのものと同じであったため、同じサプライヤーからのデータフローをあまり変更する必要はなく、ETLはほぼ同じままで、リクエストのリストは絞り込まれ、レポートセットはわずかに変更され、制限されていました。 それにもかかわらず、これらすべてが機能するはずの技術的基盤はすでに異なっていました。Oracleの代わりに、MS SQL Server DBMSがありました。 ただし、データ型が複雑な変換を必要としない場合でも、データベース構造自体は変更されていません。
現在、私たちのサポートでは、設計と機能に2つの類似点がありますが、システムの実装バージョンは異なります。 すぐに童話が影響します。しばらくして、全国の支部で働くための約30以上の同一のシステムのサポートを受けました。 新しいバージョンの展開は、センターから新しいバージョンをコピーすることにより実行されました。 バージョン管理された移行の観点から、これは1つの標準バージョンであり、すべてのサーバーの構成パラメーターも同じである必要があり、ローカル管理者は奨励されるだけでなく禁止され、この禁止の違反は毎日監視する必要があります。 また、ディレクトリのステータスと内容（ブランチデータベースから中央のデータベースへの情報の「情報」の基礎）を制御する必要があり、すべてのローカルデータベースで同じ内容を保証する必要がありました。
多くの人がすでに推測しているように、最後の段階は、会社の海外支店の業務を確保するための別の4〜5個のオプションの出現でした。 さらに、各国にはソースデータのサプライヤがあり、一部のデータ要素は十分ではありません。必要な情報の一部は提供されたセットに「ばらまかれ」、一部の指標は他のルールに従って計算されます。 つまり、各オプションはETL部分で根本的に異なり、これはアプリケーションと手順だけでなく、いわゆるデータ構造にも当てはまります。 ステージデータベース（メインと干渉せずにETL変換を実行するための作業データベース）。
このように、純粋な社内使用のためのシステムを開発した後、少しの間、よく考えられた将来の計画なしに、私たちはエキゾチックなバージョンの大きな動物園の飼育係として働いていることがわかりました。 そして、私たちだけではないと思います。
この話がどれほど一般的で簡潔であっても、データベースの移行に関連するいくつかの特徴的な機能をそこから抽出できます。
- 多数の異なるバージョンのアプリケーションの同時サポートは、開発者やユーザーの希望に依存しない客観的な現実です
- データベースを別のサーバーまたはDBMSプラットフォームに転送するときだけでなく、データベースを利用可能なバージョン（バージョン、世代）のアプリケーションソフトウェアと同期するときにも移行が必要です。
- バージョンの違いは、処理ロジックとデータベース構造の違いだけでなく、さまざまなDBMSプラットフォーム、および既存のハードウェアの特別な設定の違いとも関連しています。
- 移行プロセスの管理だけでなく、スキーム、データおよび設定の不変性の制御、変更された要素の構成に関する監査（レポート）、誰によって、どの値によっても制御が必要です。
- 移行中のデータベース構造の変更には、多くの場合、保存された共有データの追加の処理/変換が必要です
おそらく、タスクは徐々に「積み上げられる」ため、私たちにとっては簡単でした。 また、チームは安定しており、各従業員の機能は、活動の垂直領域と特定のタスクの両方で明確に分散されていました。 それにも関わらず、アプリケーションソフトウェアに変更が加えられるたびに、計画的または自発的に同じように、すべての人をアプリケーションの新しいバージョンに移行する必要がありました。 また、作業データベースのバージョンは、この更新されたバージョンに対応している必要があります。スキーム、データ、設定のバージョン付き移行を実行する必要があります。
ある程度、適切なソリューションが存在し、非常に一般的です。 最も便利で時間のかからない方法に到達することが重要です。 ネガティブな体験についてお話します。なぜなら、今は別のテクノロジーを選択していたからです。そのときの不在を本当に後悔しています。
すべてのサーバーを変更するための統一されたスクリプトを用意し、各サーバーで自動的に実行する方が簡単だと思われます。
最初の問題は、異なる場所で切り替えなければならないアプリケーションのバージョンが異なることでした！ 単一の修正スクリプトが存在することはできませんでした。現在の状態を調査し、各サーバーのスクリプトを個別に作成およびテストするのに多くの時間を費やす必要がありました。 最初にテストスタンドを作成する必要があるため、テストは別の問題です。
古いバージョンのアプリケーションの存在中に別のサーバーで行われた変更のログのサポートは、そのような変更がいくつかある場合、同期スクリプトを厳密に「正しい」シーケンスで実行する必要があり、場合によっては1つのスクリプトを再実行するため、絶対に受け入れられない-結果はすでに不可逆的です。
今、あなたの時間に異なるサーバーの数を掛けてください！
逆の問題：ローカル管理者は、データベースを自分で「改善」することを決定しました。たとえば、ディスク容量の不足により、大きなインデックスを「破壊」し、データベースファイルを別のメディアに転送した後に復元することを「忘れました」。 このような設定や構造の変更は非常に簡単に検出できますが、データベースの特定のバージョンを元の状態にしておく必要があるため、比較対象があります。 また、回線の変更を十分に迅速に検出して修正することができた場合、サーバー構成パラメーターまたは実際のデータの変更は、多大な労力で、より長い期間にわたって検出されました。 そして、修正スクリプトとその実行を作成する技術全体を実行します。 同時に、誰が、いつ、これらの変更を行ったかを調査します。
さまざまなプログラミング言語のすべての通常のソース管理システムと同様に、ソースとしてデータベースの構造へのアプローチを自動的にサポートする利用可能なツールがあれば、次のタスクははるかに簡単になります。
- データベースを特定のバージョンから別のバージョンに、1つのステップで、より新しいバージョンに更新して、前のバージョンに戻す。
- 自動モードで移行スクリプトを受け取りやすく、最後の手段として「手動で」修正を行うことができます。
- アプリケーションの既存のバージョンに対応する新しいデータベースインスタンスのゼロからの作成。
- 実際の作業データベースに基づいてテスト/開発データベースインスタンスを簡単に作成し、これらのワーカーに最も近い開発を実行します。
- データベースコピーの不要な変更の監視と監査。必要に応じて、短時間で参照状態に自動的に戻ります。
これは、記述されているストーリーにそれほど欠けていたものです。 このアプローチは、インストルメンタルソリューションを使用せずに使用するのはあまり効果的ではありませんが、独自の本格的なユーティリティを開発するのに十分な時間やリソースがありませんでした。 IT部門の管理方針も干渉しました。 ただし、今日では、このアプローチを実装する完成品もあり、それぞれが独自の機能セットを備えています。 私は次の出版物で可能な解決策の一つについて話すつもりです
データベースの変更を保存および管理するには、さまざまな方法とソリューションがあります。 最も受け入れられるアプローチを見つけ、バージョン管理されたデータベース移行の自動化の度合いを高め、作業の品質と信頼性を高め、従業員のリソースと時間を節約するのに役立つツールを適用することが重要です。 この記事では、データベースの変更を管理する問題がどこから来るのか、これがどのような困難を伴うのか、そしてこれに基づいてどのような結論に至ったのか、全体として否定的な経験を実例を挙げて説明しました。