3 ms·
For context, we have a different AWS account for each environment (production, staging, etc.) and have as much parity as possible between them (although resourc
by dmlittle 8y ago
For context, we have a different AWS account for each environment (production, staging, etc.) and have as much parity as possible between them (although resource sizes might vary - for example different RDS instance sizes for staging vs. production). All of our services run on AWS ECS and CI is done through CircleCI.
Our deployments start with a Github PR needing to have 2 approvals from peers and have all CI checks pass. Once the PR has been approved it can be merged into master which will trigger CI workflows again with the additional step of deploying the changes to staging and building a new release for production. The author of the changes can then verify they work as expected and promote the release in production or rollback their changes if things aren't working.
All of our AWS resources are created and tracked through Terraform but services are created through Convox[1]. We use Convox to create "releases" (ECS task definitions), manage their lifecycle (creation, promotion, releases, rollbacks, etc.) and it's CLI is pretty convenient (promoting a new release is as simple as running `convox releases promote <ID>`). That being said we've had some shortcomings with it and have outgrown it's flexibility. We'll be starting our migration into k8s early next year but it's worked great for us for the past 2 years.
[1] https://convox.com https://convox.com