Change Analysis Process
Overmind's change analysis follows a structured timeline that transforms your Terraform plan into actionable insights. Understanding this process helps teams know what to expect and when during their deployment workflow.
How Change Analysis Works
When you run overmind terraform plan
, Overmind initiates a multi-step analysis process that examines your proposed changes through several lenses. Each step builds on the previous one, creating an understanding of your change's potential impact.
The analysis follows this sequence:
1. Change Created
The process begins when Overmind receives your Terraform plan. At this stage, the system:
- Records the author and timestamp
- Parses the Terraform plan output
- Strips sensitive data while preserving change information
- Initializes tracking for the analysis pipeline
2. Mapped Resources
Overmind maps planned changes to actual infrastructure resources. During this step:
- Resource Identification: Each Terraform resource in your plan is matched to its corresponding cloud resource
- Supported Types: Resources with known mappings are processed for dependency analysis
- Unsupported Types: Resources without mappings are noted but skipped (like
google_container_cluster.primary
orhelm_release.nats
) - Success Tracking: Successfully mapped resources are counted and listed
Example mapped resources might include:
- Application deployments (
api-server
,frontend
,gateway
) - Database instances
- Load balancers
- Security groups
3. Calculated Blast Radius
With mapped resources identified, Overmind calculates the blast radius:
- Dependency Discovery: Uses real-time API calls to discover relationships between resources
- Cross-Service Mapping: Identifies connections across different AWS services and accounts
- Impact Scope: Determines which resources might be affected by your changes
- Metrics: Reports the total number of items and edges (connections) in the blast radius
The blast radius includes both direct dependencies (resources you're changing) and indirect ones (resources that depend on what you're changing).
4. Calculated Risks
Using the blast radius data, Overmind performs risk analysis:
- Pattern Recognition: Compares your change against known risky patterns
- Dependency Analysis: Evaluates how changes might affect connected resources
- Risk Classification: Categorizes risks by severity (Low, Medium, High)
- Contextual Assessment: Considers factors like timing, resource criticality, and change complexity
Risk examples include:
- Network misconfigurations in cluster creation
- Security vulnerabilities from permission changes
- Resource quota issues
- Feature compatibility problems
5. Auto Tagging
Automated tagging applies organizational rules to categorize the change:
- Rule Application: Evaluates the change against configured tagging rules
- Value Assignment: Assigns tags based on rule logic and valid values
- Compliance Tracking: Ensures changes align with organizational policies
For example, a rule might automatically tag all changes to production resources with env: prod
.
6. Change Started
When you proceed with terraform apply
, this milestone marks:
- The beginning of actual infrastructure modifications
- A snapshot of the current state for comparison
- Activation of change monitoring
7. Change Finished
Upon completion of the apply process:
- Records the end time of infrastructure changes
- Triggers post-change validation
- Enables before/after comparison
8. Change Validation
The final step verifies that changes were applied correctly:
- Resource Verification: Checks that resources match expected configurations
- Image Validation: For container deployments, verifies correct image hashes
- State Confirmation: Ensures the actual infrastructure state matches the intended changes
Validation examples include:
- Confirming deployment images match expected versions
- Verifying network configurations are correct
- Checking that scaling operations completed successfully
Timeline Characteristics
The change analysis timeline has several important characteristics:
- Sequential Processing: Each step builds on the previous one's output
- Flexible Timing: Steps may take varying amounts of time based on infrastructure complexity
- Partial Success: Some steps can succeed even if others encounter issues
Status Tracking
Each step in the timeline tracks:
- Start Time: When the step began processing
- Duration: How long the step took to complete
- Status: Success, failure, or partial completion
- Output: Results, errors, or relevant data from the step