Ordering Actions

The order of actions in a sequence determines execution flow. Proper ordering is critical for successful deployments.

How Ordering Works

Actions execute sequentially from first to last:

Each step must complete successfully before the next begins.

Order Index

Internally, steps have a 0-based order index:

Display	Internal Index	Action
Step 1	0	health-check
Step 2	1	stop-service
Step 3	2	deploy-files
Step 4	3	start-service

Note

The UI shows 1-based numbering for clarity, but the internal index is 0-based.

Reordering Steps

In the UI

Sequence versions are immutable, so there is no standalone editor for reordering an existing version. To set or change action order, open the sequence detail page and click New Version From This on an existing version (or Add Version for a new one). Inside the modal, each action row has ↑/↓ buttons:

• Click ↑ to move the action one position earlier
• Click ↓ to move the action one position later

The numbered badge on each row updates as you reorder; submitting creates a new version with the new order.

Effects of Reordering

When you reorder:

1. All order indices are recalculated
2. Execution sequence changes
3. A new sequence version should be created

Ordering Strategies

Dependency-Based Ordering

Order based on what each step requires:

Risk-Based Ordering

Put low-risk, reversible steps first:

Order	Action	Risk Level	Reversible
1	backup-database	Low	N/A (creates backup)
2	validate-schema	Low	Yes
3	apply-migrations	Medium	With backup
4	update-connections	High	Difficult

Pre/During/Post Pattern

Structure sequences in three phases:

PRE-DEPLOYMENT
├── 1. health-check
├── 2. create-backup
└── 3. notify-stakeholders

DEPLOYMENT
├── 4. stop-service
├── 5. deploy-files
├── 6. update-config
└── 7. start-service

POST-DEPLOYMENT
├── 8. verify-deployment
├── 9. run-smoke-tests
└── 10. notify-completion

Common Ordering Patterns

Service Update

1. pre-flight-check      # Verify target is ready
2. drain-connections     # Stop accepting new requests
3. wait-for-drain        # Let existing requests complete
4. stop-service          # Stop the service
5. deploy-files          # Update application files
6. start-service         # Start the service
7. health-check          # Verify service is healthy
8. restore-traffic       # Resume accepting requests

Database Migration

1. backup-database       # Safety net
2. stop-writes           # Prevent data changes during migration
3. run-migrations        # Apply schema changes
4. verify-schema         # Confirm changes applied
5. resume-writes         # Allow data changes again
6. update-app-servers    # Point apps to new schema

Blue-Green Deployment

1. deploy-to-inactive    # Update the inactive environment
2. verify-inactive       # Test the inactive environment
3. switch-traffic        # Route traffic to newly updated env
4. verify-active         # Confirm new active works
5. cleanup-old           # Clean up the now-inactive old env

Handling Failures

Fail-Fast Ordering

Put likely-to-fail steps early:

1. validate-config       # Fail early if config is invalid
2. check-permissions     # Fail early if no access
3. verify-connectivity   # Fail early if network issue
4. ... rest of deployment ...

Rollback Considerations

Order to enable rollback:

1. create-snapshot       # ALWAYS FIRST - enables rollback
2. ... deployment steps ...
3. verify-success        # Check if we need to rollback

If step 3 fails, you have a snapshot from step 1.

Order Visualization

The sequence detail page shows execution order:

┌─────────────────────────────────────────────────────────┐
│  Sequence: deploy-application v1.2.0                    │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  Execution Order:                                       │
│                                                         │
│  ┌───┐    ┌───┐    ┌───┐    ┌───┐    ┌───┐             │
│  │ 1 │ -> │ 2 │ -> │ 3 │ -> │ 4 │ -> │ 5 │             │
│  └───┘    └───┘    └───┘    └───┘    └───┘             │
│    │        │        │        │        │               │
│  check   backup   deploy   start   verify              │
│                                                         │
└─────────────────────────────────────────────────────────┘

Best Practices

1. Validate Before Modify

✓ 1. validate-target      # Check first
  2. modify-system        # Then change

2. Backup Before Change

✓ 1. create-backup        # Save state
  2. make-changes         # Then modify

3. Verify After Deploy

  1. deploy-application   # Make changes
✓ 2. health-check         # Then verify

4. Group Related Steps

Keep related operations together:

# Database operations together
1. backup-db
2. migrate-db
3. verify-db

# Application operations together
4. stop-app
5. deploy-app
6. start-app

5. Minimize Downtime Window

Order to reduce service unavailability:

1. prepare-deployment     # Pre-work while service runs
2. download-artifacts     # Get files ready
3. stop-service           # Brief downtime starts
4. swap-files             # Quick file swap
5. start-service          # Brief downtime ends
6. post-deployment        # Clean up while service runs

Troubleshooting

Steps Execute in Wrong Order

Symptom: Step 3 runs before Step 2

Cause: Order indices may be duplicated or incorrect in the version

Solution: Sequence versions are immutable. To fix action ordering, click New Version From This on the existing version, reorder the actions using the ↑/↓ buttons in the modal, and submit to create a new version with the corrected order.

Step Depends on Previous Output

Symptom: Step fails because previous step’s output isn’t available

Solution: Use environment variables or files to pass data between steps:

# Step 1: Save value
echo "$VERSION" > /tmp/deploy-version

# Step 2: Read value
VERSION=$(cat /tmp/deploy-version)

Reordering Not Saving

Symptom: Changes to order don’t persist

Solution: Sequence versions are always immutable — there is no Save button for reordering steps in an existing version. To change action order, open the version using New Version From This, reorder the actions with the ↑/↓ buttons in the modal, and submit to create a new version with the updated order.

Next Steps

• Versioning - Version management
• Creating Sequences - Creating new sequences
• Overview - Return to sequences overview