Continuous integration and delivery platform
Distributed across the US, Canada, Ireland, UK, Germany, Japan
CircleCI is a modern continuous integration and continuous delivery (CI/CD) platform. So, naturally, we practice this ourselves. There are more than 1M+ users on the CircleCI platform, which processes 3M+ builds on a typical weekday. If you’re reading this, it’s very likely you’ve used CircleCI to automate build, test, and deployment of software before at a previous company. Customers like Samsung, Ford Motor Company, and Condé Nast International all rely on CircleCI to operate, and more than 22,000 organizations have integrated CircleCI orbs into 65,000 repositories and nearly 18 million CI/CD pipelines. 🙌
We dogfood our own product and deploy anywhere from 400 to 700 times every week. We have very little manual testing, but lots of automated unit tests, automated integration tests where feasible, and lots of canaries and A/B testing. In the last 12 months, we’ve released over 100 features in addition to dozens of technical investments in our platform and services. If you love CI/CD, there’s no better place to work!
18 Open Positions
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.
14 Open Positions
Automated financial management to save, plan, and invest all in one place
Palo Alto, CA or Remote (US)
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!
12 Open Positions
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.
10 Open Positions
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).
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.
52 Open Positions
We have a live test environment for every pull request and our latest “main” branch is always auto-deployed to our staging environment. We have one-click deployment to production and employ code reviews for every change, big or small. We invest into creating an excellent development and delivery experience to ensure users are constantly delighted with our progress (and so that we ourselves can enjoy working on our product!).
We have built a continuous integration system and strongly believe that our shipping velocity differentiates us from our peers. As an engineer, you can expect to push to production multiple times a day. We have a lightweight process to ship through the different stages of our pipeline and no explicit separate release is needed.
We also run a mature test suite on all code commits, which we monitor continuously with failures fixed within a certain SLA. Tests take minutes to run with an expectation that they should be fast, reliable, and not the long pole to pushing features.
Check out our changelog, which we recently introduced to detail features as they are rolled out. We keep a tight feedback loop with our users, and build all features with them in mind.
We invested heavily in automation from day one, so now all it takes to deploy is to approve and merge a GitHub pull request. Our staging environment is continuously updated every time anyone merges their branch to main, so our engineers can test their changes within 10 minutes against a full replica of our production environment.
Feature flags play a big role in helping us stay safe while moving fast. No matter how large a feature, we implement it in parts and wrap it in a flag so we can enable it just for ourselves and our friends in the product team. While our code never touches servers unless it has sufficient tests, uncovering unknowns in an environment where it's safe to make mistakes is what, at the end of the day, keeps our promises to our patients and users.
Researchers and clinicians from some of the leading neuro labs and hospitals in the country count on us to ensure their work helps everyone affected by brain disease. We've built Rune on the soundest principles of infrastructure and code management so we can bring them the data they need.
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. Millions 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 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.
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.
27 Open Positions
Seamlessly create, send, and track video emails
Colorado Springs, Denver, or Remote in CO, NY, PA, WI
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.
Part of our first sprint on every project is to push an MVP version of their product. We do this through multiple avenues, whether it’s using Netlify Deploy, GitHub Actions, or TravisCI. Our chosen method of delivery depends on the client team and their product, but we believe it’s the most important step for getting the feedback we need and streamlining our development process.
Truthfully, we’re still working on cleaning up mistakes from the past and transitioning to a new dashboard with good libraries, but we have clear goals toward continuous delivery. It’s far better to constantly iterate with small changes than it is to build something new. We always do code reviews (typically from someone furthest from the code), and try to release bug fixes and deploy new features into production safely and quickly.
We work hard to ship quickly as we (unsurprisingly) have so much to get to in our product roadmap! We invest in our processes, but also in our people. If any of the above interests you, we encourage you to reach out and apply!
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.
Want to List Your Company?
Submit a team profile!
Select 8 Values
Contact me (Lynne 👋)
Qualify Your Values
Reach Thousands of Devs
Find Value-Aligned Candidates
Have Meaningful Initial Conversations
Don't Fill Roles, Hire Teammates
You can post as many job openings as you want.