I recently started working for a new company as a Development Manager, and one of the things I am looking to introduce with my new team is a Continuous Integration and Continuous Delivery pipeline to make us more efficient at delivering reliable releases, frequently into production. Whilst I was looking for some useful resources for the team I came across an excellent video by Jez Humble that discusses not only Continuous Delivery, but the challenges faced in introducing this into large organisations with mature waterfall style change control processes.
This video is an excellent introduction to the topic and if you are also considering introducing a similar process into your organisation, then I highly recommend watching the video. The technology side of introducing Continuous Delivery is quite straight forward. There are many tools, patterns and practices available to help you with this no matter what you development environment it. My teams environment happens to be .NET using TFS, but this is all just as relevant even if you work in other environments like Python, Ruby, Java etc.
Last year I wrote a short article explaining what Agile development was about and how some people generally miss the point and assume that to be Agile you have to follow something like Scrum. This article pointed out that Scrum was merely a project management tool for helping you to be agile. With this in mind, there are still a lot of misconceptions about what it is to be Agile, so I thought I would list down some of the ones that I have heard and counter argument them.
Agile is ad-hoc, with no process control
To be properly agile you need to adhere to the agile manifesto, but following the manifesto doesn’t mean you are using a defined process. The manifesto describes a set of ideals. There are various different processes and project management templates that you can apply to your projects to help you become agile. Extreme Programming (XP) and Scrum are the most popular.
When you try to implement the manifesto items you generally need to apply a lot of common sense and pragmatism to get to your goal, but if you want to wrap a more formal process around the ‘How’ of agile as opposed to the ‘Why’, then you would apply something like Scrum, which gives you more formal processes like epics, stories, iterations, stand-ups, demo’s, retrospectives , test driven development, pair programming etc.
Build the right Product – Using a continuous deployment model helps to ensure you develop the right product by ensuring you get rapid feedback from your business partners and stakeholders.
Earlier Benefits – Continuous delivery enables you get benefit out to your business/customers earlier so they can take advantage of features sooner rather than later in a big bang deployment.
Ability to React Quickly and Respond to Change – If youhave a continuous delivery system set up and are used to deploying continuously you can respond to changes in requirements more quickly or fix and deploy bugs sooner.
Innovation – The continuous delivery process enables you to work closer with the business. This closer working relationship means you have different kinds of people and skillsets working closer together. This can lead to different perspectives on problems which can lead to innovation.
Reliability and Stability – If you release your projects continuously you are repeatedly exercising your deployment process. This continual deployment and the fact you can react to change quicker leads to more reliability and stability.
More Efficient / Save Time –By automating your deployment process you can make your development team more efficient as they don’t have to deal with deployment issues as often leaving them more time to work on the good stuff, writing code!!!
Strategic Impact – A combination of all of the above gives you a strategic advantage over competitors as you can release more features sooner and fix problems sooner.
I can’t stress the benefits of getting continuous delivery working. If you are working on a new project and don’t have to deal with legacy code/systems then this is easier to achieve. If you have to deal with a huge knotted legacy estate like my developers have had to do, then getting a good continuous delivery pipeline running is harder, but can be achieved in stages.
This is what we did. We got automated builds going, and then had installers being built at the end of the builds. Then we worked on the tools for deploying to different environments. We have continuous delivery working into test environments but our next stage is to get this working for production deployments.
This is made harder for us as being part of an American Financial institution we are subject to the Sarbanes Oxley regulations which mean we have to have clear separation of concerns between development and production system, but we are looking to tackle this.
There is a very good book about this subject that I highly recommend reading. The book is called Continuous Delivery by Jez Humble and David Farley. Currently with the team I work in we are using TFS and its built in tools to manage our continuous delivery process with an auto deployment tool written by some of the guys on my team, but we are considering moving to just using TFS as a source repository and using Team City + Octopus Deploy to manage builds, packaging and deployment.
Recently, I have been doing lots of recruitment for .NET consultants. Each of the CV’s we receive all stress that they are experienced in working in agile development shops. This is great. We are an agile development company so these people sounds like a great fit.
So we get them into an interview and ask them, ‘What does agile mean?’, ‘How do you know if your team is truly agile?’ It’s at that point we get the standard list of responses:
We do Test Driven Development.
We pair program.
We use continuous integration.
We use SCRUM, KanBan, XP etc.
Use work in iterations.
We use story points.
We calculate team velocities.
These answers are all well and good, but they don’t describe what an agile team is. These are all just facilitators to being agile. What’s even worse is that these interviewees seem to have not heard of the agile manifesto.