Learn how John Bachir from Healthie leveraged Shipyard’s ephemeral environments to achieve a 50% velocity boost and attain consistent development output
Healthie uses Shipyard to increase reliability and velocity in their engineering process
Healthie is a comprehensive software that serves as the underlying infrastructure for digital health organizations of all sizes who seek to offer best-in-class, customizable experiences and to scale a provider network for longitudinal care delivery.
We spoke with John Bachir, Director of Engineering at Healthie, to learn more about how Shipyard has helped their organization increase reliability and velocity in the development process, across web and mobile teams.
“Before Shipyard, our deployment cadence was inconsistent, with some weeks seeing higher volume than others, but the delivery was very spiky. With Shipyard, we’ve consistently seen an increase in the reliability and predictability of our product delivery, which leads to happier customers and more success for our company”
The Challenge
Healthie’s engineering organization is made up of full-stack engineers, mobile engineers, QA, and product. The team manages work using a digital Kanban board representing each phase of the development process: code is written by engineers, reviewed and tested by QA, and finally signed off on by product.
“In the dark days before Shipyard, we did bundled releases, meaning we bundled up multiple new code changes and features into a single release and that would get tested together. These features and bug fixes would need to be manually deployed to one of a few staging servers, and we had to keep track of what was where. Every time there was an update, we had to push up new changes to the proper staging server.”
Deciding what went into each bundle on which staging server was a manual process. “This caused a ton of overhead for releases. Velocity was slowing down. As we grew, we became more efficient as a team: we produced more designs, more product specs… Ultimately, our release process couldn’t keep up with our team’s velocity.”
The Solution
At first, John looked into adding more staging servers as a way to unblock new features faster, but quickly hit a world of diminishing returns as each staging server needed its own setup, management, and oversight. He was looking into building a solution himself when he came across Shipyard. He cited his primary fear of using something like Heroku as having to rethink much of what they’ve set up with their current hosting provider and adapt it to a new world where concepts don’t necessarily map to each other.
“Implementing Shipyard turned out to be simple: we use Docker in production and Shipyard uses Docker. I didn’t have to translate concepts between staging and production: a simple Docker Compose file got us up and running in less than 100 lines of yaml and changing or adding a new service takes less than an hour and max 10 lines of code.”
Results
Today, Healthie has a more predictable and reliable release cadence than ever before, shipping on average over 50% more features than before they adopted Shipyard.
“Before Shipyard, our deployment cadence was inconsistent, with some weeks seeing higher volume than others, but the delivery was very spiky. With Shipyard, we’ve consistently seen an increase in the reliability and predictability of our product delivery, which leads to happier customers and more success for our company.”
Prior to Shipyard, John and the team maintained eight staging servers, all of which are no longer needed. Each pull request having its own environment allows for asynchronous collaboration and allows QA and developers to directly work together in an isolated fashion.
“For any team that finds itself with more than one or two staging environments, stop what you’re doing. Stop making manual staging environments -- don’t create more weight for yourself because it’s simply not scalable. Just use Shipyard.”
Hear about the latest and greatest in cloud native, container orchestration, DevOps, and more when you sign up for our monthly newsletter.
