データベースを使用して新しい機能を開発する場合、開発サイクルには通常、次の段階が含まれます（ただし、これらに限定されません）

。SQL移行の記述→コードの記述→テスト→リリース→監視。

この記事では、品質を低下させるのではなく、向上させると同時に、各段階でこのサイクルの時間を短縮する方法について、いくつかの実用的なアドバイスを共有したいと思います。

会社でPostgreSQLを使用し、Javaでサーバーコードを記述しているため、例はこのスタックに基づいていますが、ほとんどのアイデアは使用するデータベースやプログラミング言語に依存していません。

SQLの移行

設計後の開発の最初の段階は、SQL移行の記述です。主なアドバイス-データスキーマに手動で変更を加えることはありませんが、常にスクリプトを介して行い、それらを1か所に保存します。

当社では、開発者がSQL移行を自分で作成するため、すべての移行はメインコードとともにリポジトリに保存されます。一部の企業では、データベース管理者がスキーマの変更に関与しています。その場合、移行レジストリはどこかにあります。いずれにせよ、このアプローチには次の利点があります。

新しいベースを最初から簡単に作成したり、既存のベースを現在のバージョンにアップグレードしたりできます。これにより、新しいテスト環境とローカル開発環境をすばやく展開できます。
すべての拠点のレイアウトは同じです。サービスに驚きはありません。
すべての変更（バージョン管理）の履歴があります。

、両方の商業および無料のこのプロセスを自動化するための多くの既製のツールがあります：フライウェイ、LiquiBaseを、sqitch私が比較して、最高のツールを選択しないであろう。この記事ではなどは、 -これは、別の大きなテーマである、そしてあなたはそれに多くの記事を見つけることができます..。

私たちはフライウェイを使用しているので、ここにそれについての少しの情報があります：

移行には、sqlベースとjavaベースの2種類があります。
SQLの移行は不変（不変）です。最初の実行後、SQL移行は変更できません。Flywayは、移行ファイルの内容のチェックサムを計算し、実行するたびにそれを検証します。Javaの移行を不変にするには、追加の手動操作が必要です。
flyway_schema_history ( schema_version). , , , .

内部契約によると、すべてのデータスキーマの変更は、SQLの移行によってのみ行われます。それらの不変性により、すべての環境と完全に同一の実際のスキーマを常に取得できます。

Java移行は、純粋なSQLで記述できないDMLにのみ使用されます。私たちにとって、このような状況の典型的な例は、別のデータベースからPostgresにデータを転送するための移行です（RedisからPostgresに移行していますが、これはまったく別の話です）。もう1つの例は、大きなテーブルのデータを更新することです。これは、テーブルのロック時間を最小限に抑えるために複数のトランザクションで実行されます。 Postgresの11番目のバージョンから、これはplpgsqlのSQLプロシージャを使用して実行できることは言うまでもありません。

Javaコードが古くなっている場合、レガシーを生成しないように移行を削除できます（Java移行クラス自体は残りますが、内部は空です）。私たちの国では、これは本番環境への移行後1か月以内に発生する可能性があります。これは、すべてのテスト環境とローカル開発環境を更新するのに十分な時間であると考えています。Javaの移行はDMLにのみ使用されるため、それらを削除しても、新しいデータベースを最初から作成することにはまったく影響しないことに注意してください。

pg_bouncerを使用する人にとって重要なニュアンス

Flywayは、移行中にロックを適用して、複数の移行が同時に実行されないようにします。簡略化すると、次のように機能します。

ロックがキャプチャされています
個別のトランザクションで移行を実行する
ブロックを解除します。

Postgresの場合、セッションモードでアドバイザリロックを使用します。つまり、正しく機能するには、ロックのキャプチャと解放中にアプリケーションサーバーが同じ接続で実行されている必要があります。トランザクションモード（最も一般的）またはシングルリクエストモードでpg_bouncerを使用すると、トランザクションごとに新しい接続が返される場合があり、flywayは確立されたロックを解放できません。

この問題を解決するために、セッションモードのpg_bouncerで個別の小さな接続プールを使用します。これは移行のみを目的としています。アプリケーションの側からは、1つの接続を含む別のプールもあり、リソースを浪費しないように、移行後にタイムアウトによって閉じられます。

コーディング

移行が作成されました。現在、コードを記述しています。

アプリケーション側からデータベースを操作するには、次の3つのアプローチがあります。

ORMの使用（Javaについて話す場合、休止状態は事実上標準です）
プレーンsql + jdbcTemplateなどを使用します。
DSLライブラリの使用。

ORMを使用すると、SQLの知識の要件を減らすことができます-多くが自動的に生成されます：

データスキーマは、コードで使用可能なxml-descriptionまたはJava-entityから作成できます。
オブジェクトの関係は、宣言的な説明を使用して定義されます-ORMが結合を行います
Spring Data JPAを使用すると、リポジトリメソッドの署名に基づいてさらにトリッキーなクエリを自動的に生成することもできます。

もう1つの「ボーナス」は、すぐに使用できるデータキャッシュの存在です（休止状態の場合、これらは3レベルのキャッシュです）。

ただし、ORMは、他の強力なツールと同様に、使用するときに特定の資格が必要であることに注意することが重要です。適切な構成がないと、コードは機能する可能性が高くなりますが、最適とは言えません。

反対に、SQLを手動で作成します。これにより、リクエストを完全に制御できます。作成した内容が正確に実行され、驚くことはありません。しかし、明らかに、これは手作業の量を増やし、開発者の資格の要件を増やします。

DSLライブラリ

これらのアプローチのほぼ中間に、DSLライブラリ（jOOQ、Querydslなど）の使用からなる別のアプローチがあります。これらは通常、ORMよりもはるかに軽量ですが、完全に手動のデータベース作業よりも便利です。DSLの使用はあまり一般的ではないため、この記事ではこのアプローチについて簡単に説明します。

ライブラリの1つであるjOOQについて説明します。彼女は何を提供していますか：

データベース検査とクラスの自動生成
リクエストを書くための流暢なAPI。

jOOQはORMではありません-クエリやキャッシングの自動生成はありませんが、同時に、完全に手動のアプローチの問題のいくつかは閉じられています。

テーブル、ビュー、関数などのクラス。データベースオブジェクトは自動的に生成されます。
リクエストはJavaで記述されているため、タイプセーフが保証されます。構文的に正しくないリクエストや、間違ったタイプのパラメータを持つリクエストはコンパイルされません。IDEはすぐにエラーを要求し、アプリケーションを起動してリクエストの正確さを確認するために時間を無駄にする必要はありません。これにより、開発プロセスがスピードアップし、エラーの可能性が減少します。

コードでは、リクエストは次のようになります。

BookRecord book = dslContext.selectFrom(BOOK)
                        .where(BOOK.LANGUAGE.eq("DE"))
                        .orderBy(BOOK.TITLE)
                        .fetchAny();

必要に応じて、プレーンsqlを使用できます。

Result<Record> records = dslContext.fetch("SELECT * FROM BOOK WHERE LANGUAGE = ? ORDER BY TITLE LIMIT 1", "DE");

明らかに、この場合、クエリの正確さと結果の分析は完全にあなたの肩にかかっています。

jOOQレコードとPOJO

上記の例のBookRecordは、ブックテーブルの行のラッパーであり、アクティブなレコードパターンを実装します。このクラスは（特定の実装を除いて）データアクセスレイヤーの一部であるため、アプリケーションの他のレイヤーに転送したくない場合がありますが、独自のある種のpojoオブジェクトを使用します。レコードの変換に便利なように、<–> pojo jooqには、自動と手動のメカニズムがいくつか用意されています。上記のリンクのドキュメントには、さまざまな読み取り使用例がありますが、新しいデータの挿入と更新の例はありません。このギャップを埋めましょう：

private static final RecordUnmapper<Book, BookRecord> unmapper = 
    book -> new BookRecord(book.getTitle(), ...); // - 

public void create(Book book) {
    context.insertInto(BOOK)
            .set(unmapper.unmap(book))
            .execute();
}

ご覧のとおり、すべてが非常に単純です。

このアプローチにより、データアクセスレイヤークラス内の実装の詳細を非表示にし、アプリケーションの他のレイヤーへの「リーク」を回避できます。

また、jooqは、一連の基本的なメソッドを使用してDAOクラスを生成し、テーブルデータの操作を簡素化し、手動コードの量を減らすことができます（これはSpring Data JPAと非常によく似ています）。

public interface DAO<R extends TableRecord<R>, P, T> {
    void insert(P object) throws DataAccessException;    
    void update(P object) throws DataAccessException;
    void delete(P... objects) throws DataAccessException;
    void deleteById(T... ids) throws DataAccessException;
    boolean exists(P object) throws DataAccessException;
    ...
}

会社では、DAOクラスの自動生成を使用していません。データベースオブジェクトのラッパーを生成し、自分でクエリを作成するだけです。ラッパーの生成は、移行が保存される別のmavenモジュールが再構築されるたびに発生します。少し後で、これがどのように実装されるかについての詳細があります。

テスト

テストの作成は開発プロセスの重要な部分です。優れたテストはコードの品質を保証し、コードを維持しながら時間を節約します。同時に、その逆も当てはまると言っても過言ではありません。テストが悪いと、高品質のコードの錯覚が生じ、エラーが隠され、開発プロセスが遅くなる可能性があります。したがって、テストを作成することを決定するだけでは十分ではなく、正しく実行する必要があります。同時に、テストの正確さの概念は非常に曖昧であり、誰もが少し独自のものを持っています。

テスト分類の問題についても同じことが言えます。この記事では、次の分割オプションの使用を提案しています。

ユニットテスト（ユニットテスト）
統合テスト
エンドツーエンドテスト（エンドツーエンド）。

ユニットテストでは、個々のモジュールの機能を互いに分離してチェックします。モジュールのサイズも未定義のものです。別のメソッドである場合もあれば、クラスである場合もあります。分離とは、他のすべてのモジュールがモックまたはスタブであることを意味します（ロシア語では、これらは模倣またはスタブですが、どういうわけか、あまり良く聞こえません）。このリンクをたどって、2つの違いに関するMartinFowlerの記事を読んでください。ユニットテストは小さくて高速ですが、個々のユニットのロジックの正確さを保証することしかできません。

統合テストユニットテストとは異なり、複数のモジュールの相互作用をチェックします。データベースの操作は、統合テストが理にかなっている場合の良い例です。データベースのすべてのニュアンスを考慮して、高品質でデータベースを「ロック」することは非常に難しいためです。ほとんどの場合、統合テストは、他のタイプのテストと比較して、データベースをテストする際の実行速度と品質保証の間の適切な妥協点です。したがって、この記事では、このタイプのテストについて詳しく説明します。

エンドツーエンドのテストは最も広範囲です。それを実行するためには、環境全体を高める必要があります。製品の品質に対する最高レベルの信頼性を保証しますが、最も遅く、最も高価です。

統合テスト

データベースで動作するコードの統合テストに関しては、ほとんどの開発者は、データベースを起動する方法、初期データで状態を初期化する方法、および可能な限り迅速に実行する方法について自問します。

少し前までは、h2の使用は統合テストではかなり一般的な方法でした。これは、Javaで記述されたメモリ内データベースであり、最も一般的なデータベースとの互換性モードがあります。データベースをインストールする必要がなく、h2の汎用性により、特にアプリケーションが特定のデータベースに依存せず、SQL標準に含まれているもののみを使用する場合（常にそうであるとは限りません）、実際のデータベースの非常に便利な代替品になりました。

ただし、問題は、h2でサポートが実装されていないトリッキーなデータベース機能（または新しいバージョンからの完全に新しい機能）を使用したときに始まります。また、一般に、これは特定のDBMSの「シミュレーション」であるため、動作には常にいくつかの違いがあります。

別のオプションは、埋め込まれたpostgresを使用することです。これは実際のPostgresであり、アーカイブとして出荷され、インストールは必要ありません。これにより、通常のPostgresバージョンのように作業できます。 YandexとopenTable

から最も人気のあるいくつかの実装があります..。社内ではYandexのバージョンを使用しました。マイナス面のうち、起動時に非常に時間がかかります（アーカイブが解凍され、データベースが起動されるたびに、コンピューターの能力にもよりますが、2〜5秒かかります）、公式リリースバージョンからの遅れにも問題があります。また、コードを停止しようとした後、エラーが発生し、PostgresプロセスがOSでハングしたままになるという問題に直面しました。これは、手動で強制終了する必要がありました。

テストコンテナ

3番目のオプションはdockerを使用することです。Javaの場合、コードからdockerコンテナを操作するためのapiを提供するtestcontainersライブラリがあります。したがって、dockerイメージを持つアプリケーションの依存関係は、testcontainersを使用したテストで置き換えることができます。また、多くの一般的なテクノロジーには、使用するイメージに応じて、より便利なapiを提供する個別の既製のクラスがあります。

データベース（Postgres、Oracle、Cassandra、MongoDBなど）、
nginx
カフカなど

ちなみに、tescontainersプロジェクトが非常に人気になったとき、yandex開発者は、組み込みpostgresプロジェクトの開発を停止することを公式に発表し、testcontainersに切り替えるようにアドバイスしました。

長所は何ですか：

testcontainersは高速です（空のPostgresの起動には1秒もかかりません）
postgresコミュニティは、新しいバージョンごとに公式のドッカー画像をリリースします
testcontainersには、プログラムで実行しない限り、jvmをシャットダウンした後にぶら下がっているコンテナを強制終了する特別なプロセスがあります。
testcontainerを使用すると、統一されたアプローチを使用してアプリケーションの外部依存関係をテストできます。これにより、明らかに作業が簡単になります。

Postgresを使用したテスト例：

@Test
public void testSimple() throws SQLException {
    try (PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>()) {
        postgres.start();
        ResultSet resultSet = performQuery(postgres, "SELECT 1");
        int resultSetInt = resultSet.getInt(1);
        assertEquals("A basic SELECT query succeeds", 1, resultSetInt);
    }
}

testcontainersにイメージ用の個別のクラスがない場合、コンテナーの作成は次のようになります。

public static GenericContainer redis = new GenericContainer("redis:3.0.2")
            .withExposedPorts(6379);

JUnit4、JUnit5、またはSpockを使用している場合、testcontainersには追加の機能があります。これらのフレームワークのサポート。これにより、テストの作成が容易になります。

テストコンテナを使用したテストの高速化

埋め込まれたpostgresからtestcontainersに切り替えると、Postgresをより速く実行することでテストがより速くなりましたが、時間の経過とともにテストは再び遅くなり始めました。これは、flywayが起動時に実行するSQL移行の数が増加したためです。移行回数が100を超えると、実行時間は約7〜8秒になり、テストの速度が大幅に低下しました。それは次のように機能しました：

次のテストクラスの前に、Postgresを備えた「クリーンな」コンテナが発売されました
フライウェイは移行を実行しました
このクラスのテストが実行されました
コンテナが停止され、削除されました
次のテストクラスについて、項目1から繰り返します。

明らかに、時間の経過とともに、2番目のステップにはますます時間がかかりました。

この問題を解決しようとすると、すべてのテストの前に1回だけ移行を実行し、コンテナーの状態を保存してから、このコンテナーをすべてのテストで使用するだけで十分であることがわかりました。そのため、アルゴリズムが変更されました。

すべてのテストの前に、Postgresを備えた「クリーンな」コンテナが起動されます
flywayは移行を実行します
コンテナの状態が持続する
次のテストクラスの前に、事前に準備されたコンテナが起動されます
このクラスのテストが実行されます
コンテナが停止し、削除されます
次のテストクラスについて、手順4から繰り返します。

現在、個々のテストの実行時間は移行の数に依存せず、現在の移行の数（200以上）では、新しいスキームはすべてのテストの実行ごとに数分を節約します。

これを実装する方法に関する技術的な詳細を次に示します。

Dockerには、commitコマンドを使用して実行中のコンテナーから新しいイメージを作成するための組み込みメカニズムがあります。たとえば、設定を変更することで、画像をカスタマイズできます。

重要なニュアンスは、コマンドがマウントされたパーティションのデータを保存しないことです。ただし、公式のPostgres dockerイメージを取得すると、データが保存されているPGDATAディレクトリは別のセクションに配置されるため（コンテナーの再起動後にデータが失われないようにするため）、コミットが実行されたときにデータベース自体の状態は保存されません。

解決策は簡単です。PGDATAのセクションは使用せず、データをメモリに保持します。これは、テストではごく普通のことです。これを行うには2つの方法があります-dockerfileを使用します（このようなもの）セクションを作成せずに、または公式コンテナの開始時にPGDATA変数をオーバーライドします（セクションは残りますが、使用されません）。2番目の方法ははるかに簡単に見えます：

PostgreSQLContainer<?> container = ...
container.addEnv("PGDATA", "/var/lib/postgresql/data-no-mounted");
container.start();

コミットする前に、postgresをチェックポイントして、変更を共有バッファーから「ディスク」（オーバーライドされたPGDATA変数に対応）にフラッシュすることをお勧めします。

container.execInContainer("psql", "-c", "checkpoint");

コミット自体は次のようになります。

CommitCmd cmd = container.getDockerClient().commitCmd(container.getContainerId())
                .withMessage("Container for integration tests. ...")
                .withRepository(imageName)
                .withTag(tag);
String imageId = cmd.exec();

準備された画像を使用するこのアプローチは、他の多くの画像にも適用できるため、統合テストを実行する際の時間を節約できることは注目に値します。

ビルド時間の最適化についてもう少し

前述のように、移行を使用して個別のmavenモジュールをアセンブルする場合、特に、データベースオブジェクトに対してjavaラッパーが生成されます。このために、メインコードをコンパイルする前に起動され、次の3つのアクションを実行する自作のmavenプラグインが使用されます。

postgresで「クリーンな」ドッカーコンテナを実行します
Flywayを起動します。これは、すべてのデータベースに対してsql移行を実行し、それによってそれらの有効性をチェックします。
Jooqを実行します。これは、データベーススキーマを検査し、テーブル、ビュー、関数、およびその他のスキーマオブジェクトのJavaクラスを生成します。

簡単にわかるように、最初の2つの手順は、テストの実行時に実行される手順と同じです。コンテナの起動とテスト前の移行の実行にかかる時間を節約するために、コンテナの状態の保存をプラグインに移動しました。したがって、モジュールを再構築した直後に、コードで使用されているすべてのデータベースの統合テスト用の既製のイメージが、dockerイメージのローカルリポジトリに表示されます。

より詳細なコード例

@ThreadSafe
public class PostgresContainerAdapter implements PostgresExecutable {
  private static final String ORIGINAL_IMAGE = "postgres:11.6-alpine";

  @GuardedBy("this")
  @Nullable
  private PostgreSQLContainer<?> container; // not null if it is running

  @Override
  public synchronized String start(int port, String db, String user, String password) 
  {
    Preconditions.checkState(container == null, "postgres is already running");

    PostgreSQLContainer<?> newContainer = new PostgreSQLContainer<>(ORIGINAL_IMAGE)
        .withDatabaseName(db)
        .withUsername(user)
        .withPassword(password);

    newContainer.addEnv("PGDATA", "/var/lib/postgresql/data-no-mounted");

    // workaround for using fixed port instead of random one chosen by docker
    List<String> portBindings = new ArrayList<>(newContainer.getPortBindings());
    portBindings.add(String.format("%d:%d", port, POSTGRESQL_PORT));
    newContainer.setPortBindings(portBindings);
    newContainer.start();

    container = newContainer;
    return container.getJdbcUrl();
  }

  @Override
  public synchronized void saveState(String name) {
    try {
      Preconditions.checkState(container != null, "postgres isn't started yet");

      // flush all changes
      doCheckpoint(container);

      commitContainer(container, name);
    } catch (Exception e) {
      stop();
      throw new RuntimeException("Saving postgres container state failed", e);
    }
  }

  @Override
  public synchronized void stop() {
    Preconditions.checkState(container != null, "postgres isn't started yet");

    container.stop();
    container = null;
  }

  private static void doCheckpoint(PostgreSQLContainer<?> container) {
    try {
      container.execInContainer("psql", "-c", "checkpoint");
    } catch (IOException | InterruptedException e) {
      throw new RuntimeException(e);
    }
  }

  private static void commitContainer(PostgreSQLContainer<?> container, String image)
  {
    String tag = "latest";
    container.getDockerClient().commitCmd(container.getContainerId())
        .withMessage("Container for integration tests. It uses non default location for PGDATA which is not mounted to a volume")
        .withRepository(image)
        .withTag(tag)
        .exec();
  }
  // ...
}

( «start»):

@Mojo(name = "start")
public class PostgresPluginStartMojo extends AbstractMojo {
  private static final Logger logger = LoggerFactory.getLogger(PostgresPluginStartMojo.class);

  @Nullable
  static PostgresExecutable postgres;

  @Parameter(defaultValue = "5432")
  private int port;
  @Parameter(defaultValue = "dbName")
  private String db;
  @Parameter(defaultValue = "userName")
  private String user;
  @Parameter(defaultValue = "password")
  private String password;

  @Override
  public void execute() throws MojoExecutionException {
    if (postgres != null) { 
      logger.warn("Postgres already started");
      return;
    }
    logger.info("Starting Postgres");
    if (!isDockerInstalled()) {
      throw new IllegalStateException("Docker is not installed");
    }
    String url = start();
    testConnection(url, user, password);
    logger.info("Postgres started at " + url);
  }

  private String start() {
    postgres = new PostgresContainerAdapter();
    return postgres.start(port, db, user, password);
  }

  private static void testConnection(String url, String user, String password) throws MojoExecutionException {
    try (Connection conn = DriverManager.getConnection(url, user, password)) {
      conn.createStatement().execute("SELECT 1");
    } catch (SQLException e) {
      throw new MojoExecutionException("Exception occurred while testing sql connection", e);
    }
  }

  private static boolean isDockerInstalled() {
    if (CommandLine.executableExists("docker")) {
      return true;
    }
    if (CommandLine.executableExists("docker.exe")) {
      return true;
    }
    if (CommandLine.executableExists("docker-machine")) {
      return true;
    }
    if (CommandLine.executableExists("docker-machine.exe")) {
      return true;
    }
    return false;
  }
}

save-state stop .

:

<build>
  <plugins>
    <plugin>
      <groupId>com.miro.maven</groupId>
      <artifactId>PostgresPlugin</artifactId>
      <executions>
        <!-- running a postgres container -->
        <execution>
          <id>start-postgres</id>
          <phase>generate-sources</phase>
          <goals>
            <goal>start</goal>
          </goals>
          
          <configuration>
            <db>${db}</db>
            <user>${dbUser}</user>
            <password>${dbPassword}</password>
            <port>${dbPort}</port>
          </configuration>
        </execution>
        
        <!-- applying migrations and generation java-classes -->
        <execution>
          <id>flyway-and-jooq</id>
          <phase>generate-sources</phase>
          <goals>
            <goal>execute-mojo</goal>
          </goals>
          
          <configuration>
            <plugins>
              <!-- applying migrations -->
              <plugin>
                <groupId>org.flywaydb</groupId>
                <artifactId>flyway-maven-plugin</artifactId>
                <version>${flyway.version}</version>
                <executions>
                  <execution>
                    <id>migration</id>
                    <goals>
                      <goal>migrate</goal>
                    </goals>
                    
                    <configuration>
                      <url>${dbUrl}</url>
                      <user>${dbUser}</user>
                      <password>${dbPassword}</password>
                      <locations>
                        <location>filesystem:src/main/resources/migrations</location>
                      </locations>
                    </configuration>
                  </execution>
                </executions>
              </plugin>

              <!-- generation java-classes -->
              <plugin>
                <groupId>org.jooq</groupId>
                <artifactId>jooq-codegen-maven</artifactId>
                <version>${jooq.version}</version>
                <executions>
                  <execution>
                    <id>jooq-generate-sources</id>
                    <goals>
                      <goal>generate</goal>
                    </goals>
                      
                    <configuration>
                      <jdbc>
                        <url>${dbUrl}</url>
                        <user>${dbUser}</user>
                        <password>${dbPassword}</password>
                      </jdbc>
                      
                      <generator>
                        <database>
                          <name>org.jooq.meta.postgres.PostgresDatabase</name>
                          <includes>.*</includes>
                          <excludes>
                            #exclude flyway tables
                            schema_version | flyway_schema_history
                            # other excludes
                          </excludes>
                          <includePrimaryKeys>true</includePrimaryKeys>
                          <includeUniqueKeys>true</includeUniqueKeys>
                          <includeForeignKeys>true</includeForeignKeys>
                          <includeExcludeColumns>true</includeExcludeColumns>
                        </database>
                        <generate>
                          <interfaces>false</interfaces>
                          <deprecated>false</deprecated>
                          <jpaAnnotations>false</jpaAnnotations>
                          <validationAnnotations>false</validationAnnotations>
                        </generate>
                        <target>
                          <packageName>com.miro.persistence</packageName>
                          <directory>src/main/java</directory>
                        </target>
                      </generator>
                    </configuration>
                  </execution>
                </executions>
              </plugin>
            </plugins>
          </configuration>
        </execution>

        <!-- creation an image for integration tests -->
        <execution>
          <id>save-state-postgres</id>
          <phase>generate-sources</phase>
          <goals>
            <goal>save-state</goal>
          </goals>
          
          <configuration>
            <name>postgres-it</name>
          </configuration>
        </execution>

        <!-- stopping the container -->
        <execution>
          <id>stop-postgres</id>
          <phase>generate-sources</phase>
          <goals>
            <goal>stop</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

リリース

コードが書かれ、テストされました-リリースする時が来ました。一般に、リリースの複雑さは次の要因によって異なります。

データベースの数（1つ以上）
データベースのサイズについて
アプリケーションサーバーの数（1つ以上）
シームレスリリースかどうか（アプリケーションのダウンタイムが許可されているかどうか）。

ほとんどの場合、すべてのデータベースとすべてのアプリケーションサーバーを同時に更新することは不可能であるため、項目1と3は、コードに下位互換性の要件を課します。データベースのスキーマが異なり、サーバーのコードのバージョンが異なる場合が常にあります。

データベースのサイズは移行時間に影響します。データベースが大きいほど、長い移行を実行する必要が生じる可能性が高くなります。

シームレス性は部分的に結果として生じる要因です-リリースがシャットダウン（ダウンタイム）で実行される場合、最初の3つのポイントはそれほど重要ではなく、アプリケーションが利用できない時間にのみ影響します。

私たちのサービスについて話す場合、これらは次のとおりです。

約30のデータベースクラスター

1つのベースのサイズ200〜400 GB
( 100),
.

カナリアリリースを使用します。アプリケーションの新しいバージョンが最初に少数のサーバーに表示され（プレリリースと呼ばれます）、しばらくして、プレリリースでエラーが見つからない場合は、他のサーバーにリリースされます。したがって、実稼働サーバーはさまざまなバージョンで実行できます。

起動時に、各アプリケーションサーバーは、ソースコードにあるスクリプトのバージョンを使用してデータベースのバージョンをチェックします（フライウェイの観点から、これは検証と呼ばれます）。それらが異なる場合、サーバーは起動しません。これにより、コードとデータベースの互換性が保証されます。たとえば、移行がサーバーの別のバージョンで行われているために、コードがまだ作成されていないテーブルで機能する場合、状況は発生しません。

ただし、たとえば、新しいバージョンのアプリケーションで、古いバージョンのサーバーで使用できるテーブルの列を削除する移行がある場合、これはもちろん問題を解決しません。現在、このような状況はレビュー段階でのみチェックしています（必須です）が、友好的な方法で追加を導入する必要があります。CI / CDサイクルでこのようなチェックを行うステージ。

移行に時間がかかる場合があり（たとえば、大きなテーブルからデータを更新する場合）、同時にリリースの速度を低下させないために、組み合わせ移行の手法を使用します。..。この組み合わせは、実行中のサーバーで手動で移行を実行し（管理パネルを介して、フライウェイなしで、したがって移行履歴に記録せずに）、サーバーの次のバージョンで同じ移行の「通常の」出力を実行することで構成されます。これらの移行には、次の要件が適用されます。

まず、長時間の実行中にアプリケーションをブロックしないように作成する必要があります（ここでの重要なポイントは、DBレベルで長期ロックを取得しないことです）。これを行うために、移行の記述方法に関する開発者向けの内部ガイドラインがあります。将来的には、Habréでも共有する可能性があります。
次に、「通常の」起動中の移行では、すでに手動モードで実行されていることを確認し、この場合は何も実行しないでください。履歴に新しいレコードをコミットするだけです。SQL移行の場合、このようなチェックは、変更についてSQLクエリを実行することによって実行されます。Java移行の別のアプローチは、手動実行後に設定される保存されたブールフラグを使用することです。

このアプローチは2つの問題を解決します：

リリースは高速です（手動アクションではありますが）
( ) - .

リリースされると、開発サイクルは終了しません。新しい機能が機能するかどうか（およびどのように機能するか）を理解するには、メトリックで「囲む」必要があります。それらは、ビジネスとシステムの2つのグループに分けることができます。

最初のグループはサブジェクト領域に強く依存します。メールサーバーの場合、送信された文字の数、ニュースリソースの場合、1日あたりの一意のユーザーの数などを知っておくと便利です。

2番目のグループのメトリックは、サーバーの技術的状態（cpu、メモリ、ネットワーク、データベースなど）を決定します。

正確に監視する必要があるものとその方法は、すべての人にとってほぼ同じです。これは、膨大な数の個別の記事のトピックであり、ここでは触れません。最も基本的な（キャプテンでさえ）ことだけを思い出させたい：

事前にメトリックを定義する

基本的なメトリックのリストを定義する必要があります。また、システムで何が起こっているのかがわからない場合は、最初のインシデントの後ではなく、リリース前に事前に行う必要があります。

自動アラートを設定する

これにより、反応時間が短縮され、手動監視の時間が節約されます。理想的には、ユーザーが問題を感じてあなたに手紙を書く前に、問題について知っておく必要があります。

すべてのノードからメトリックを収集する

ログのように、メトリックが多すぎることはありません。システムの各ノード（アプリケーションサーバー、データベース、接続プーラー、バランサーなど）からのデータの存在により、その状態の全体像を把握でき、必要に応じて、問題をすばやく特定できます。

簡単な例：Webページのデータの読み込みが遅くなり始めました。多くの理由が考えられます：

Webサーバーが過負荷になり、要求への応答に時間がかかります

SQLクエリの実行に時間がかかる
キューが接続プールに蓄積され、アプリケーションサーバーが長時間接続を受信できない
ネットワークの問題
他の何か

指標がなければ、問題の根本原因を見つけるのは簡単ではありません。

完了の代わりに

特効薬がなく、どちらのアプローチを選択するかは特定のタスクの要件に依存し、他の人にとってうまくいくことはあなたには当てはまらないかもしれないという事実について、非常に平凡な言い方をしたいと思います。しかし、あなたが知っているアプローチが多ければ多いほど、この選択をより徹底的かつ定性的に行うことができます。この記事から、あなたが将来あなたを助けるであろうあなた自身のために何か新しいことを学んだことを願っています。データベースの操作プロセスを改善するためにどのようなアプローチを使用しているかについてコメントさせていただきます。

開発者の目を通してデータベースを操作する