SOP Template: Software Deployment for SaaS
Free software deployment SOP template for SaaS teams. CI/CD pipeline steps, feature flags, rollback procedures, and post-deploy monitoring.
Purpose
Define a repeatable, safe process for deploying code changes to production in a SaaS environment. This SOP covers the full deployment lifecycle: pre-deploy verification in staging, CI/CD pipeline execution via GitHub Actions, feature flag management with LaunchDarkly or equivalent, post-deploy monitoring, and rollback procedures. The goal is zero-downtime deployments with rapid rollback capability when things go wrong.
Scope
Covers all production deployments including feature releases, bug fixes, hotfixes, and infrastructure changes. Applies to all backend services, frontend applications, and database migrations. Does not cover development or staging environment deployments, which follow a separate lightweight process.
Prerequisites
- GitHub Actions CI/CD pipeline configured with build, test, and deploy stages
- Staging environment that mirrors production configuration
- Feature flag service (LaunchDarkly, Flagsmith, or equivalent) integrated with the application
- Monitoring dashboards in Datadog or Grafana with deployment markers enabled
- Rollback runbook documented for each service in Notion
- Linear or Jira board with a 'Ready to Deploy' column reviewed by engineering lead
- Slack channel #deployments configured with GitHub Actions notifications
Roles & Responsibilities
Deploying Engineer
- Verify all CI checks pass on the PR before merging to the deploy branch
- Confirm the change was tested in staging and approved by QA or a peer reviewer
- Trigger the production deployment via GitHub Actions and monitor the pipeline
- Watch monitoring dashboards for 30 minutes post-deploy and respond to anomalies
Engineering Lead
- Review the deploy queue in Linear and approve the deployment order
- Approve database migrations and infrastructure changes before they reach production
- Make the rollback decision if post-deploy metrics show degradation
- Enforce the deploy freeze calendar during high-risk periods
QA Engineer
- Run the staging verification checklist before giving deploy approval
- Execute smoke tests in production within 10 minutes of deployment
- Report any regression findings in the #deployments Slack channel immediately
Procedure
Before any production deployment, the deploying engineer confirms: the PR has been approved by at least one reviewer, all CI checks pass (unit tests, integration tests, linting, type checks), the change has been verified in the staging environment, and the Linear ticket is in the 'Ready to Deploy' column. If the change includes a database migration, the Engineering Lead must give explicit approval.
- aOpen the GitHub PR and verify: 1+ approvals, all CI checks green, no merge conflicts
- bConfirm staging verification: the QA engineer or a peer tested the feature in staging
- cCheck the Linear ticket status — must be 'Ready to Deploy'
- dIf database migration is included: get written approval from Engineering Lead in the PR comments
- eCheck the deploy freeze calendar — no deployments during freeze windows
Completion Checklist
Key Performance Indicators
Deployment frequency
At least 5 deploys per week per team
Deployment success rate (no rollback needed)
95% or higher
Mean time to rollback
Under 10 minutes from decision to completion
Change failure rate
Under 5% of deployments cause incidents
Lead time from merge to production
Under 30 minutes
Why This Matters for SaaS
Deployment is the most frequent high-risk activity in SaaS engineering. A team deploying 10 times a week has 520 opportunities per year for something to go wrong. Without a documented deployment process, each engineer deploys differently. One runs smoke tests, another doesn't. One monitors for 30 minutes, another closes the laptop and goes to lunch. The DORA metrics research is clear: teams with documented, automated deployment processes have 4x lower change failure rates and 24x faster recovery times. A deployment SOP turns a risky activity into a repeatable, measurable process.
Common Mistakes
- ×Deploying without canary validation and sending untested code to 100% of production traffic at once
- ×Skipping the post-deploy monitoring window — 'it deployed successfully' is not the same as 'it works correctly'
- ×Deploying database migrations and application code in the same deployment without verifying backward compatibility
- ×Not having a one-click rollback mechanism, forcing engineers to manually revert under pressure
- ×Deploying on Friday afternoon and discovering the regression Monday morning when customers have been affected all weekend
- ×Feature-flagging only new features but not risky refactors or performance changes
SaaS-Specific Notes
SaaS deployments must maintain SOC 2 compliance. This means: deployment access is restricted to authorized engineers (not every developer has production deploy permissions), all deployments are logged with who deployed what and when, and deployment approval is documented (the PR review). If your application handles payments, PCI DSS requires that production deployments go through a change management process with documented approval. Your GitHub Actions workflow logs serve as the audit trail — make sure they're retained for at least 12 months.
Frequently Asked Questions
Learn More About Software Deployment
For a deeper look at building onboarding documentation, see our complete guide.