Developer Environment

Setting up a development environment is a relatively simple thing to do, but getting it right is more difficult and is something that should be constantly revised based upon project/sprint retrospectives.  We have gone through several iterations here at Aqueduct, in order to get something that we think it works quite well.

Dev machines

Developers must have good machines. Very Good Machines. Dual monitors are a must.

Tools

Good tools are a must. We use the following:

Resharper 5 – Lifesaver plugin.

VS2010 – Our IDE of choice.

Ants Profiler – For checking for performance issues.

Liquibase,  - For Versioning database changes

Apache bench – For load testing

TortiseSVN / GitBash – For source control management

Visual SVN Server – Takes the pain out of hosting subversion on Windows

            Firebug – The legendary plugin.

NUnit

Selenium

                        NCover

Moq

Source Control

We generally use subversion but we have been experimenting with GIT and Mercurial recently. Personally I like Git and we trailed it on a recent project. Unfortunately, we found that Git has quite a steep learning curve  (compared with subversion) and we chose to trial it of a fairly short project (8-10 weeks) with 5 developers.  I don’t think this was a long enough period for every one to adapt to it and we encountered lots of merge issues and it put everyone on the project under a fair bit of pressure. We are going to persevere with it and trial it on a longer project as we can see the potential benefits.

Test Driven Development

TDD is something we have been pushing at Aqueduct for a while. Although we are not fully there yet, we are getting there.  We generally use Moq and its powerful fluent structure in combination with Nunit to create our tests. Mocking in combination with the MVP pattern (where we can’t use MVC) allows us to bypass the problems generally faced when developing with webforms.

Code Coverage

We generally aim for around 50% code coverage on projects.  I personally feel that although having 100% coverage is possible; it is not worth the extra effort. You end up just testing setting properties on a view, which does not really tell you much. I prefer to test the actual business logic.

Continuous Integration

Having a continuous integration setup is at the centre of everything we do.  It allows to know the current status of the code as soon as someone does a check-in, instead of finding issues when we deploy.

We use CruiseControl.Net in combination with CCTray. At the start of each project we setup three different builds.

 CI Build (Run on every check-in)

·      Runs Unit Tests

·      Runs Selenium Tests

·      Computes code coverage

Nightly Build

·      Runs Unit Tests

·      Runs Selenium Tests

·      Computes code coverage

·      Deploys to DEV server

Staging Build (Manually triggered)

·      Runs Unit Tests

·      Runs Selenium Tests

·      Computes code coverage

·      Deploys to Staging / QA server