Sequences

A Sequence is an ordered, versioned collection of Actions that defines a workflow for deployment operations. Sequences allow you to chain multiple actions together in a specific order.

What is a Sequence?

Sequences define the order in which actions execute. While actions are atomic units, sequences combine them into meaningful workflows:

Each sequence is:

• Ordered - Actions execute in a defined sequence
• Versioned - Like actions, sequences support semantic versioning
• Composable - Reuse existing actions across multiple sequences
• Flexible - Specify version requirements for action compatibility

Sequence Structure

Component	Description
Name	Descriptive identifier (e.g., “Deploy Web Application”)
Version	Semantic version number
Steps	Ordered list of action references with version requirements

Step Ordering

Steps execute sequentially from lowest to highest order index:

Order	Action	Version Requirement	Description
0	health-check	^1.0.0	Verify target is healthy
1	stop-service	>=1.0.0	Gracefully stop the service
2	deploy-files	^2.0.0	Deploy new application files
3	start-service	>=1.0.0	Start the service
4	smoke-test	~1.2.0	Verify deployment succeeded

Note

Order indices are 0-based internally but displayed as 1-based (Step 1, Step 2, etc.) in the UI for clarity.

Version Requirements

Each action reference includes a version requirement using semver ranges:

Requirement	Meaning	Example Match
^1.0.0	Compatible with 1.x.x	1.0.0, 1.5.3, 1.9.9
>=2.0.0	2.0.0 or higher	2.0.0, 3.1.0, 10.0.0
~1.5.0	1.5.x only	1.5.0, 1.5.1, 1.5.99
=1.2.3	Exact version only	1.2.3
>=1.0.0,<2.0.0	Range	1.0.0 through 1.x.x

Version Resolution

When a sequence version is created, Mantis resolves each action’s version requirement to the highest matching version available at that moment and pins the exact action version. During deployment, Mantis uses these already-pinned versions directly — no further resolution occurs at deploy time.

This means two sequence versions created at different times may resolve the same version requirement to different action versions, depending on which action versions existed at creation time. To pick up a newer action version, create a new sequence version.

Relationship to Actions and Solutions

• Actions are atomic execution units
• Sequences combine actions into ordered workflows
• Solutions bundle sequences for complete deployment packages

Creating a Sequence

In the UI

1. Navigate to Sequences in the sidebar
2. Click New Sequence
3. Enter a name (e.g., “Deploy Backend Service”)
4. Specify the initial version (e.g., “1.0.0”)
5. Add action steps:
   • Click Add Action
   • Select an action from the dropdown
   • Specify the version requirement
   • Repeat for additional steps
6. Reorder steps using the up/down arrows
7. Click Save

Step Management

In the sequence editor, you can:

• Add Steps - Include additional actions
• Remove Steps - Delete unnecessary steps
• Reorder Steps - Use the up/down arrow buttons to change execution order

Versioning Sequences

Like actions, sequences use semantic versioning:

When to Create New Versions

Scenario	Version Change
Add a new step	Minor (1.0.0 -> 1.1.0)
Remove a step	Major (1.0.0 -> 2.0.0)
Reorder steps	Major (1.0.0 -> 2.0.0)
Update version requirement	Minor (1.0.0 -> 1.1.0)
Fix typo in step config	Patch (1.0.0 -> 1.0.1)

Immutability

Sequence versions are immutable once created. To modify a sequence:

1. Open the sequence detail page
2. Click Add Version
3. Configure the new version
4. Save

This ensures deployments are reproducible and auditable.

Best Practices

Design for Failure

Plan for steps that might fail:

1. Pre-flight checks - Validate prerequisites before making changes
2. Atomic operations - Each step should complete fully or not at all
3. Post-deployment verification - Include health checks after changes

Step Granularity

Balance between too many and too few steps:

Too Granular	Too Coarse
20 single-command steps	One monolithic script
Hard to maintain	Hard to debug
Slow execution	No visibility into progress

Aim for 5-10 logical steps that represent distinct phases of your deployment.

Naming Conventions

Use clear, workflow-oriented names:

Good	Bad
deploy-web-application	seq1
database-migration	db_deploy_v2_final
rollback-frontend	undo

Example Sequences

Web Application Deployment

Sequence: deploy-web-app (v1.0.0)
+-- Step 1: pre-flight-checks (^1.0.0)
+-- Step 2: backup-database (^2.0.0)
+-- Step 3: run-migrations (^1.5.0)
+-- Step 4: deploy-static-assets (^1.0.0)
+-- Step 5: deploy-application (^3.0.0)
+-- Step 6: warm-up-caches (^1.0.0)
+-- Step 7: health-check (^1.0.0)

Database Migration

Sequence: database-migration (v2.1.0)
+-- Step 1: backup-database (^2.0.0)
+-- Step 2: validate-migration-scripts (^1.0.0)
+-- Step 3: apply-migrations (^1.0.0)
+-- Step 4: verify-schema (^1.0.0)
+-- Step 5: update-connection-pools (^1.0.0)

Next Steps

• Creating Sequences - Step-by-step creation guide
• Ordering Actions - Managing step order
• Versioning - Version management strategies