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.