Publishing

Deploy workflows, agents, and processors to environments with versioned releases and publish target configuration.

Overview

Publishing is the final step of the release pipeline, where versioned artifacts are deployed to target environments and made available for execution. M3 Forge provides:

• Publish targets - Configurable deployment destinations
• Atomic deployments - All-or-nothing releases to prevent partial states
• Publish history - Full audit trail of what was deployed when
• Rollback support - Quick recovery from problematic releases

Publishing integrates with the Release Pipeline to provide end-to-end deployment automation.

Publish Targets

Publish targets define where and how artifacts are deployed.

What is a Publish Target?

A publish target is a configuration that specifies:

• Environment - Which environment to deploy to (dev, staging, production)
• Gateway - Which Marie-AI gateway executes workflows
• Database - Where workflow definitions are stored
• Access controls - Who can publish to this target
• Deployment settings - Timeouts, concurrency, validation rules

Viewing Publish Targets

Navigate to Settings → Publish Targets to see all configured targets:

Creating a Publish Target

{
  "name": "Production US East",
  "environment": "production",
  "type": "manual_approval",
  "enabled": true
}

{
  "gateway_id": "gateway-us-east-1-prod",
  "gateway_url": "https://prod-gateway-us-east.example.com",
  "health_check_interval_seconds": 60
}

{
  "database_url": "postgresql://user:pass@prod-db.example.com:5432/m3studio",
  "schema": "production"
}

{
  "deployment": {
    "timeout_seconds": 600,
    "max_concurrent_deployments": 1,
    "require_backup": true,
    "run_smoke_tests": true
  }
}

{
  "access": {
    "allowed_roles": ["admin", "maintainer"],
    "require_approvals": 2,
    "approval_timeout_hours": 24,
    "allowed_approvers": ["alice", "bob", "carol"]
  }
}

Publishing a Release

Deploy a version to a publish target:

Publish Types

Different publish targets support different deployment workflows:

Auto-Deploy

Deployments start automatically when a new version is created:

{
  "type": "auto_deploy",
  "triggers": {
    "on_version_tag": true,
    "version_pattern": "v*.*.*",
    "branch": "main"
  }
}

Use case: Development environments where rapid iteration is needed.

Manual Approval

Deployments require explicit approval from designated reviewers:

{
  "type": "manual_approval",
  "approvals": {
    "min_approvals": 2,
    "allowed_approvers": ["alice", "bob", "carol"],
    "timeout_hours": 24,
    "auto_reject_on_timeout": true
  }
}

Use case: Staging and production environments requiring human oversight.

Scheduled

Deployments occur on a predefined schedule:

{
  "type": "scheduled",
  "schedule": {
    "cron": "0 2 * * 2",
    "timezone": "America/New_York",
    "deploy_latest_version": true
  }
}

Use case: Production deployments during maintenance windows (e.g., every Tuesday at 2 AM).

Emergency

Bypass normal gates for critical hotfixes:

{
  "type": "emergency",
  "emergency": {
    "require_justification": true,
    "allowed_roles": ["admin"],
    "audit_trail": true,
    "post_deploy_review": true
  }
}

Use case: Hotfix deployments during production outages.

Publish Process

The publish process executes these steps:

1. Pre-Publish Validation

Before starting deployment:

• Connectivity check - Verify gateway and database are reachable
• Version compatibility - Ensure version is compatible with target environment
• Resource check - Verify sufficient capacity for deployment
• Backup verification - Confirm backup storage is available

If any check fails, deployment is aborted.

2. Quality Gates

Run automated quality checks:

• Workflow validation - DAGs are valid, no cycles
• Security scan - No secrets or vulnerabilities
• Integration tests - End-to-end smoke tests
• Performance tests - Latency and throughput benchmarks

See Release Gates for details.

3. Approval

If required, wait for manual approvals:

• Notification - Send approval requests to designated reviewers
• Review period - Wait for minimum approvals (or timeout)
• Decision - Proceed if approved, abort if rejected

4. Backup

Create backup of current environment state:

• Snapshot workflows - Export current DAG definitions
• Snapshot agents - Export current agent configs
• Snapshot metadata - Save version info and timestamps
• Store backup - Upload to S3 with retention policy

Backups enable quick rollback if deployment fails.

5. Deploy Artifacts

Update target environment:

• Upload workflows - Insert/update DAG definitions in database
• Upload agents - Insert/update agent configurations
• Upload processors - Deploy custom node implementations
• Update metadata - Mark new version as active

Deployment is atomic - either all artifacts are deployed or none are.

6. Activation

Make new version active for execution:

• Switch active version - Update version pointer in database
• Invalidate caches - Clear workflow definition caches
• Restart services (if needed) - Reload configurations
• Route traffic - Direct new executions to new version

7. Post-Publish Verification

Verify deployment succeeded:

• Smoke tests - Execute test workflows end-to-end
• Health checks - Ping gateway and database
• Metric baseline - Record initial metrics for comparison

If verification fails, automatic rollback is triggered.

8. Notification

Notify stakeholders of deployment:

• Slack - Post to deployment channel
• Email - Send to team distribution list
• PagerDuty - Create deployment event
• Webhook - Call custom notification endpoints

Publish History

View all past deployments in the publish history:

History Table

Publish Details

Click any publish to see full details:

Metadata:

• Version: v1.3.0
• Target: Production US East
• Status: Succeeded
• Started: 2024-03-19 14:23:15 UTC
• Completed: 2024-03-19 14:27:00 UTC
• Duration: 3m 45s
• Deployed by: alice

Changes:

• 2 workflows updated
• 1 agent created
• 0 processors deleted

Quality Gates:

• ✓ Validation (3s)
• ✓ Security scan (45s)
• ✓ Integration tests (2m 15s)

Approvals:

• ✓ alice approved (1 hour before deploy)
• ✓ bob approved (30 min before deploy)

Logs:

[2024-03-19 14:23:15] Starting deployment of v1.3.0 to Production US East
[2024-03-19 14:23:16] Running pre-publish validation...
[2024-03-19 14:23:20] ✓ All validations passed
[2024-03-19 14:23:21] Creating backup...
[2024-03-19 14:23:45] ✓ Backup created: backup-prod-20240319-142345
[2024-03-19 14:23:46] Deploying artifacts...
[2024-03-19 14:25:12] ✓ All artifacts deployed
[2024-03-19 14:25:13] Activating new version...
[2024-03-19 14:25:30] ✓ Version v1.3.0 is now active
[2024-03-19 14:25:31] Running post-deploy verification...
[2024-03-19 14:27:00] ✓ All smoke tests passed
[2024-03-19 14:27:00] Deployment succeeded

Rollback

If a publish causes issues, rollback to the previous version:

Rollback Process

Rollback Execution

Rollback performs these steps:

1. Deactivate current version - Stop routing new executions
2. Restore from backup - Load previous workflow definitions
3. Activate previous version - Route executions to previous version
4. Run smoke tests - Verify rollback succeeded
5. Notify team - Alert of rollback and reason

Rollback typically completes in under 2 minutes.

Multi-Region Publishing

Deploy to multiple geographic regions:

Region Targets

Create publish targets for each region:

{
  "targets": [
    {
      "name": "Production US East",
      "region": "us-east-1",
      "gateway_url": "https://prod-gateway-us-east.example.com"
    },
    {
      "name": "Production EU West",
      "region": "eu-west-1",
      "gateway_url": "https://prod-gateway-eu-west.example.com"
    },
    {
      "name": "Production AP Southeast",
      "region": "ap-southeast-1",
      "gateway_url": "https://prod-gateway-ap-se.example.com"
    }
  ]
}

Coordinated Rollout

Deploy to all regions in sequence:

This staged rollout minimizes blast radius if issues occur.

Blue-Green Deployment

Run two versions simultaneously for zero-downtime deploys:

{
  "deployment_strategy": "blue_green",
  "blue_green": {
    "switch_after_seconds": 300,
    "traffic_split": {
      "blue": 50,
      "green": 50
    },
    "rollback_on_error_rate": 5.0
  }
}

• Blue - Current version
• Green - New version
• Traffic split 50/50 for 5 minutes
• If error rate > 5%, automatic rollback to blue

Publish Metrics

Track publish performance:

View metrics in Monitoring → Publish Metrics.

Best Practices

Test Before Production

Always publish to staging before production:

1. Publish v1.3.0 to staging
2. Run full regression test suite
3. Monitor for 1 hour
4. If stable, publish to production

Gradual Rollout

For high-risk changes:

• Deploy to 10% of traffic
• Monitor error rates and latency
• If healthy, increase to 50%
• If still healthy, increase to 100%

Publish Windows

Schedule production publishes during low-traffic periods:

• Avoid peak hours - Don’t publish during business hours
• Use maintenance windows - Tuesday 2-4 AM
• Notify users - Warn of potential brief disruption

Automated Testing

Run comprehensive tests before publishing:

• Unit tests (100% pass required)
• Integration tests (95% pass required)
• Performance tests (latency < threshold)
• Security scans (no critical issues)

Communication

Keep team informed of publishes:

• Pre-publish - Announce planned publish time
• During publish - Share real-time status updates
• Post-publish - Confirm success and monitoring plan

Troubleshooting

Publish Stuck in “Deploying”

If publish hangs:

Publish Failed

If publish fails:

1. Review error logs - Identify failure cause
2. Check quality gates - See which gate failed
3. Fix issue - Address root cause
4. Retry publish - Deploy again after fix

Rollback Failed

If rollback fails:

1. Check backup availability - Verify backup exists
2. Manual restore - Restore from backup manually if needed
3. Contact support - Escalate to platform team

Next Steps

• Configure Publish Targets in Settings
• Set up Release Gates to enforce quality
• Monitor publish health in Monitoring
• Learn about Environments for multi-stage deployment