Why a Commitment to Continuous Deployment Pays Off

I knew there wasn’t a lot of scope for inefficiencies. As a result I set about working through the things I’d have to do, to make the development process as simple and efficient as possible.

You might be surprised to learn that what language to develop the application in choice wasn’t at the top of the list, nor even on it.

Instead, I sat down in my office and started considering all the various tasks which would need to be done to get the application launched ASAP. After that I then broke the list down in to which were the most important, which were automatable.

After a little while of doing this, perhaps half an hour, I’d created a plan, one which, if I pulled it off, would ensure that I could focus near exclusively on the most important areas of the project; those being client communication and design and development.

What Was My Plan, You May Ask?

It’s this. On thinking the situation through, I remembered that some of the most expensive processes, expensive with respect to time and distraction, are setting up and managing development and deployment environments.

Over the years, I’ve worked in places which have had a semi-smooth development and deployment process, and I’ve seen the benefits which it yields. I’ve also worked in some which; well to say they had a process would be generous at best.

Here’s the process I decided to go after and implement. I’d use Ansible to provision both the local development and remote deployment environments.

The remote environments would include both a testing and production setup. Each environment, whether development, testing, or production, would be composed of two servers; one web and caching server, and one database server.

Then I’d use a CI server, likely Codeship, to implement the deployment process. Here’s how that process would work. After changes were pushed to the VCS server, likely Bitbucket, the CI server would run a build, and if the build passed, then a deployment would be made to the testing server.

If the deployment was successful, a notification would be sent to the client, notifying them that changes were ready for review. If the client was happy with the changes, they could then kick off the deployment to production.

How’s It Working Out?

So far, I’m beyond delighted with the results! The provisioning of all environments, along with the deployment to the test server is fully functional.

How the client can trigger a push to production however, that I’m still working on. I’m happy for any constructive suggestions about how to do this.

Why All This Emphasis on Automated Deployment and Provisioning?

You might wonder why I’m so keen to take this approach. Perhaps you might think that I should be focusing just on the coding, and worrying about the deployment later. I hear what you’re saying, but I believe that’s the wrong approach.

My approach is based out of the Linux ecosystem in which I grew up. If you come from a Windows background, you may be used to thinking that Linux systems take a lot longer to setup and configure. Well, that used to be the case some years ago.

But I’m fine with taking a bit longer, at the start, to get everything up and running just right. Why? Because time invested here pays off later, when you’re not wasting time keeping servers up and running.

Linux has always served me well that way. Once it’s running, generally you just leave it to do its thing, as it keeps on ticking. Given that, I believe it ~should~ must also be done that way in software development as well.

They should just keep on working, letting us get on with testing and development.

Over To You

Do you agree with me? Yes/No? Share your experience and thoughts in the comments.

CC Image (background of main image) Courtesy of Michael Himbeault on Flickr