Automation is worth the effort

Somewhere in the late 2000s, as a software developer, I would spend a lot of time in Microsoft Word.

When I was nearing completion of a software project, I would start to get the application ready for going into production.

I would start to write an implementation plan. This long, textual document (with outline numbering and track changes turned on) described, usually in great detail, how to deploy the software into test and production.

It usually consisted of steps like this: Create user account. Populate database. Add password to config file. Copy files to FTP server.

Every step had to be meticulously documented, because the team doing the deployment didn’t know anything about my code at all. They just saw a stream of shit heading their way on a daily basis.

When I had completed the document, I would then raise a ticket to the deployment team. They held the production passwords, and had the unenviable job of getting my sloppy junior-dev code into production. To them, I was the guy dropping the worst smelling fart in the room, and then casually strolling away.

Meanwhile, back at my desk (which was in an entirely different room, of course), I would be twiddling my thumbs, hoping for the best for my deployment. Usually, I would find out later that something had gone wrong, because I’d missed a step.

So I’d go back to update the document, and start the process again, praying that I hadn’t missed something else.

Now let’s look at how we could achieve this today. There’s a ton of tools we can use to automate this process.

To save typing and prevent mistakes, we can use shell scripting and configuration management tools like Ansible to deploy the application. We’re effectively writing another implementation plan like I used to do above, but this time, we’re writing it in code. This gives the deployment team more confidence that what they’re deploying.

We also have containers. Containers give us, as developers, ultimate power over the environment in which our application will run. Who doesn’t want that? Containers enable this because they are essentially both a self-contained environment and a common packaging format for our app.

No longer do we ship a set of pieces and write some instructions on how to put them together. Now we ship the application as a single, familiar package. And our package runs in the same way as all the other packages.

Testing can be improved with automation, too. Automated testing doesn’t mean writing one pointless unit test and making it go green. We can write automated tests to ensure that our code works as expected, or to prove that a particular bug was well and truly fixed.

Testers don’t need to wait for code to arrive in their lap to contribute. They can shape the software before it’s written, by writing test cases (using Behaviour Driven Development), and they can automate their test scripts using browser-based testing tools.

And we can wrap all of this in a build pipeline. A pipeline brings it all together: compiling code, running automated tests, and safely deploying an application to production.

A pipeline can even be used to perform other, related tasks that used to be done manually; such as creating database accounts, seeding some data, or configuring a third-party application. Now the deployment team doesn’t need to worry as much.

This is a lot more effort than writing a Word document. In fact, it’s really hard. Automation takes a lot of effort and commitment. But the payoff is more than worth it. Do you want more confidence in the software you’re building and deploying?