Speaker & Podcaster

Tiny DevOps

Implementing Continuous Delivery in Reverse

Conventional wisdom tells us that an automated CI (Continuous Integration) pipeline is the necessary first piece to a CI/CD (Continuous Integration/Continuous Deployment) pipeline. Typical advice for adding CI/CD to an existing project goes something like this:
Write a bunch of automated tests.
Automate the running of your unit tests for every code change with a CI tool.
Find some way to instill responsibility and trust into every member of the team.
Finally automate the deployment process.
In this talk, I challenge the conventional wisdom, and offer my proven approach that skips steps 1-3, and explains how to do so responsibly and confidently.
The goal of this presentation is to inspire anyone who feels that modern CD is beyond their reach, by showing them a simpler, proven way to implement CD quickly. Rather than seeing CD as a far off, distant end goal, I intend to change the listener’s mindset to see this “Reverse CD” approach as a starting point to Continuous Improvement of software delivery.
I’ll go over the reasons why this reverse approach not only works, can also actually be more effective by freeing your team to work on what matters most from a business standpoint, rather than focusing on automation for its own sake.
I’ll explain the tactical steps to be taken to implement CD “in reverse”, from the Definition of Done, to build automation, and trunk-based development.
I’ll address the most difficult obstacle to overcome as well: The psychological barrier to automation, and how this can be addressed to the team and management with empathy.
I will also relate anecdotes from my experience implementing Reverse CD at various companies, ranging from a monolith to microservices, as well as single-person projects.
While the approach is tool agnostic, I’ll touch on some of the particulars of using a few common tools such as GitLab CI and GitHub actions.


Hi! I’m Jonathan Hall, and 15 years ago a disastrous multi-day technical failure sparked a life-long specialization in improving processes to avoid such needless pain.

Since then, I have worked with many teams on problems big and small, from the highly tactical, like improving coding practices, to the more strategic, like organizational restructuring. And what may be surprising to some is that in my experience, and without exception, my biggest successes have been on the smallest teams.

Much of the DevOps literature out there focuses on hyper-growth companies like Google, Netflix, and Uber, but it is my firm belief that with the right mindset, agile and DevOps principles can be at least as effective—nay, more so—on “tiny” teams.