A couple of years ago, whilst I was at Madgex, James and Martin ran a discussion session around this video

I liked the idea and the concept of derisking deployments, but the architecture/complexity of the systems we had didn’t suit it. Now I’ve moved on, and have a much simpler architecture to work with, this became a realistic possiblity. So, I’m really pleased to have now got a system that does automatic daily deployments to test. I’m not brave enough to have switched it to do live deployments like that yet, but they use the same interface, so there will soon be no reason why they shouldn’t - and in reality the only difference is that I currently get to control the time when a deployment to live happens. The mechanics are the same.

We’ve built our continuous integration environment on top of Jenkins. It polls our hosted git repositories and builds when it detects changes (ideally, this would be a post-commit hook). Any dependent projects are set up to build as a result of a successful build of the project it is dependent on. The projects which have embedded tests get run, and failing tests cause the build to be flagged as a failure. We can manually deploy at any stage if we need to by simply pressing the “Run build” icon on jenkins (I have a “Deploy To Test” job within jenkins). But if we don’t then they’ll get deployed the following morning anyway.

This is because early every morning (before any of us are in), the deployment tool runs, deploys anything that is waiting, emails a summary to the shared email account and then triggers off a batch of end-to-end tests. This means that when we get in we know that the test system is up to date and a basic set of tests have run (and hopefully succeeded). Every weekend a larger batch of end to end tests gets run automatically as well, again just to exercise the system from an automated load test perspective.

We’ve been running like this for a month or so now, and it seems to be going really smoothly. I’m finding jenkins really easy to work with and manage and we’re gradually increasing the amount of unit tests and end to end tests to continue this process. Perhaps most important is that deployments are no longer quite as scary, happen more often and are being done by more members of the team, rather than relying on a specialist.

So, thanks James and Martin for planting the idea. I did listen.