ORMツールを使用せずにデータベースに依存するバックエンドのリポジトリ管理
ほとんどの場合、データベースを使用してバックエンドプロジェクトを設定するときは、ORMツールを使用してデータベースを扱います。したがって、データベーススキーマと移行はバックエンドコードに結合されており、バックエンドリポジトリ内に保持できます。
現在、1つのデータベースタイプのみに依存する複数のプロジェクトを作成しています。プレーンSQLを使用する必要があります。
追加の「データベースプロジェクト」を処理するためのベストプラクティスについて知りたいのですが。意味データベース-バックエンド-フロントエンド。データベーススキームを独自のリポジトリに配置する必要がありますか？次に、MigrationFrom1To2のようなSQLスクリプトをこのリポジトリに配置することもできます。
私の頭に浮かぶ問題は、データベースとバックエンドプロジェクトで多くの開発者と一緒に作業しているときに、両方のプロジェクトを同期させる方法を教えてください。まだ存在しない新しいデータベーステーブルを想定しているバックエンドコードのプルリクエストがあるとしましょう。次に、データベースリポジトリがその機能も実装するのを待つ必要があります（他のリポジトリの問題につながるリンクを追加します）。そうすることで、すべてのバックエンド開発者は最新のデータベース移行スクリプトをプルして自分のローカルデータベースを更新する必要があるため、バックエンドで作業する前に新しいデータベースの移行を確認する必要があります。
現在、私はORMでプロジェクトを管理する方法を知っていますが、誰かがプレーンSQLでプロジェクトを管理する方法を説明できればいいです（1つのデータベースで問題ありません）。それが役立つ場合は、MariaDbと.NET Coreを使用しています。特に、自動ビルドとDocker（Githubアクションなどを使用）に関しては。
複数のプロジェクトで私達はあなたと同じ状況にありました、そしてここに私達がそれを解決した方法があります。
状況
単一のデータベースが複数の関連するものに使用されました。請負業者は、データベースに依存するアプリケーションのサブセットに取り組んでいました。従業員は、同じデータベース上のアプリケーションの別のサブセットで作業していました。 DBAは移行を担当していました。
リポジトリ
アプリケーション開発用とデータベース用の2つのリポジトリがありました。契約と従業員がアプリリポジトリにコードを記述していました。 DBリポジトリでDBの変更が発生していました。 DBAはdbリポジトリから移行していました。アプリ変更管理チームがアプリリポジトリからコードをデプロイしていました。 DBAとアプリ変更管理チームは、適切な方法で適切なものを展開するために十分に調整されました。
分岐戦略
請負業者は、アプリとデータベースリポジトリに機能ブランチ（例：ユーザー設定）を作成しました。 DBへの変更は、dbリポジトリで行われます。アプリへの変更はアプリリポジトリに反映されます。 dbの変更に依存する十分なコードが記述されるとすぐに、リリースにフラグを付けてプッシュアウトします。変更管理とDBAは、両方のリポジトリのユーザー設定ブランチのプルリクエストを一緒に確認して、正しくデプロイされ、ブランチをマスターにマージして、リリースプロセスを実行できることを確認しました。ポストプロダクションの問題がないことを確認するために、制御された環境で機能フラグをオン/オフにしました。チームメンバーは、日中に複数回合併しました。この方法はうまくいきました。お気づきかもしれませんが、CI/CDは完全に自動化されていませんでした。チームはDBに加えた変更について互いに話し合ったので、誰もが何を期待すべきかを知っていました。
トランクベースの開発
別の状況では、アプリとデータベースのリポジトリにローカルブランチを作成することにしました。コードとdbの変更をテストし、できるだけ早くクリーンにマージします。 DBAと変更管理チームは、QA、実稼働前のチェックなどを経て、実稼働環境に毎日配備されました。驚くべきことに、競合はそれほど多くなく、簡単に解決できました。開発者が理論をテストしたらすぐに、データベースの変更を作成してマスターにプッシュすることを強調しました。 DBの変更はコードよりも進んでいます。
機能フラグと同様に、開発者はユーザーの操作を許可する前に、dbの依存関係を確認しました。どういうわけか、依存するコードのdb変更が見つからなかった場合、優雅なメッセージが表示され、変更管理に依存関係を確認するためのメールが送信されます。繰り返しになりますが、驚くべきことに、物事は非常にうまくいきました。
より複雑な例
規制された会社には複数の契約チームがあり、アジャイルを行ったり、ウォーターフォールを行ったり、独自の巧妙な開発方法論を使用したりしました。会社のスタッフには複数のチームがあり、請負業者と同じような違いがありました。機能を作成したり、問題を修正したりするために、全員が協力しなければなりませんでした。無秩序に聞こえますか？彼らは毎日のCABミーティングを作成しました-CABはChange Approval Boardの略です。各チームは5分を費やして、CABが本番環境にプッシュしようとしているものとその依存関係を教育します。異なるリポジトリとバージョン管理システムがありました。
非常に小さな変更を加えて、本番環境にプッシュすることができました。大きな変更は、素晴らしいファンファーレを伴う巨大なバッチになります。変更管理チームは、さまざまなリポジトリ/バージョン管理システムからコードを収集し、それをシミュレーション（シミュレーション）環境（最初にdb、次にアプリの変更）で再生してから、本番環境で計画しました。大規模な変更は、毎晩小さな変更で更新された長期的なブランチにありました。大規模な変更が行われる月は、小さな変更が数日間一時停止しました。大きな変更は消え、その後小さな変更が再開されます。率直に言って、それは完璧に近いものではありませんでしたが、2人のFTEがタカのように配備を見ている限り、うまくいきました。
両社の共通点は、アプリ開発者がフラグを立てて機能し、飛行前チェックリストを実行して、機能が正常に実行されるためにすべての依存関係が整っていることを確認したことです。このようにして、何かが見落とされた場合、エラーがログに記録され、ユーザーは何をすべきか/誰を呼び出すべきかを優雅に知らされました。
同じデータベースに接続する多くのアプリケーションは一般に悪い考えであり、これが人々がマイクロサービスに目を向けている主な理由の1つです。そのため、データが分離され、1つのサービスが別のサービスのデータベースに関連付けられていません。
多くの多くのプロジェクトを処理する1つの大きなソリューションがある場合、使用することをお勧めします
DbUpは、SQL Serverデータベースへの変更を展開するのに役立つ.NETライブラリです。既に実行されているSQLスクリプトを追跡し、データベースを最新の状態にするために必要な変更スクリプトを実行します。
これはORMではなく、純粋なSQLを使用します。コード内にSQLスクリプトのリストを作成します。これもソース管理の一部であり、アプリケーションを起動するたびに、すべての移行が適用されているかどうかをチェックし、適用されていない場合は最後の変更を適用します。
移行チェックとデータベース更新を自動化できます
- As CI/CDパイプラインの一部 。
- アプリケーションが毎回起動するときに実行されるアプリケーションの起動タスクとして。スタートアップタスクを設定する方法の例は、 Andrew Lock's ブログにあります。