Modernizing Development with Continuous Shipping
Ahoy there. Continuous shipping: a concept many companies talk about but never get around to implementing. Ever wonder why that is? In the first post of this three-part series, we’ll go over(board) the concept of continuous shipping and why it’s valuable. Parts two and three will deep-dive into the process implementation. Buckle that life jacket; it’s time to set sail.
Release cycles are adopted early in a company’s life. Although they might be altered slightly over time, they often remain the same as updates are released. A company might spend 12 months on development of an update in addition to between three and six months on QA and other manual processes. Many larger companies have teams dedicated entirely to testing every single piece of this process.
Longer release cycles are reasonably well-tested and stable processes. While there are many reasons to structure the release process in this way, the primary motive is stability and predictability. Both of these come at a cost: the ability to react to feedback is slow, and predictability can be cancelled out by the complexity of needed patch releases.
Probably the most enduring benefit of a lengthy release cycle is the opportunity to cause a big splash by unveiling something press-worthy that will make an impression on customers. However, when we look at the evolution of technology over time, we’re currently headed in a new direction. Software startups are known for a shipping style that emphasizes rapid iteration. Although this is necessary for small teams that are limited on resources and use production releases to gather large amounts of data quickly, larger companies are now starting to adopt shorter release cycles to take advantage of benefits like market responsiveness, greater focus on innovation, and shorter issue resolution cycles.
To be blunt: the time has come to shorten the release cycle.
But why change a process that, flaws aside, still works? It’s worth thinking about the problem we’re trying to solve. Imagine a scenario where a change is released, and a customer complains via social media. In a larger company, the customer service team triages the issue, taking whatever troubleshooting steps are available. If the problem isn’t easily fixable, the customer service team escalates internally, typically flowing information circuitously between technical support, QA, product management, and the developer(s) who wrote the code. Typically, an update is shipped to production after a matter of days or weeks (fingers crossed that it’s actually fixed). Ideally, the customer also receives a resolution update.
Much like the 12-month release cycle, this is a long and complicated process that could benefit from streamlining. With the help of continuous shipping, companies can ship more software while minimizing mistakes and increasing developer productivity.
To be blunt: the time has come to shorten the release cycle.
Modernizing Development
With this shortened cycle, quick iteration is critical. Fundamentally, the adoption of continuous shipping modernizes development. By minimizing the component that’s changing, developers maintain high quality and stability.
Shortened release cycles bring a shift in risk culture. Specifically, teams need to accept the fact that they can minimize risk, but that risk is inherent.
Still, the importance of the big splash remains. After all, if you happen to be the proprietor of a fancy, new cargo ship, you’re certainly not going to pass up the opportunity to christen it with one of those showy champagne-smashing ceremonies, right? While shortened feedback cycles reduce the opportunities for large-scale launches, the need for making an impact on customers persists. Sure, big splashes may need to be planned more strategically in the context of rapid releases than in longer cycles, but the payoff is still obvious.
Shortened release cycles also bring a shift in risk culture. Specifically, teams will need to accept the fact that they can minimize risk, but that risk is inherent. Take Sentry: our core technology captures errors. Sentry doesn’t stop users from creating bugs, but we immediately tell developers about them. So, if iteration is part of the development workflow, a fix can be issued and an update shipped without a separate process, minimizing risk to customers. As you might imagine is the case with a shortened cycle, the key is to mitigate and react quickly. The quicker you are, the more benefit you’ll see.
Minimize Impact with Automation
How, exactly, do you ship a new update while reducing its impact? Automation and testing are crucial. In fact, it’s best to minimize human involvement altogether, which, as a bonus, offers an opportunity for scalability.
The above illustration should look familiar — it’s how we think about the workflow for any software development and operations team today. Changes to code go through a testing phase and then deployment. In reality, this phase might repeat. You might go through a testing phase, deploy it to 10% of the audience, and then go through another automated period that checks to see if it’s safe to send to the rest of your audience. Unfortunately, this is often a costly process, one that you probably only find at companies that have a lot of engineering time to invest.
From here, you’d go through an automation/monitoring/QA phase where uptime monitoring might come in to play. What you do with that information is up to you. The creation of a triage phase might be valuable, as it would allow the focus to be on fixing issues until success is reached and feedback is integrated.
Again, Sentry provides a great example of this workflow. If a customer signs up for Sentry and hits an error, the error is tracked in the system and — motivated by an internal SLA — addressed the same day. A fix is pushed as soon as the error is resolved. During the success phase, any customer who was affected by the issue is contacted, because Sentry tracks them all. However, this type of proactive communication doesn’t exist in companies who generally reactively respond to customer complaints.
Of course, this entire process is done in the name of minimizing mistakes, increasing productivity, and (hopefully) improving sentiment. Continuous shipping, despite its rigor, is a worthwhile venture for all teams, regardless of size.
Specifically, the process encompasses four key components:
Integration: merge changes frequently and verify through automation
Deployment: ship code as soon as it’s ready
Monitoring: know where things go wrong
Feedback: identify the needs and issues of your users
In the next two posts of this series, we’ll take a deep dive into how companies can implement these elements from the ground up. Until then, read about how we’ve been embracing continuous shipping here at Sentry since 2015 with Freight.
