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.

We don’t have a release cycle, we have a deploy button.

At Wealthfront, we don’t have a QA team by design. Instead, we rely heavily on engineers to own their code’s quality throughout the software development process by investing heavily in multiple levels of automated testing, monitoring, and reporting. We’ve been working in a CI/CD environment since before it became common and our approach to continuous delivery is a core part of our product development process. We actively use A/B tests and feature flags to get code safely into production quickly and often. Don’t believe us? See when we last pushed to production here!

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 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 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.

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 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!!

One of our core engineering principles is to minimize drift.

We mindfully decrease drift between our development branches and master, between production and master, and between 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.

Once your code is reviewed, it can be in production in under 30 minutes.

Simplifying everything is at the core of Meraki. Networking is complicated and we’re making it easier, faster, and smarter so businesses run more smoothly, and more people have reliable access to the information they need.

Engineers simplify complex problems to make it easy for people to work with us and to work with each other. Our team cares deeply about providing the best possible experience for our customers. We work tirelessly to keep customer networks online, fast, and secure. That’s why we’ve built a platform that allows us to be nimble and work quickly to get new features and fixes to customers as soon as they are ready. Engineers own projects start to finish, from vague idea to sleek, production-ready feature. Iteration cycles are short; once your code is reviewed, it can be in production in under 30 minutes. We ship to production dozens of times per day, and let as little as possible stand in the way of rapid, iterative improvement.

Meraki engineers lead an Intro to React workshop in partnership with our ERO Connected Asian Affinity Network (CAAN) at our office in San Francisco.

We push multiple times a day.

The things we focus on the most are 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.

We strive for a culture of continuous learning.

One of our core engineering principles is “Ship Fast” and we build in small batches and deliver often. Changes are made in individual branches with continuous integration pipelines. New features can be controlled via feature flags and our deployment process allows us to push code at any time. Ownership of code is end-to-end, so individual developers are pushing code to production themselves and can do so at any time of day.

We are constantly thinking of ways to make it safer to push new code. We depend on feature flagging to push features rapidly and with confidence, and are continually revising our end-to-end testing to balance coverage without the need to rewrite tests with each push. We’ll also borrow inspiration from other monitoring tools (like PagerDuty) to build features for Amplitude.

On time. On target. Our word is bond.

We work on sprints primarily around planning, but we push to production every day. 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 start iterating to provide our users with the functionality they really want. That’s not to say we’re not pragmatic! We take test coverage seriously. Hundreds of thousands of end users depend on our app, so if a bug happens during checkout, we’re losing people real business.

Still, we’re not fearful about deploying (and deploying quickly) because we trust our deployment process. Abe and Andy are always on-call and everyone else on the engineering team is on a weekly rotation. If you’re on-call, you’ll cycle in to help with our error alert feed. This helps expose everyone to different parts of the codebase, yet everyone has support should they need help figuring out an issue.

Labelbox has an automated pipeline that allows us to deploy multiple times per week (or per day).

We use Codefresh so our tests and deployments take less than 10 minutes. One reason this is such an advantage is because continuous delivery allows us to test what works. To us, continuous delivery is saying, “I don’t know all the answers, and I need to capture it through experiments and iteration,” and asking, “Does this work?” over and over again. We’re also confident every time we roll out changes or new features because we use LaunchDarkly for feature flagging.

Shipping often leads to better products.

We’ve set up our workflow to allow for a continuous delivery process. From the point of opening a pull request, our code runs through a test suite in CircleCI with parallelism and our build pipelines to generate a review app for stakeholders to review and test. When the PR flows from code review to merge into master, it is then deployed to Staging. From here, relevant members of the team QA the feature work before deploying to Production.

We leverage Github, CircleCI, CodeClimate, and Google Cloud Platform throughout this process to ensure we can ship quickly while still having high test coverage, writing quality code, and ensuring passing reviews. We also leverage feature flags regularly to keep to a continual delivery and ensure high quality standards.

STORD is growing quickly, for an up-to-date list of our openings, checkout out our careers page!

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’ve leveraged continuous integration and delivery practices since 2012!

All of our engineering teams and codebases enjoy automated testing suites and delivery pipelines to development, staging, and production environments. Automated testing tools range from Selenium for end-to-end testing of branches and features to unit testing of algorithms and particular coding strategies. We ship early and often, and make thorough use of feature flags, beta groups, and customer interviews on newly released software. Product managers and their teams will then gather both survey and interview feedback from beta experiences to further refine experiences prior to general release.