De functie Environment Merge stelt je in staat om schemawijzigingen van één omgeving (bron) toe te passen op een andere (doel). Dit is de kernbewerking die structurele wijzigingen — zoals nieuwe tabellen, kolommen, views en enums — door je ontwikkellevenscyclus propageert.

---

Hoe Merge werkt

Het merge-proces is ontworpen om veilig, voorspelbaar en transparant te zijn:

1. Selectie: Selecteer een bronomgeving (waar de wijzigingen vandaan komen) en een doelomgeving (waar je ze wilt toepassen).
2. Analyse: Het systeem voert een diff uit om alle ontbrekende wijzigingen in de doelomgeving te identificeren.
3. Beoordeling & Cherry-pick: Beoordeel de gedetecteerde wijzigingen en kies selectief welke je wilt toepassen.
4. Automatische backup: Voordat er wijzigingen worden toegepast, maakt Archie Core een volledige backup van de data en structuur van de doelomgeving.
5. Atomische toepassing: Geselecteerde wijzigingen worden als één bewerking toegepast. Als een deel van de merge faalt, wordt de hele bewerking automatisch teruggedraaid.

---

Beveiliging & betrouwbaarheid

Archie Core garandeert de integriteit van je productie- en staging-omgevingen tijdens een merge:

• Transactionele updates: Alle schemawijzigingen worden binnen één transactie toegepast. Dit betekent dat ofwel alle geselecteerde wijzigingen succesvol worden toegepast, of geen — waardoor je database niet in een gedeeltelijk gemigreerde staat kan komen.
• Omgevingsvergrendeling: Tijdens een merge wordt de doelomgeving vergrendeld om gelijktijdige configuratiewijzigingen te voorkomen.
• Automatische pre-merge backups: Er wordt altijd een “vangnet”-backup gemaakt direct vóór uitvoering. Als een merge slaagt maar je later een probleem ontdekt, kun je herstellen naar de exacte staat vóór de merge via de Backups-pagina.

---

Cherry-Pick-selectie

De merge-interface biedt gedetailleerde controle over wat wordt verplaatst:

• Individuele selectie: Schakel specifieke wijzigingen in of uit (zoals een enkele kolomtoevoeging of een nieuwe index) zonder de hele branch te mergen.
• Groepsacties: Selecteer of deselecteer snel alle wijzigingen gerelateerd aan een specifieke tabel of view.
• Bescherming tegen breaking wijzigingen: Destructieve bewerkingen (zoals het verwijderen van een kolom) zijn standaard niet vooraf geselecteerd. Je moet expliciet kiezen voor deze wijzigingen om per ongeluk gegevensverlies te voorkomen.

---

Migratiegeschiedenis

Elke merge-bewerking wordt vastgelegd in een gecentraliseerd audittrail. De Geschiedenis-pagina voor een omgeving toont:

• Auditlog: Wie de merge heeft gestart, welke omgevingen betrokken waren en wanneer het plaatsvond.
• Wijzigingssamenvatting: Een duidelijk overzicht van wat is aangemaakt, gewijzigd of verwijderd.
• Traceerbaarheid: Documentatie van de specifieke SQL-opdrachten die tijdens de migratie zijn uitgevoerd.
• Backup-link: Directe toegang tot de automatische backup die specifiek voor die migratie is aangemaakt.

---

Rollback-beleid

Als je een merge moet terugdraaien, gebruik je de Backups-pagina om de omgeving te herstellen naar de “Pre-merge”-staat.

Let op: In tegenstelling tot een eenvoudige undo, herstelt een restore-bewerking de hele database naar een eerder tijdstip. We raden aan om wijzigingen te verifiëren in een staging-omgeving voordat je merge naar productie.

---

Developer API (GraphQL)

Mutation: mergeEnvironments

mutation MergeEnvironments($input: MergeEnvironmentInput!) {
  mergeEnvironments(input: $input) {
    success
    message
    migrationId
    changesApplied
    backupId
  }
}

Query: migrationHistory

query MigrationHistory($projectId: ID!, $environment: String) {
  migrationHistory(projectId: $projectId, environment: $environment) {
    id
    sourceEnvironment
    targetEnvironment
    status
    appliedBy
    appliedAt
    changes {
      changeType
      objectName
      sql
      isBreaking
    }
    backupId
  }
}