Scene 2 – continuous delivery – Using Python for CI/CD Pipelines
Scene 2 – continuous delivery
A while after I was pushed down the DevOps river by Doug, I found myself facing a roadblock. If it were a physical roadblock, I would have no problem given the 400 crunches and 649 (yes, exactly that much) pull-ups I did every day. But this roadblock existed in the realm of computers, and it had a toll booth that rejected any code that didn’t meet its requirements. Tired of the automatic rejection of my code, I decided to speak to the toll booth attendant, and lo and behold, I found that it was my old friend Doug.
Me: How’d you get here Doug?
Doug: I was always here.
Me: (Visibly confused) Okay… So, whenever I push my code, it updates the test version of the application?
Doug: That is correct, but only if your code passes testing and deploys successfully. Otherwise, it reverts to the older version of the project and tells you what went wrong.
Me: Okay, can’t you just take my word for it?
Doug: I’d love to, but the last time we did that, a zebra came flying out of the server room and started biting people. Zebras are mean.
Me: How did a Zebra…
Doug: That’s not the point. The point is that this system doesn’t just exist to launch stuff, alright? It’s there because it simplifies and secures things for everybody. Once a dev pushes the code, it’s over for them. If that code gives out an error, they resume work on it. DevOps people just exist to make that process as easy as possible.
Me: Alright, is that easy to set up?
Doug: Nope.
This is the part with a montage of me learning all of the testing and security principles and how to push code, create approval workflows, and a lot of other things that you’ve seen in this book. It’s not an easy journey by any means, but a rewarding one.
Me: Okay, that’s all right. Right?
Doug: Define all.
Me: (Sighs) Alright, what’s left?
Doug: Do more and you’ll learn more.
Thus, the journey continued in earnest, revealing even more questions each time. It was honestly pretty boring. But I soon realized that there was a reason for that…
Well, after the truth was revealed to me, I realized that this actually was the way. A way created through trial and error to find out what works and what doesn’t. A way based on real-life problems and their solutions. A more pragmatic way that brought order from chaos. But I also realized that there is such a thing as too much order (we call it bureaucracy if a government does it). There were a lot of necessary steps, but they generated a few unnecessary ones every time something was changed. The process needed to adapt to itself. An interesting concept. And it needed to do so while also delivering value. But to innovate, you must automate. And that is the story of continuous deployment.
