Continuous Delivery Made Easy
After graduating college I wound up with a job at a large bank. There I had a great history lesson on how software used to be developed. Huge requirements documents. Six month development windows. Saturdays spent trying to meet arbitrary requirements set forth my a committee. It was painful.
After the first week I sat down with a senior developer who was supposed to show me how to access the mainframe (this was 2011). He looked at me and said, “What are you even doing here? You should get out while you can.” I laughed and didn’t think anything of it for three years. For those three years I suffered through some pretty rough times including some major health issues but just thought of what I did as just a four letter word: W-O-R-K. It wasn’t fun but it was money.
What that job taught me was how not to do things. It was clunky. It was slow. It involved way too many people to get something simple done.
I then landed a job at my first startup. There it was like I was starting from square one. Nothing I had learned at the bank was applicable and the way work was done was very rapid but error prone. This was exciting. My first task was to get familiar with the code base by writing tests and minor bug fixes. When I went to look for examples I found none. My manager explained that they had been going so fast there wasn’t time to create any. He would then disappear for an hour once a day to walk over to the local University to use their WiFi to upload a new build. This was our deployment process…
As time went on I started teaching myself new things in technology. I read about why unit tests were important. How build and test pipelines could be structured and helpful. I led several initiatives to help streamline the process at my job to help reduce the strain on QA. What I found was one core book referenced by many blog posts and conference talks: Continuous Delivery by Jez Humble. In it you will find many theoretical applications and reasons to set up a process of automating the testing and deployment of your applications. In fact if you look around there are a ton of great books about how software should be written, tested, and deployed. But these books were all theoretical, it was up to you as the reader to piece together these different products and processes to make it work.
It was around this time that I started volunteering my time at a local startup. Again they didn’t have time to establish a pipeline and unit tests for their product and they were feeling the strain of a whack-a-mole style bug process and a single person managing deployments bottleneck. I suggested writing a pipeline to help and drafted a paper explaining the importance of the process. Here was my first writing on the subject and it was basically a light research paper on all of the books and articles I had read about the process. But I too fell victim to a theoretical dissertation instead of a practical guide.
When reading “The Phoenix Project” for the hundredth time I realized that this was what people were missing. A story. A story of how things can go so badly and how technology and process can save the day. I then became an disciple of the DevOps movement, baptized in the tears of broken deployments and raised to a level of enlightenment found in the Toyota Production System.
Then I found myself at yet another startup and explaining to younger developers the hows and whys to many of the deployment pipeline I had helped write. As I explained for the millionth time about the importance of testing and automation it occurred to me that these young developers hadn’t been taught what I had learned. That after reading their “Write a Hello World application in whatever cool new language you just learned” they didn’t know what to do next. Obviously someone would want to write an application and release it somehow. You can find tons of tutorials about writing serverless functions, releasing apps in Heroku, or using Docker in production. But there is no direction to when you should consider these things or how. No one explains that while shipping is great it won’t scale if you don’t have quality checks. That anything you do manually is error prone. The lack of direction bothered me. It also bothered me that people weren’t having the same revelations that I had.
The worst part was that various companies or groups I talked to said, “yeah this is great but we don’t have time to do what you are asking.” This comment never made sense to me. With most of my pet projects I was using some sort of CI/CD to release them so why couldn’t they find time to do it for their production code? My theory was that it wasn’t ingrained at the start. That no one decided to build the assembly line because they didn’t expect their app to grow, or their team to grow, or that they would not be disciplined enough.
I’m sure some of you have felt the same. I’m sure others of you could care less. But it was very important to me to tell others that this is simple. It’s not rocket science. And it’s important. So I do what anyone does when they have opinions… I created a website, that I don’t write on. While this site was supposed to be a collection of thoughts and musings about other things I never really wanted it to be a “Deploy and AWS Lambda in Go in 5 easy steps” but just random thoughts and projects I have had over the years. But this doesn’t do anyone any good. I have a journal for that crap anyway so what’s the point of this site?
Well the answer there was to put myself out there. But it really didn’t do me any good. So I decided to take it to the next level and write a book. So that’s what I’ve been doing for almost a year now. It’s showed me several things. First, it’s a lot of work getting stuff out of your head and on papers. Second, you need to be vulnerable. Third, you need to adjust.
This book is the book I wish I had five years ago. A mix of theory and practice. A defense of Continuous Delivery and a demonstration of its power. Currently it’s in early release which means it has a bunch of warts. One of those warts being that it is a little theory heavy at the moment as I work through the practical examples. But the end product is hopefully going to be the second book someone reaches for after they learn a new language. A book that shows you how to take your project and make it a product. To take a team of one to a team of many. To find the pleasure in writing a line of code, pushing it, and seeing it live within minutes.
If you are interested please consider buying a copy and receive a discount using code
mlholmes4 at this link.