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.
Disclaimer: I currently do not own or have been given a license to NCrunch. I am forming my opinions of it based on the use of the 30 day evaluation license.
In this article I want to talk about a very useful tool called NCrunch. I have had a few people recommend the tool to me recently, so I thought I would check it out. I am glad I did. So, what is NCrunch? The description on their site explains this nicely.
NCrunch is an automated concurrent testing tool for Visual Studio .NET. It intelligently runs automated tests so that you don’t have to, and gives you a huge amount of useful information about your tested code, such as code coverage and performance metrics, inline in your IDE while you type.
On reading that I first though, hmm, well doesn’t visual studios test explorer do that, and it does, but this tools goes a step further. In essence NCrunch executes tests in the background whilst you work giving you continuous feedback. Initially I thought that’s not really such a big deal. One of the projects I am working in has 690 unit tests and because they are true unit tests, as in they don’t hit databases or external resources, then they only take 20 seconds or so to run. Even though this is the case you still get into the compile, run the tests, check the results, fix or carry on loop.
Disclaimer : My license for NDepend was provided free by Patrick Smacchia at NDepend. This license was not given to me in return for a good review. The article below is based purely on my own observations and use of NDepend.
A while back I published a couple of articles on Structured Code Reviews:
In these articles I discussed a code reviewing process aimed at sharing knowledge and increasing code quality in your team. In these articles I discussed using the tools already available to you in Visual Studio 2012, like the Unit Test Runner, Code Metrics, and Static Code Analysis.
In this article I want to expand on the tools available by looking at a 3rd party tool called NDepend. So, what is NDepend? First let’s look at the description from their website.
Make your .NET Code Beautiful with NDepend
NDepend is a Visual Studio tool to manage complex .NET code and achieve high Code Quality. With NDepend, software quality can be measured using Code Metrics, visualized using Graphs and Treemaps, and enforced using standard and custom Rules.
Hence the software design becomes concrete, code reviews are effective, large refactoring are easy and evolution is mastered.
Essentially NDepend is an analysis tool that really allows you to dig deep into the structure and quality of your code. You may want to do this for various reasons. You may want to routinely keep an eye on the quality of your project, or you may have to get under the skins of a large piece of legacy code so that you can refactor it.
In unit testing, all mocks are evil! Now there’s a controversial statement to start a blog post with, but let me explain. I am writing this from my own experience as a software developer and a leader of software developers. This is the sort of thing that software religious wars are made of, so if you agree, or disagree, I would love for you to share your thoughts in the comments.
I think Mocking libraries, although very powerful, can enable developers to over complicate their unit tests. Unit tests should be short and easy to understand. I have lost count of the times where I have seen a developer mock out more than they need to because of excessive class coupling in their code. Just because you can mock out any object doesn’t mean that you should and avoid reducing excessive coupling.
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.
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.