Deployment - does it take time?

One of the things that often gets overlooked when writing software is the time and effort needed to get it from the developer's computer to its final publication or live state on the internet. This is called software deployment.

For a simple website, I would just FTP the files from my machine to the machine where they are to be hosted. This hosting would be managed hosting so once I'd figured out my domain names from my usernames, I'd know what goes where and there we go.

And this serves me well for simple websites, but as the level of complexity and importance grows in a piece of software, the less I want all my hard work in development and testing to be wasted when the customer sees the end product break because of what is essentially an error in copy-pasting.

FTP has no "undo" function, and I only have the date stamp and size of the file to help me determine which files changed and how long ago. As the software grows in size, the more uncertain I become about how close my development copy is to the deployed version, and the more likely I am to break it by deploying the wrong file called "index.php" to replace one of the many not up-to-date "index.php"s and leaving myself a job worthy of a detective to try to get the released copy back in the state I want it, without deploying features I'm not ready to release.

And if I'm working on multiple computers, or another person is helping, then we have to remember to keep our development copies in sync with the released version despite the changes we've both made. Oh, and we can't work on the same file at the same time as we'll end up getting stuck in a loop where we constantly overwrite each others changes.

And if something breaks, how do we know where the problem is, without all our comfy development and debugging tools to hand?

It gets messy.

The solution we've adopted at myCoracle, for the Learning Line, is a standard one. Make the deployment process repeatable and testable, and make sure I'm informed if anything goes wrong.

Our source control makes sure that the version we are deploying is the correct one. Our deployments are done using a Python library specially built for the job, called Fabric. Using this, I can get the correct version of the code from source control, copy it to the correct place, and then run the unit tests that I talked about last time.

These sanity checks allow even the most paranoid person to feel that deployments are done fully and accurately.

Django provides some tools to make sure you're informed if anything unforseen happens, in such a way that you have to work really hard to turn them off. That's a good thing. It gives me more confidence that we've made a good decision there in using it.

And you can rest assured that we'll be informed about issues in our software as soon as you are and that we've got the tools to deploy fixes quickly, securely and accurately.