The Environment Merge feature allows you to apply schema changes from one environment (source) to another (target). This is the core operation that propagates structural changes — such as new tables, columns, views, and enums — across your development lifecycle.

---

How Merge Works

The merge process is designed to be safe, predictable, and transparent:

1. Selection: Select a source environment (where the changes originated) and a target environment (where you want to apply them).
2. Analysis: The system performs a diff to identify all missing changes in the target environment.
3. Review & Cherry-pick: Review the detected changes and selectively choose which ones to apply.
4. Automatic Backup: Before any changes are applied, Archie Core creates a full backup of the target environment’s data and structure.
5. Atomic Application: Selected changes are applied as a single operation. If any part of the merge fails, the entire operation is automatically rolled back.

---

Safety & Reliability

Archie Core guarantees the integrity of your production and staging environments during a merge:

• Transactional Updates: All schema changes are applied within a single transaction. This means either all selected changes are applied successfully, or none are — preventing your database from entering a partially-migrated state.
• Environment Locking: While a merge is in progress, the target environment is locked to prevent concurrent configuration changes.
• Automatic Pre-Merge Backups: A “safety net” backup is always created immediately before execution. If a merge succeeds but you discover an issue later, you can restore to the exact state before the merge using the Backups page.

---

Cherry-Pick Selection

The merge interface allows for granular control over what gets moved:

• Individual Selection: Toggle specific changes (like a single column addition or a new index) without merging the entire branch.
• Group Actions: Quickly select or deselect all changes related to a specific table or view.
• Breaking Change Protection: Destructive operations (like dropping a column) are not pre-selected by default. You must explicitly opt-in to these changes to prevent accidental data loss.

---

Migration History

Every merge operation is recorded in a centralized audit trail. The History page for an environment shows:

• Audit Log: Who initiated the merge, which environments were involved, and when it occurred.
• Change Summary: A clear breakdown of what was created, modified, or removed.
• Traceability: Documentation of the specific SQL commands executed during the migration.
• Backup Link: Direct access to the automatic backup created specifically for that migration.

---

Rollback Policy

If you need to revert a merge, you should use the Backups page to restore the environment to its “Pre-merge” state.

Note: Unlike a simple undo, a restore operation reverts the entire database to a previous point in time. We recommend verifying changes in a staging environment before merging into production.

---

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
  }
}