Har du noen gang opplevd marerittet når din lokale database ser helt perfekt ut, men produksjonsdatabasen er et komplett kaos? Du er ikke alene. Mange utviklerteam møter utfordringer med å holde databasen og applikasjonskoden synkronisert, spesielt når endringene skal rulles ut i forskjellige miljøer. Dette kan føre til nedetid, frustrerte brukere og overarbeidede utviklere.

Siden 2010 har Flyway, et Java-basert verktøy, tilbudt en robust løsning for å håndtere databasemigrasjoner på en sikker, versjonskontrollert måte. Selv om Flyway primært er utviklet for Java, er det også effektivt når det brukes i Kotlin-prosjekter, takket være Kotlin sin interoperabilitet med Java.

I denne bloggposten vil vi spesielt fokusere på hvordan Kotlin-utviklere kan bruke Flyway for å håndtere databaseendringer. Vi vil gå gjennom oppsett av datasource i Kotlin, og utforske hvordan Flyway kan brukes til å unngå vanlige fallgruver i databasehåndtering. Les videre for å lære hvordan du kan gjøre dine databasemigrasjoner smidige med Flyway i Kotlin-miljøer.

Hvordan Flyway fungerer

Flyway hjelper med å håndtere databaseversjoner gjennom en enkel, men effektiv tilnærming ved bruk av SQL-script. Prosessen starter med at du skriver et SQL-script for hver endring eller tillegg du ønsker å gjøre i databasen. Hvert script navngis med et versjonsnummer som definerer rekkefølgen de skal kjøres i. For eksempel, hvis den nåværende versjonen av databasen din er 41, og du trenger å gjøre en endring, vil du opprette et nytt script kalt V42__compensatory_measures.sql. Prefixet V42 angir at dette scriptet vil oppgradere databasen til versjon 42. Resten av filnavnet er et navn som beskriver hva migrasjonen dreier seg om.

Overordnet skisse

Når Flyway kjøres, vil det sjekke databasens nåværende versjon og deretter se etter SQL-script med høyere versjonsnumre. Flyway vil utføre disse scriptene i rekkefølge, én etter én, for å oppdatere databasen. Dette sikrer at alle endringer blir utført på en kontrollert og sekvensiell måte, og hver vellykket migrasjon øker databasens versjonsnummer. Hvis et script feiler, vil Flyway stoppe prosessen, slik at feilen kan rettes uten å påvirke resten av databasen.

Ved å bruke denne metoden, sikrer Flyway at alle deler av systemet alltid er synkronisert med riktig versjon av databasen, og at ingen endringer går tapt eller blir utført ut av rekkefølge. Dette er spesielt nyttig i teammiljøer og ved deployering i forskjellige miljøer, fra utvikling til produksjon.

Legge til Flyway i ditt prosjekt

I dette eksempelet bruker vi Gradle som byggeverktøy. For å begynne å bruke Flyway i ditt Kotlin-prosjekt, må du først legge til nødvendig avhengighet. Dette sikrer at Flyway-biblioteket er tilgjengelig, og at du kan bruke det til å håndtere databasemigrasjoner. Legg til følgende linje i dependencies i prosjektets build.gradle.kt:

implementation("org.flywaydb:flyway-core:10.15.0")
implementation("org.flywaydb:flyway-database-postgresql:10.15.0")

Ved å inkludere denne avhengigheten, vil du ha tilgang til alle Flyway-funksjoner som er nødvendige for å administrere databaseversjoner og utføre migrasjoner for PostgreSQL.

Konfigurere Flyway for å utføre migrasjoner

Når du har lagt til Flyway-avhengigheten i ditt prosjekt, er neste skritt å sikre at Flyway utfører nødvendige migrasjoner når applikasjonen starter. Dette involverer konfigurering av Flyway sammen med din datasource. Her er et eksempel på hvordan du kan konfigurere og initiere databasemigrasjoner i Kotlin:

private fun migrateDataSource(config: WebappConfig.DatabaseConfig, dataSource: DataSource): MigrateResult {
    // Angi spesifikk sti for seed data basert på miljø
    val environmentSpecificSeedDataPath = getEnvironmentSpecificSeedDataPath()
    val migrationPaths = arrayOf(
        "db/tables",  // Path for database skjema
        "db/common_seed_data",  // Path for felles seed data
        "filesystem:$environmentSpecificSeedDataPath"  // Dynamisk path for miljøspesifikke data
    )

    // Konfigurer og kjør Flyway migrasjon
    return Flyway.configure()
        .baselineOnMigrate(config.baselineOnMigrate)  // Om migrasjonen skal starte på en baseline
        .dataSource(dataSource)  // DataSource konfigurasjon
        .locations(*migrationPaths)  // Lokasjoner for migrasjonsfiler
        .table("flyway_schema_history")  // Default navn på tabellen som holder styr på migrasjonshistorikken
        .load()  // Last Flyway konfigurasjon
        .migrate()  // Utfør migrasjon
}

Forklaring av Koden:

  • environmentSpecificSeedDataPath: Denne variabelen inneholder den spesifikke stien til seed data basert på det gjeldende miljøet, noe som sikrer at riktig data brukes.
  • migrationPaths: En array som inneholder stiene til migrasjonsfilene. Dette inkluderer generelle tabelldefinisjoner, felles seed data, og miljøspesifikke seed data. I dette tilfellet vil prosjektet ha to foldere med SQL-script i /src/main/resources/db: tables/ og common_seed_data/
  • Flyway.configure(): Her konfigureres Flyway med diverse innstillinger, inkludert baselineOnMigrate, som angir om en baseline-versjon skal brukes ved første migrasjon. dataSource angir kilden til databasen, og locations peker på hvor migrasjonsfilene finnes.
  • .migrate(): Denne metoden utfører selve migrasjonen ved å kjøre SQL-scriptene definert i de angitte lokasjonene.

Ved å integrere denne funksjonen i oppstartsrutinen for din applikasjon, kan du sikre at databasen alltid er oppdatert med de nyeste skjemaendringene og nødvendig seed data, noe som minimerer risikoen for databaserelaterte feil under drift.

Sikre robust oppstart med korrekt databasekonfigurasjon

For å sikre at applikasjonen din starter med en korrekt konfigurert og oppdatert database, er det viktig at migrasjonsprosessen gjennomføres som en del av opprettelsen av datasourcen. Her er et eksempel på hvordan du kan opprette en datasource og utføre nødvendige databasemigrasjoner samtidig, og sørge for at applikasjonen ikke starter hvis migrasjonen feiler:

private fun createAndMigrateDataSource(): DataSource {
    val dataSource = HikariDataSource().apply {
        jdbcUrl = config.dbUrl  // Database URL
        username = config.dbUser  // Database brukernavn
        password = config.dbPassword  // Database passord
    }
    // Utfør migrasjonen
    val migrateResult = migrateDataSource(config, dataSource)
    // Sjekk at migrasjonen var vellykket
    check(migrateResult.success) { "Flyway migration failed!" }

    return dataSource  // Returnerer den konfigurerte og migrerte datasourcen
}

Hovedpunkter i Koden:

  • HikariDataSource().apply {…}: Opprett en ny DataSource ved hjelp av HikariCP for forbindelsesstyring, og konfigurer den med nødvendige detaljer som URL, brukernavn og passord.
  • migrateDataSource(…): Kall funksjonen som utfører Flyway-migrasjon. Dette er funksjonen i forrige eksempel.
  • check(migrateResult.success) {…}: Etter migrasjonen sjekker denne linjen om migrasjonen var vellykket. Hvis migrasjonen feiler, vil check-funksjonen kaste en exception og stoppe oppstarten av applikasjonen, noe som forhindrer at applikasjonen kjører med en feilkonfigurert eller utdatert database.

Ved å følge denne tilnærmingen sikrer du at databasen alltid er korrekt konfigurert før applikasjonen blir tilgjengelig, og du unngår potensielle problemer som kan oppstå på grunn av forskjeller eller feil i databasen under kjøring.

Håndtering av samtidighetsproblematikk i clustermiljøer

En vanlig utfordring i moderne applikasjonsutvikling er å sikre at databasemigrasjoner håndteres korrekt i et clustermiljø, hvor flere instanser av en applikasjon kan starte samtidig. Dette er spesielt relevant i Kubernetes-cluster, hvor applikasjonen kan skaleres dynamisk.

Flyway tilbyr en robust løsning på dette problemet gjennom sin låsemekanisme. Når en migrasjon starter, setter Flyway en lås i databasen som forhindrer andre instanser fra å initiere migrasjonen samtidig. Dette sikrer at selv om flere pods forsøker å utføre migrasjoner samtidig, vil kun én pod utføre migrasjonen, mens de andre vil vente til låsen frigjøres. Denne tilnærmingen forhindrer migrasjonskonflikter og sikrer en konsistent databasestatus gjennom hele clusteret.

I Kubernetes kan denne prosessen ytterligere forbedres ved å bruke en Rolling Update deployeringsstrategi. Med Rolling Updates starter Kubernetes en ny pod, og når den nye poden er klar, termineres en gammel pod, og prosessen gjentas til alle pods er oppdatert. Denne sekvensielle tilnærmingen til pod-oppdateringer kan redusere risikoen for migrasjonskonflikter selv før Flyway’s låsemekanisme trer i kraft.

Det er viktig for utviklere å være klar over disse mekanismene og strategiene for å sikre at databasemigrasjoner håndteres pålitelig i distribuerte og dynamisk skalerbare miljøer som Kubernetes.

Refleksjoner rundt Valg av Migreringsverktøy

Flyway har vært en god hjelper i mine prosjekter, og har spart meg for store mengder tid og innsats ved å automatisere kjedelig og gjentakende arbeid med databasemigrasjoner. Gjennom årene har jeg også vært klar over andre populære verktøy som for eksempel Liquibase. Disse har sine egne fordeler og brukersamfunn.

Selv om jeg har hatt gode erfaringer med Flyway, er jeg åpen for å prøve andre verktøy hvis de tilbyr klare forbedringer eller passer bedre med teamets behov i fremtiden. Det viktigste for meg er å finne et verktøy som er pålitelig og gjør jobben godt.

Å velge riktig migreringsverktøy avhenger av mange faktorer, inkludert teamets spesifikke behov, teknologisk komfort og prosjektets krav. Flyway har fungert for meg, men det beste verktøyet for ditt prosjekt kan være et annet, avhengig av dine unike omstendigheter.

Hvis du ennå ikke har tatt i bruk Flyway, kan det være verdt å vurdere dette verktøyet for ditt eget prosjekt. Det kan kanskje gjøre en forskjell for deg og ditt team, akkurat som det har gjort for meg.

Lykke til med databasemigrasjonene, og må prosjektet ditt blomstre med så få tekniske hindringer som mulig!