We deploy many applications on any given day.

We didn’t used to though. In 2015, when Plastiq first moved from Boston to San Francisco, we had a 2-week development cycle followed by a 3- or 4-day feature testing and regression testing cycle that would culminate in a dreaded Thursday night release. It wasn’t a great development environment and we made it a priority to improve.

We automated application builds, enabled working unit tests, and created a simple end-to-end automated regression suite. We next automated our deployments to an integration environment. Today, we’ve completely disabled our QA environment and consolidated all of our non-production environments (our integration environment is our QA and staging environment all in one!).

At Plastiq, we also use the Trunk Based Development model which means that we commit directly to the master branch. Builds and deployment are automatic and then unit, api and end to end tests are run. We are now moving toward continuous deployment so that our commits to master will be automatically deployed to production.

You can learn more about where we started and where we’re headed here.

We believe in delivering updates to our users as soon as they are ready.

Stitch Fix has long practiced continuous deployment. Any build on the master branch that passes its tests (which usually takes <10 minutes) is then followed by a one-step deployment script. This has worked successfully for years because of the quality of our automated tests, which we rely on heavily. Some teams deploy a few times a week while other deploy several times a day. Despite differences between various engineering teams and projects, there is a shared effort to make smaller, more incremental changes at Stitch Fix.

“Software only becomes valuable when you ship it to customers.” - Darragh Curran, VP of Engineering

We ship simple, early and often, and iterate rapidly. It’s not uncommon for us to release our core software 150 times per working day. An Engineer can get their latest PR into the hands of all of our customers in 30 minutes. We recognise that this release process is the pulse of a growing organisation, and realise that software only has value when it’s in the hands of our customers. To support this we have multiple stages of integration tests and also a bunch of tools that allow us to flip features on and off in production in various ways. We’ve also got a bunch of ways of getting in-production feedback and a really tight process for managing and learning from the in-production mistakes we will inevitably make while moving this fast.

We like to keep the wheels turning.

We believe in continuous delivery and deployment so that we can address the most pressing user needs and get rapid feedback on our work. We release often (multiple times a day) in incremental changes to our production environments. We also value test-driven development, and this gives us the confidence to release on such a frequent cycle. We use GitHub to manage our code, Buildkite to deploy our code, and our comprehensive test suite runs in a few minutes.

We are continuously deploying to production from our master branch.

Code is deployed via pull requests, once another engineer has reviewed the work and builds are passing (build is currently ~8min). We use Github for all issue tracking and code reviews. In the last month, we have deployed to production 150 times (deployment is zero-downtime and currently ~10min).

We work using a GitFlow-like process.

Stories are worked on in branches, and then merged to master when they are ready. Our test suite then runs, including mobile tests. If everything is green, we deploy both the server and mobile apps so we can accept and test our work. This all happens automatically.

We use tools like Heroku, CircleCI, and CodePush to manage our operations. We write our tests with tools like rspec, jasmine, and selenium. Being an international company, we’ve also integrated a translation process (both automated and with human review) into our deployment process.

We deploy to production about twice a week, but that’s a choice by our PMs as to when a feature is ready. Just because we work at Airbus, that doesn’t mean that we can’t use modern software practices and tools!

We ship our product multiple times a day.

We are breaking down problems into smaller ones which are easier to solve and test. Not only are these more manageable, but it reduces risk and makes it easier to roll back changes. As a result, we spend less time worrying about deploying and have more confidence each time we push code to production. Typically, features only stay in staging for a couple of hours before going to production. Engineers are responsible for taking their own code to production, so if it breaks, you’re also responsible for fixing it.

We like to move fast and innovate.

We have lots of different microservices and applications, and we’re constantly shipping new features. As soon as a PR is merged, tests are run and things are auto deployed to our infrastructure. Our DevOps team has built a great (and open source) layer on top of kubernetes that allows engineers to ship new services quickly and reliably with out-of-the-box logging, metrics, scaling, or load balancing. We like to work with our hands untied so we can make real impact, every day.

One of our core engineering principles is to minimize drift.

We mindfully decrease drift between our development branches and master, between production and master, andbetween what we are building and what our users are using. In order to do so, we practice continuous delivery. Master is automatically deployed to production, and new mobile builds are pushed to a limited distribution group on every commit.

We run tests on every branch via CircleCI and we have protected branches turned on in GitHub that require tests go green before merge to make sure every merge is a success. We also actively monitor our production environment using Bugsnag and other tools to fix bugs as close to immediately as possible.

We have a really cool deployment process. Hear us out.

We use Jenkins in a way that is deeply integrated with Jira and Bitbucket. We deploy to our non-production environments by simply changing the status of a ticket in Jira. From there, Jenkins gets the branch name from Jira and generates the build on the appropriate server. We do review pull requests before they go in product QA and from there QA can merge to release through a corresponding Jira status. Everyone loves this system!!

We push multiple times a day.

The things we focus on the most is data modeling and our API, so we have almost converged on our coding styles. We work on having a straightforward and repeatable deployment process so that we can write, test, and release code faster and more frequently.

On time. On target. Our word is bond.

A the end of the day it is all about execution. We strive to efficiently prioritize the features in our development pipeline and deploy as quickly as possible. The quicker we have a feature out - the quicker we can learn and improve to provide our users with functionality they really want.

Continuous Integration and Continuous Delivery are the cornerstones for building highly functional, scalable, and quality software.

Our current process at PAX is as follows:

• Engineers complete a task and submit a Pull Request on GitHub.
• The Pull Request is then code reviewed by a peer.
• Upon approval by the reviewer, the code is merged into the dev branch.
• CircleCI (our CI tool) then compiles the code and runs Unit Tests.
• If Unit Tests pass, then we run Integration Tests. If those pass, we run our QA Automation Tests.

This holds true for all development. We follow more Continuous Delivery on mobile (for obvious reasons) than on the backend/web side, which we manually push to the staging environment after tests pass, and then eventually to production. Our goal is to automate this process so that successful CircleCI builds, and tests initiate an automatic deploy to staging (this is real continuous deployment). Our secondary goal is to push code to production on a daily basis.

On the mobile side of software development, we do releases after every 2-week sprint, which means delivering updates to users on a bi-weekly cadence. Every two weeks, we push a new build. This creates a reliable system for our team and helps us guarantee we’re continually adding value for our users. We write really long roadmaps, so it requires us to hit all of the checkpoints along the way. A high level of trust is required since there are a lot of dependencies with software in order to continually deliver.

Tests are automatically run against pull requests, and required to pass before merge. They run in ~ 2 minutes.

Once your commit has been approved by another engineer, it is immediately deployed to production when you hit merge. Our services are deployed to ECS and will be gracefully auto-rolled back if they fail to start. We use a variety of tools (Cloudwatch, Sentry, Pingdom) for monitoring and alerting, and Terraform to manage our infrastructure as code. (These are manually applied first to a staging environment, then to our production environment.) We use experiment flags to ship new features to production early, and then develop and deploy incrementally until they’re ready to turn on for all of our customers.

We are constantly pushing to production.

Whenever a feature is ready and has been tested in our staging environment, we typically push it live asap. We have a modern CI/CD process that integrates CircleCI and AWS to get code out quickly. We make use of feature flags when needed in order to keep our deploys compact and small. New hires can expected to be shipping to production within their first couple weeks.