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

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.

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 ship fast and sustainably.

Shipping code is the most visible way that engineers contribute to the success of Asana, and doing so in a fast and sustainable way is key.

Shipping fast starts with serious investment in tooling, such as continuous deployment with multiple pushes per day. It also takes focus and flow, like the kind you can have during our “No Meeting Wednesdays.”

But shipping fast and sustainably takes more than just effective work. When we’re focused, we write higher-quality code, and this translates to less technical debt, faster iteration, and less time fighting fires. While lots of hours in the office lead to the illusion of a lot of work, it often results in just a lot of energy spent treading water.

This is a long-term investment against the pervasive misconception that shipping fast means working unsustainably. Software isn’t going anywhere, and Asana’s engineering culture aims to support people to work well for decades to come.

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.

We release several times a day, and you can have code live on the site in as little as 20 minutes.

We believe that speed is one of the attributes that sets an organization apart, and we strive to support our engineers in moving as fast as possible. We place a heavy emphasis on automated tooling so we can write quality code and have it live in production without worrying about lingering issues. Our tests and live deployment previews are automatically run and built on every push. This avoids the need to run all tests locally and saves you precious time on your local machine. Our CodeBuild pipeline verifies and builds your changes while Lerna enables you to deploy after your tests have passed.

We value not only code quality, but also speed. Tasks should take two hours, two days, or two weeks (and it’s never two weeks). This speed helps us remain nimble and fix previous issues quickly, so they don’t fester.

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.