Test Driven Development, Behaviour Driven Development, Extreme Programming and many other new-age hippy development methodologies have spread through the development world like wild fire. I believe there is room for one more in the shape of Build Driven Deployment/Automated Deployment - A new source of confidence in the development world. Time to go out and spread the word.
Over the past 10-15 years in software development our industry has been swept over by evangelists selling the secrets to software developer Zen in the form of Test Driven Development (TDD). Test Driven Development impresses on you as a developer many benefits:
- You can confidently refactor code because you have a test suite to back up your successful code changes
- You find yourself writing less lines of code, and having better architecture and planning around your code as it progresses from idea to reality because you are defining it in a module by module de-coupled style.
- You can iterate faster because you always have stable, well designed, and well tested code, as apposed to having any stages of “settling” or “stability” at the end of your development cycles – the code always works as written and is testable as such.
- You get to ponce around thinking of yourself as a member of the programming elite because you can extol the virtues to other (jokes… jokes…)
These things are all well and good, and the message has been shouted from the roof tops for long enough that like many types of folklore or Wikipedia entry, gradually over time they become fact/reality. This is definitely a good thing for our industry as a whole, and the above mentioned evangelists should be thanked for bringing about this change in mindset to the now majority of the development world.
But something is still missing?
When you develop a project, depending on the size of the task at hand great lengths of time are spent planning architecture/object modelling, and product life cycle and development timeline, and managing scope creep, and many, many other tasks, some that you don't even notice you are dedicating time too (keeping management in a happy place about the direction of the project and their personal input/importance to it anyone???) that make up your delivery of your software project.
So why is it that when we actually go to ship our product, or upload it onto our webhost, or generate our installation CD that in the majority of cases I've seen, deployment is not seen as something that deserves the same amount of discipline and forethought as the product itself?
So many people, myself included have talked about it recently that it must be starting to get through surely?
In the words of Scott Hanselman:
If you are using XCOPY, you’re doing it wrong!
When you want to deploy your project, having to do anything that is not simple and repeatable is a failure in your deployment strategy. Whether you write desktop software, mobile software, web software, work in a large team, your own one-man-band team or simply like to think you have management over any of the above, automated deployment is something you should seriously consider investing some of your time in.
I am so sure that i am speaking from a positive position, I am going to put my own quote into circulation around this:
“…After writing unit tests, automated deployment will be the best thing you can do for your development lifecycle…”
“But i already have automated build for my project” you say
This is not enough! Automated build is just the beginning, automated deployment finishes this off. If you cannot deploy from that build in an automated fashion you are simply moving the dependency on human error further down the chain of production, while at the same time giving yourself false confidence in you ability to ship a project with ease.
Why/How?
When you have a project that can be automatically deployed at the drop of a hat, you gain a lot of similar positive things that you gain from Test Driven Development and other agile methodologies:
You have confidence in your deployment.
You know that you can deploy your project anytime of the day. You know that if your technical lead/team lead/manager/janitor/mum is away for the day you can deploy your project. This confidence allows you to get on with more important things like actually writing code, or better tending to your clients. It means that in the web development world, you don’t need to have all hands on deck the day the project ships/goes live to make sure that everything goes smoothly.
You have confidence in your product lifecycle.
As with most build automation tasks you guarantee that the rest of your process is sound simply by adding automated deployment to your project. You guarantee that all your developers check in their code religiously. You guarantee that your developers are more vigilante in not checking in anything that breaks the build. You force people to think about how they store things in your source control repository and use things like branching and tagging for new features (this may be considered by some to be elementary, but believe me that in the fly-by-night world of web development, this in some teams’ cases is a big thing). It forces you to choose more modern distributed source control providers like Git or Mercurial because your developers want to branch/merge more quickly because they have to separate their work from the stable main line of a project that gets deployed.
You gain confidence in your projects’ architecture
Because you know that your code is going to be automatically deployed, you won’t be lead down the path of making architectural decisions that involve adding complicated fiddly third party dependencies that add human interaction to your deployment process. This is a good thing. You use unit tests more readily because coverage and unit test runners can easily be plugged into your build/deployment process, in turn giving your tech lead and management folk alike better visibility over progress and code coverage. You tend to implement more strict backup and storage of live assets versus static assets in your project/website because you write your projects to be more modular in their storage based around the knowledge of them needing to be backed up or versioned in an automated and repeatable fashion. You start to think more about the storage and versioning of things like your database’s schema and the generation and versioning of database change scripts. All these things are priceless and only lead to you being a better developer. As a architect of solutions myself an added benefit of all the above is that it forces less senior developers to grow as it forces them into some form of process and introduces them to a lot of this thinking early – in smaller teams this alone is HUGE.
Your customers gain confidence in your ability to deliver on time
Your ability to be able to repeatability deploy your website or software doesn’t just impact your team and their ability to push a new release – it also positively impacts your customers (the people you are doing this all for remember). If your project is internal your customers are your management and other staff members. Adding confidence to your customers (either internal or external) faith in your ability to quickly add a feature, and deploy it into production for use increases your brand/your teams brand in their eyes. This has a flow on effect in that i like to think it adds a surplus of “kudos” to your bottom line that can be used to better handle times when their view of your work is less stellar.
So how do i start on my path to further happiness?
There are many resources on starting to use automated deployment in your project’s life cycle. Depending on what platform or language you use day-to-day these will change, however their are a lot of resources available on the net for all of the above, you just need to look.
For .Net web developers some further reading can be found in some of the links below – feel free to let me know of any good ones to add to the list: