Migrasi Flyway dalam Projek Gradle Berbilang Modul (Seni Bina Bersih)

Mengautomasikan Migrasi Pangkalan Data di Java dengan Flyway

Penghijrahan pangkalan data ialah aspek penting dalam pembangunan perisian, terutamanya dalam persekitaran di mana penyepaduan dan penghantaran berterusan (CI/CD) adalah amalan standard. Apabila aplikasi anda berkembang dan berkembang, skema pangkalan data juga mesti bergantung padanya. Menguruskan perubahan skema ini secara manual boleh menyebabkan ralat dan memakan masa yang ketara.

Enter Flyway, alat sumber terbuka yang tidak ternilai yang disesuaikan untuk memudahkan migrasi pangkalan data. Flyway memperkenalkan kawalan versi ke pangkalan data anda, membolehkan anda memindahkan skema anda dengan selamat dan dengan kebolehpercayaan. Dalam artikel ini, kami akan meneroka cara untuk mengautomasikan pemindahan pangkalan data dalam projek gragle java berbilang modul menggunakan Flyway, memastikan pengurusan perubahan pangkalan data menjadi proses yang diperkemas dan tahan ralat.

Maklumat lanjut tentang flyway

Memahami Binaan Berbilang Projek dalam Gradle

Walaupun sesetengah projek yang lebih kecil atau aplikasi monolitik mungkin diuruskan dengan hanya satu fail binaan dan struktur sumber bersatu, projek yang lebih besar kerap disusun menjadi beberapa modul yang saling bergantung. Istilah "saling bergantung" adalah penting di sini, menonjolkan keperluan untuk menyambungkan modul ini melalui proses binaan tunggal.

Gradle memenuhi persediaan ini dengan keupayaan binaan berbilang projeknya, yang sering disebut sebagai projek berbilang modul. Dalam terminologi Gradle, modul ini dipanggil subprojek.

Binaan berbilang projek distrukturkan di sekitar satu projek akar dan boleh termasuk beberapa subprojek di bawahnya.

Struktur direktori hendaklah kelihatan seperti berikut:

├── .gradle
│   └── ⋮
├── gradle
│   ├── libs.versions.toml
│   └── wrapper
├── gradlew
├── gradlew.bat
├── settings.gradle.kts (1)
├── sub-project-1
│   └── build.gradle.kts (2) 
├── sub-project-2
│   └── build.gradle.kts (2) 
└── sub-project-3
    └── build.gradle.kts (2)

(1) Fail settings.gradle.kts hendaklah termasuk semua subprojek.
(2) Setiap subprojek harus mempunyai fail build.gradle.kts sendiri.

Memanfaatkan Sub-Modul Gradle untuk Seni Bina Bersih

Clean Architecture ialah corak reka bentuk yang menekankan pengasingan kebimbangan, menjadikan perisian lebih mudah untuk diselenggara dan diuji. Salah satu cara praktikal untuk melaksanakan seni bina ini dalam projek melibatkan penggunaan struktur submodul Gradle untuk menyusun pangkalan kod anda. Begini cara anda boleh menyelaraskan Seni Bina Bersih dengan sub-modul Gradle:

Lapisan Seni Bina Bersih:
Teras:

• Mengandungi logik perniagaan, model domain dan peraturan aplikasi. Tidak mempunyai pergantungan pada Luaran atau Web.
• Hendaklah bebas daripada pelaksanaan khusus rangka kerja jika boleh.

Luaran:

• Mengendalikan tindakan atau penyepaduan luaran, seperti pemindahan pangkalan data atau interaksi perkhidmatan pihak ketiga.
• Mungkin bergantung pada Teras untuk logik perniagaan tetapi tidak boleh bergantung pada Web.

Web:

• Titik masuk, mendedahkan REST API dan mengendalikan permintaan HTTP.
• Bergantung pada Teras untuk logik perniagaan dan mungkin bergantung pada Luaran untuk penyepaduan.

├── .gradle
│   └── ⋮
├── gradle
│   ├── libs.versions.toml
│   └── wrapper
├── gradlew
├── gradlew.bat
├── settings.gradle.kts (1)
├── sub-project-1
│   └── build.gradle.kts (2) 
├── sub-project-2
│   └── build.gradle.kts (2) 
└── sub-project-3
    └── build.gradle.kts (2)

Langkah 1: Buat projek Gradle berasaskan Java dan namakannya "SchoolStaff".

Langkah 2: Pergi ke Spring Initializr dan hasilkan projek REST API bernama Web.

Langkah 3: Cipta projek Gradle berasaskan Java dan namakannya Luaran.

Langkah 4: Buat projek Gradle berasaskan Java dan namakannya Teras.

Root build.gradle.kts

SchoolStaff/
├── Core/
│   ├── src/
│   │   └── main/
│   │       ├── java/         # Business logic and domain objects
│   │       └── resources/    # Core-specific resources (if any)
│   └── build.gradle.kts
├── External/
│   ├── src/
│   │   └── main/
│   │       ├── java/         # External integration code
│   │       └── resources/    # db/migration and other external resources
│   └── build.gradle.kts
├── Web/
│   ├── src/
│   │   └── main/
│   │       ├── java/         # REST controllers and entry-point logic
│   │       └── resources/    # Application-specific configuration
│   └── build.gradle.kts
├── build.gradle.kts          # Root Gradle build
└── settings.gradle.kts       # Project module settings

settings.gradle.kts

plugins {
    id("java")
}

allprojects {
    group = "school.staff"
    version = "1.0.0"

    repositories {
        mavenLocal()
        mavenCentral()
    }
}

subprojects {
    apply(plugin = "java")

    dependencies {
        testImplementation(platform("org.junit:junit-bom:5.10.0"))
        testImplementation("org.junit.jupiter:junit-jupiter")
    }

    tasks.test {
        useJUnitPlatform()
    }
}

Kebergantungan yang diperlukan untuk projek "Web".

rootProject.name = "SchoolStaff"

include("Core", "External", "Web")

Kebergantungan yang diperlukan untuk projek "Teras".

dependencies {
    implementation(project(":Core"))
    implementation(project(":External"))
}

Kebergantungan yang diperlukan untuk projek "Luaran".

dependencies {
    runtimeOnly(project(":External"))
}

Kami menggunakan pemalam berikut untuk penghijrahan Flyway:

import java.sql.DriverManager
import java.util.Properties
// Function to load properties based on the environment
fun loadProperties(env: String): Properties {
    val properties = Properties()
    val propsFile = file("../web/src/main/resources/application-$env.properties")

    if (propsFile.exists()) {
        propsFile.inputStream().use { properties.load(it) }
    } else {
        throw GradleException("Properties file for environment '$env' not found: ${propsFile.absolutePath}")
    }

    return properties
}
// Set the environment (default is 'dev' if no argument is passed)
val env = project.findProperty("env")?.toString() ?: "dev"

// Load properties for the chosen environment
val dbProps = loadProperties(env)
buildscript {
    dependencies {
        classpath("org.flywaydb:flyway-database-postgresql:11.1.0") // This is required for the flyway plugin to work on the migration, otherwise it will throw an error as No Database found
        classpath("org.postgresql:postgresql:42.7.4")
    }
}
plugins {
    id("java-library")
    id("org.flywaydb.flyway") version "11.0.1"
}

group = "school.staff"
version = "unspecified"

repositories {
    mavenLocal()
    mavenCentral()
}

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-data-jpa:3.4.0")
    implementation("org.postgresql:postgresql:42.7.4")
    implementation("org.flywaydb:flyway-core:11.0.1")
    implementation("org.flywaydb:flyway-database-postgresql:11.0.1")
    implementation("org.flywaydb:flyway-gradle-plugin:11.0.1")

    implementation (project(":Core"))
    testImplementation(platform("org.junit:junit-bom:5.10.0"))
    testImplementation("org.junit.jupiter:junit-jupiter")
}

tasks.test {
    useJUnitPlatform()
}

// Task to create the database if it doesn't exist
tasks.register("createDatabase") {
    doLast {
        val dbUrl = dbProps["spring.datasource.url"] as String
        val dbUsername = dbProps["spring.datasource.username"] as String
        val dbPassword = dbProps["spring.datasource.password"] as String

        // Extract the base URL and database name
        val baseDbUrl = dbUrl.substringBeforeLast("/")+ "/"
        val dbName = dbUrl.substringAfterLast("/")

        // Connect to the PostgreSQL server (without the specific database)
        DriverManager.getConnection(baseDbUrl, dbUsername, dbPassword).use { connection ->
            val stmt = connection.createStatement()
            val resultSet = stmt.executeQuery("SELECT 1 FROM pg_database WHERE datname = '$dbName'")
            if (!resultSet.next()) {
                println("Database '$dbName' does not exist. Creating it...")
                stmt.executeUpdate("CREATE DATABASE \"$dbName\"")
                println("Database '$dbName' created successfully.")
            } else {
                println("Database '$dbName' already exists.")
            }
        }
    }
}

flyway {
    url = dbProps["spring.datasource.url"] as String
    user = dbProps["spring.datasource.username"] as String
    password = dbProps["spring.datasource.password"] as String
    locations = arrayOf("classpath:db/migration")
    baselineOnMigrate = true
}

 //Ensure classes are built before migration
tasks.named("flywayMigrate").configure {
    dependsOn(tasks.named("createDatabase"))
    dependsOn(tasks.named("classes"))
}

Pendekatan ini sangat sesuai untuk persekitaran pengeluaran, kerana ia memastikan migrasi terkawal dan boleh dipercayai. Daripada menjalankan migrasi secara automatik pada setiap permulaan aplikasi, kami melaksanakannya hanya apabila perlu, memberikan fleksibiliti dan kawalan yang lebih besar.

Kami juga menggunakan fail application.properties dalam aplikasi Spring untuk mengurus sambungan pangkalan data dan bukti kelayakan. Tetapan baselineOnMigrate = benar memastikan bahawa migrasi awal digunakan sebagai garis dasar untuk migrasi masa hadapan.

 plugins {
    id("org.flywaydb.flyway") version "11.0.1"
}

Kami boleh menggunakan JPA Buddy untuk menjana semua fail migrasi dalam direktori sumber/db/migrasi projek Luaran.

V1__Initial_Migration

flyway {
    url = dbProps["spring.datasource.url"] as String
    user = dbProps["spring.datasource.username"] as String
    password = dbProps["spring.datasource.password"] as String
    locations = arrayOf("classpath:db/migration")
    baselineOnMigrate = true
}

Daripada projek root, kita boleh melaksanakan migrasi Flyway menggunakan arahan berikut:

CREATE TABLE _user
(
    id                 UUID NOT NULL,
    created_by         UUID,
    created_date       TIMESTAMP WITH TIME ZONE,
    last_modified_by   UUID,
    last_modified_date TIMESTAMP WITH TIME ZONE,
    first_name         VARCHAR(255),
    last_name          VARCHAR(255),
    email              VARCHAR(255),
    password           VARCHAR(255),
    tenant_id          UUID,
    CONSTRAINT pk__user PRIMARY KEY (id)
);

Ini akan menggunakan semua fail migrasi ke pangkalan data.

Kesimpulan

Kami telah meneroka cara mengautomasikan migrasi pangkalan data menggunakan Flyway dalam projek berbilang modul Gradle, yang penting untuk mengekalkan ketekalan skema dalam persekitaran CI/CD.

Kami juga membincangkan cara Gradle menyokong binaan berbilang projek, mengatur projek yang kompleks menjadi subprojek yang boleh diurus, masing-masing dengan konfigurasi binaan sendiri, disatukan di bawah skrip binaan akar.

Akhir sekali, kami menyelaraskan Seni Bina Bersih dengan modul Gradle, menstrukturkan projek ke dalam lapisan Teras, Luaran dan Web, mempromosikan pengasingan bersih kebimbangan dan pengurusan pergantungan.

Amalan ini meningkatkan kemodulatan, automasi dan kebolehselenggaraan, menetapkan peringkat untuk pembangunan perisian bebas ralat berskala.

Atas ialah kandungan terperinci Migrasi Flyway dalam Projek Gradle Berbilang Modul (Seni Bina Bersih). Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!