Changes
A Change is the atomic, versioned, self-contained unit of change in Flamingock. It encapsulates logic to evolve target systems safely, deterministically, and with complete auditability.
Key characteristics
- Atomic execution: Each Change runs exactly once
- Ordered sequence: Executed based on their
order
property - Auditable: Recorded in the audit store to prevent duplicate execution
- Safe by default: If Flamingock is uncertain about a change's outcome, it stops and requires manual intervention
- Rollback capable: Can be undone through rollback methods
What Changes can do
Changes enable you to version and track changes across your entire technology stack:
- Message queue operations: Topic creation, schema registry updates
- Object storage: Bucket setup, file migrations, policy updates
- Database migrations: Schema changes, data transformations, index creation
- External API integrations: Service configurations, webhook setups
- Infrastructure changes: Feature flag updates, configuration changes
Types of Changes
- Template based
- Code based
Written in Java, Kotlin, or Groovy with annotations. Best for complex logic or when you need full programmatic control.
@TargetSystem("user-database")
@Change(id = "add-user-status", author = "dev-team")
public class _0001__AddUserStatus {
@Apply
public void apply(MongoDatabase database) {
// Your change logic here
}
@Rollback
public void rollback(MongoDatabase database) {
// Your rollback logic here
}
}
Use YAML or JSON definitions with reusable templates. Perfect for repetitive operations and standardized patterns.
# File: _0002__AddStatusColumn.yaml
id: add_status_column
author: "db-team"
templateName: sql-template
apply: "ALTER TABLE orders ADD COLUMN status VARCHAR(20);"
rollback: "ALTER TABLE orders DROP COLUMN status;"
Safety and recovery
While Change executions typically complete successfully, Flamingock provides configurable recovery strategies to handle any exceptional circumstances that may arise. If results are uncertain, Flamingock stops and requires manual intervention rather than risking data corruption, ensuring you always know the exact state of your systems.
You can configure different recovery strategies based on your requirements. For complete details on failure handling and recovery workflows, see Safety and Recovery.
Next steps
Dive deeper into specific aspects of Changes:
- Anatomy & Structure - Learn the technical structure, required properties, and annotations
- Types & Implementation - Understand code-based vs template-based approaches
- Best Practices - Follow proven patterns for reliable Changes
Or continue to other key concepts:
- Target Systems - Configure where your changes will be applied
- Templates - Explore reusable change patterns