I have had a few emails from readers of this blog over the last week asking if it has been abandoned. The answer is No. I was off work for a month after having surgery and then on my return to work I was pretty snowed under, but I am definitely continuing to write posts. I am currently half way through my next large article on Service Oriented Architecture Design and will have that posted over the next month.
In the mean time, thank you to everyone that reads this blog regularly. Over the past 3 months, traffic has been rising quite a lot, far more than I ever anticipated, so I will definitely be continuing with it. I have lots of interesting posts in the pipeline, as well as expanding the training section.
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.
Does it build? Yes then continue, No then stop the code review.
Run the unit tests.
Do they run and all pass? Yes then continue, No then stop the code review.
Check the unit test code coverage.
Is the coverage around >60%? Yes then continue, No then stop the code review unless there is a good excuse for the coverage that the review team are happy with.
Check the code metrics (Cyclomatic Complexity and Maintainability Index)
Are the metrics within agreed boundaries? Yes then continue, No then stop the code review.
Run the static code analysis against the agreed rule set?
Are there any warnings / errors? Yes then stop the code review, No then continue.
Once you get to this point, the development practices have been followed and you can proceed to review the actual code.
All of the tools I discussed above are available as standard to developers who use Visual Studio Enterprise Edition, except Resharper/CodeRush etc.
Unit Test Coverage
Whilst you are developing your software you should be writing tests to exercise that code. Whether you practice test driven development and write your tests first or write tests after the fact, you need a decent level of test coverage. This gives you a level of confidence that the code you are writing does what you expect it too. Also, it gives you a safety blanket when you need to refactor your code. If you make a change in one area, does it break something somewhere else? Unit tests should give you that answer.
The screen shot below, shows the Test Explorer view in Visual Studio 2012. From this view you can run all of your unit tests. As of Visual Studio 2012 Update 1, you can group you tests based on pass outcome, length of execution and project. Think of this view as your project health dashboard. If you have a good level of coverage and they are all green, then you can carry on developing. If you have any red tests then you need to work out why and fix them. Don’t let this view lead you into a false sense of security though. You still need to write tests to a decent level of coverage and ensure you are testing the right things.
You can check your test coverage very easily in Visual Studio. First you can click the little drop down ‘Run’ menu in the Test Explorer, or you can open the ‘Test’ menu in Visual Studio, and then open up the ‘Analyse Test Coverage’ and select ‘All Tests’. This will give you a view similar to below.
I was reading an interesting article on The Register today called “What Compsci textbooks don’t tell you: Real world code sucks”. Whilst the title of the post is quite brash, I did find myself nodding my head at pretty much everything in the post. As a Lead Developer at a financial services company, code quality is something that bothers me constantly, both in the legacy systems I have inherited and the new systems we are developing. I thought I would add comment to one of the points in the original post.
“A tremendous amount of source code written for real applications is not merely less perfect than the simple examples seen in school — it’s outright terrible by any number of measures. Due to bad design, sloppy or opaque coding practices, non-scalability, and layers of ugly “temporary” patches, it’s often difficult to maintain, harder still to modify or upgrade, painful or impossible for a new person joining the dev team to understand, or (a different kind of problem) slow and inefficient. In short, a mess.
Of course there are many exceptions, but they’re just that: exceptions. In my experience, software is, almost as a rule, bad in one way or another.”
I feel like I have been living this every day over the past 18 months. I have inherited some systems that are very challenging to work with. They contain code that is very hard to maintain, doesn’t scale and has virtually no unit test coverage. Pretty much all of the original authors have now all moved on, but that still leaves a waste ground of code for my team to maintain.
I now have a decent team working under me, and they are trying as best as they can to tame this huge legacy beast, and they are doing a pretty good job with what they have got, but we still find ourselves having to make compromises that make us uneasy due to time pressures, shifting priorities and lots more reason.