Today some colleagues and I were discussing prospective deployment options. We have all worked on many projects, isnt it funny how often the deployment process, the most important part, is a complete after thought. After mentioning it this morning to the PM/BA/Non techies we realised there was no actual deployment procedure in place (this is my first real release at the current company). We decided to let them come up with a standardised plan for their end (“put last build into production” was an option we had to take away from them) while we sorted out our plan.

I am still very much learning abut builds and CI, so this is by no means the authoritative answer; This post basically described what we came up with.

Preface

One thing we are dong well is actually using ClickOnce, a technology that is perfectly suited for the large corporate environment we work in and deliver smart client app’s to. We want to continue to do this but make sure it is done properly.

We have very loose processes out side of the people actually writing code. The non tech’s are not au fait with agile, they are not too good at requirements, planning, resourcing… well you get it. So we need to insulate ourselves from any curve balls that get thrown by these guys. We also need to seriously cover our ass, because when the proverbial hits the fan around here it slide down the ranks very fast; we want to make sure the have no way of letting it get to us, unless of course we actually deserve it.

We don’t have full control over deployments. There is a system team that will copy our applications up to the next environment (ie Test -> UAT), and it has to be the same application to get pushed up. This is fair enough, however it doesn’t work well for ClickOnce, by default any one testing on a lower level would not get updated*, we actually need a separate application for each environment. We also have only once chance for deployments. if we mess up even one deployment it means this process is no longer automatically approved and every change must go thru a 2 week change management process.

The Plan

In the time I have been at my new contract I have managed to get a couple of pretty big wins. We are now completely TDD we have a build server, we do (close to) weekly deployments to a dev test environment and we are getting up to speed on scrum. What I really wanted next was “one click deployments”.

The plan basically is:

• We will decide a release date/time for moving from Dev to Test. We are currently doing 7 day sprints and trying (scrum is new) to deliver a working production-quality piece of software each week. ATM this is Wednesday 2pm (for a variety of reasons).
• We run the Deploy Script**. The deploy script runs our standard build which performs unit and integration test, static analysis etc, then it modifies the config to the test, environment and publishes to the pre-deploy network location (then repeats for UAT then Prod) .
• We now have all the releases of each version in a known pre-deployment folder. From here the test click once is copied to the real deployment folder.
• The Testers test away and of course there are no bugs [ 😉 ] and they approve release of version x.y.z.b. Because we have all the releases for each environment produced at the same time and are the exact same build (other than 3 small config files) the system lads can do their Test->UAT (or UAT->Prod)deployment based on the version number that has been approved.

This means

• We have every release in pre-deployment for Test, UAT and Prod
• The testers can let the system guys know the exact version number that has been approved. It is now up to the system guys to copy the correct versions up to the next environment.
• We cant modify the files as it will break the manifest and render the app useless. This keep the system guys happy.
• We are removed from the deployment process, which means we don’t have to be at work at 9pm when the deployment takes place.
• Multiple versions of the application can be held on the users workstation, each one assured it is the latest for it given environment. This keeps PM’s, BA’s,Testers & UAT testers very happy.

This process takes about a minute. A lot happens but it is totally repeatable and completely versioned. This certainly is a better/ faster/ more reliable option than the 3 hour deploys we did at my last place of work. To be honest I’m pretty happy with it. This should also work well with ASP.Net deployments however there would have to be a versioning folder “hand created”*** (I believe) to get the same effect.

So I haven’t quite got my “one click deployments”, but half a dozen clicks and some automated scripts that run in under 5 minutes (most of that is watching static analysis and  tests run) is a bloody good start. Plus it’s a good time for me to sit back and have a coffee; I’m almost looking forward to deployments 🙂

 

For you nosey bastards; The deployment part of the script looks like:

    
    
    <AssemblyInfo CodeLanguage="CS"
      OutputFile="$(ApplicationPropFolder)\AssemblyInfo.cs"
      AssemblyTitle="$(AssemblyTitle)"
      AssemblyDescription="$(AssemblyDescription)"
      AssemblyCompany="YOURCOMPANY"
      AssemblyProduct="$(AssemblyProduct)"
      AssemblyCopyright="Copyright © YOURCOMPANY"
      ComVisible="false"
      CLSCompliant="true"
      Guid="$(WinUiProjectGuid)"
      AssemblyVersion="$(BUILD_NUMBER)"
      AssemblyFileVersion="$(BUILD_NUMBER)"
     />
    
      $(RootClickOnceDeploymentLocation)\DEV\$(ProjectName)\
      $(RootClickOnceDeploymentLocation)\TEST\$(ProjectName)\
      $(RootClickOnceDeploymentLocation)\UAT\$(ProjectName)\
      $(RootClickOnceDeploymentLocation)\PROD\$(ProjectName)\
    
   
    

    
    
    
    
   
    <MSBuild Projects="$(SolutionFile)"
             Targets="Publish"
             Properties="Configuration=Release;
              PublishDir=$(DevFolderLocation);
              PublishUrl=$(DevFolderLocation);
                  InstallUrl=$(DevFolderLocation);
                  UpdateUrl=$(DevFolderLocation);
              ApplicationVersion=$(BUILD_NUMBER);
             "/>
    <MSBuild Projects="$(SolutionFile)"
             Targets="Publish"
             Properties="Configuration=Release;
              PublishDir=$(TestFolderLocation);
              PublishUrl=$(TestFolderLocation);
                  InstallUrl=$(TestFolderLocation);
                  UpdateUrl=$(TestFolderLocation);
              ApplicationVersion=$(BUILD_NUMBER);
             "/>
    <MSBuild Projects="$(SolutionFile)"
             Targets="Publish"
             Properties="Configuration=Release;
              PublishDir=$(UatFolderLocation);
              PublishUrl=$(UatFolderLocation);
                  InstallUrl=$(UatFolderLocation);
                  UpdateUrl=$(UatFolderLocation);
              ApplicationVersion=$(BUILD_NUMBER);
             "/>
    <MSBuild Projects="$(SolutionFile)"
             Targets="Publish"
             Properties="Configuration=Release;
              PublishDir=$(ProdFolderLocation);
              PublishUrl=$(ProdFolderLocation);
                  InstallUrl=$(ProdFolderLocation);
                  UpdateUrl=$(ProdFolderLocation);
              ApplicationVersion=$(BUILD_NUMBER);
             "/>
  

 

NB:You will need the MS Build Community Task download to update the AssemblyInfo.cs. The M$ one is a bit flakey (apparently). I used the community task for other things anyway so I figured I would use what is there.

NB: the BUILD_NUMBER is being passes in as a parameter to the script.

As my MSBuild skills are not the sharpest, I have left the repeated code in. I spent a couple of minutes trying to figure out how to prevent repeating myself with MSBuild but to no avail. if you have any ideas (short of Rake) let me know.  I am also still figuring out ClickOnce so some of those URLs are probably not necessary, have a play yourself…. this is just my first run.

*because, for example, Dev version would be higher than Test so when clicking on the latest Test ClickOnce application it would deem the application does not need to be updated as the dev version number is higher than the Test version number (if they were being run on the same machine). The applications have to be different applications for each environment. We still need to confirm this is the case with today’s changes. Yeah… a bit of a pain, but worth it I guess.

**we actually stop the build server for the project we are deploying, reset the build counter, increment the release version, then run the script then restart the server.

** MakeDir is not really hand created, but you get my drift 😉

I am sure someone out there may find this useful. Its an XSLT to transform the TRX file that is output by the MSTest runner. Its a slightly better visual depiction than my MSBuild output of thousands of lines of courier new text…

This is very much “It works on my computer”, I am running VS 2008 Team edition (?). Let me know if this works for you.

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform&quot;
                xmlns:vs=”http://microsoft.com/schemas/VisualStudio/TeamTest/2006″&gt;
 
   
     
       

Test Results Summary

       

         

           

           

         

         

           

           

         

       

Run Date/Time
Results

        Coverage Summary
       
       
     
   
 
 
   

Test Summary

   

     

       

       

       

     

     

       

       

       

     

   

Total	Failed	Passed

 
 
   

Unit Test Results

     

       

       

     

     
       

         
           
              background-color:pink;
background-color:lightgreen;
              background-color:yellow;
           
         
         

         

       

     
   

Test Name	Result
	FAILED               Passed               Inconclusive

 

Rhino Mocks is one of my favourite pieces of open source software. It has, more than any other piece of code, changed the way I code, for the better, I hope.
Many moons ago I first played with it and like the fact it was strongly typed, NMock2 was the mock framework I was using at the time and it is string based, which can lead to havoc when refactoring.
Back in those days RhinoMocks was only Record-Playback and to be honest it never felt natural to me. Due to popular demand the framework was extended to allow for either the record play back or IMO the more natural AAA syntax

Arrange – Act – Assert

Arrange, Act, Assert to me help break up the way I write my test to make it very clear what I am trying to achieve. I even have code snippets that auto populate my test. I type “mstest” and i get

[TestMethod]
public void Can()
{
   //Arrange
   //Act
   //Assert
   Assert.Inconclusive("Test not completed");
}

I also feel this allows newcomer to see what is going on more clearly and also helps them write test first.
How?
Well, in my mind the hardest thing to do when starting TDD is knowing what to write! If you have the code stub with comments as above, it gives you a visual guide to nudge you into progress.

I also find it helps if n00bs actually write the ACT part first, not the ARRANGE. Typically this involves writing 2 lines of code

• create the object and
• call the method you want to test

eg:

[TestMethod]
public void CanValidateCustomerFromCustomerAddPresenter()
{
    //Arrange
    //Act
    var presenter = new CustomerPresenter(view,service);
    presenter.Validate(customer);
    //Assert
    Assert.Inconclusive("Test not completed");
}

The fact the above code wont even compile is irrelevant. It shows intent. Now the developer writing the test has a clear direction of what they need to do. Often this way of TDD fleshes out new tests. To me this (incomplete and fictitious) test straight away is crying out for complimentary tests: eg CanNotValidateCustomerFromCustomerAddPresenterWithNullCustomer etc etc
The fact that I have not even defined what a customer is, means my mind is still open to possibilities.
On top of the benefits of writing the ACT first, I think AAA syntax makes the test more readable in terms of maintaining code bases, as it has the top down procedural look that coders are used to (even OO has top down).

[TestMethod]
public void CanValidateCustomerFromCustomerAddPresenter()
{
   //Arrange - Set up mocks (put in your TestInitialize)
   var view = MockRepository.GenerateMock();
   var service = MockRepository.GenerateMock();
   //Arrange - Set up your parameters & return objects
   var customer = TestFactory.CreateVaildCustomer();
   //Arrange - Set up your expectations on your mocks
   view.Expect(v=>v.ShowValidation(customer));
   service.Expect(s=>s.Validate(customer)).Return(ValidationFactory.Success);
   //Act
   var presenter = new CustomerPresenter(view,service);
   presenter.Validate(customer);
   //Assert
   view.VerifyAllExpectations();
   service.VerifyAllExpectations();
}

Now I have not run this thru a compiler I just threw this down, but to me this is pretty readable. I used Record-playback only for a few months and found it a little confusing, perhaps my pitiful little brain was maxing out on simple syntax, but hey.
If you are not using AAA try it out, it works great with the C# lambda expressions too (as above) which, to me, means you have incredibly readable tests.

*please ignore the fact the test is odd.. I am trying to show readability as opposed to how to write a crap object 😉
**is it incredibly obvious that i am writing MVP triplets ? 😉

Just a remnder that we are meeting at 43below on Barrack Street in the city at 5:30 thonight (11th feb 09).
Be there or… well, or dont be there.

More stuff i am looking at:

• Android dev… very exciting i will finally be able to do some real world dev in my osx environment
• I will be starting to use GIT* due to android dev with my java mates… should be interesting. * this bring me up to using 4 different SCMs at the moment… bloody hell.
• Automocking from the Jimmy Bogard. This looks to be a great help in the mismatch between dto and domain object. Used with the NH fluent interface for mapping life could be significantly easier 🙂

Some links:
Fellow OzAlt.netter post on GIT : http://www.paulbatum.com/2009/02/im-starting-to-git-it.html

I am not a fan of the singleton pattern. This may come as a surprise to some, as the very first thing that people may see when using my code is the wrapper I have for my IOC container acts as a singleton.

So why do I, along with many others, not like the singleton? Because it is usually used incorrectly and hard to test.

The first time I had seen massive singleton abuse was when I had to go on a consulting gig to help “finish” a project, i.e. the final sprint prior to go live. The whole data access layer was made up of a mess of singletons. There was no need for it, none for the objects had state let alone required to hold state in a single instance but they would not let us, the hired consultants, refactor it out. Bizarre*. Since then I have seen a singleton butcher-job at just about every contract I have had. it seems to be the first pattern people use and the first to be abused.

So when do i use a singleton? Well when an object that should only have one instance. The notion of singleton implies there is only one logical possible instance of that type that can be in creation at a time. I think this is the fundamental problem I regularly see. Most times I see the use of a singleton this is just not the case.

To highlight this even more, often the object itself does not even have state. If the type has no possible (instance) state, then there is surely no need for singular state! This is the time where the object is just a static class. In the same way it is ok to use singletons, it is ok to use static classes, just make sure it is the right circumstances for your choice.

One annoyance is when singletons are used so they can be “thread safe” and then the construction of the object is not thread safe. please investigate how to do this if this is actually a concern. Even better use an IoC container! By using an IoC the object becomes easily testable and you infrastructure concerns are hidden from the consumer. To me, this is a good thing. 🙂

*That project is still going, still not live and apparently still has singletons used inappropriately in the data access layer. Oh well.

I don’t know about you but I like loose coupling. Being able to code against abstractions is great, I can be TDD and focus on SRP and proper SoC. Maintenance and extensibility become much easier and code is visibly cleaner. There are tools out there that help me do this currently such as various mock frameworks, IoC containers and ESBs but I though I would introduce a couple of relative new comers to the scene that can help loosen things up a bit.

A few months (maybe years ago I get up an abstraction of the IoC containers I use (Spring.Net, Castle, StructureMap and Unity) so I didn’t have to remember all the different semantics for each container for each contract/project I worked on. Well a few months ago M$ came up with the Common Service Locator. It is a good idea. I like it and may replace my abstraction with this soon (only for the sake of people maintaining my code). If you are a contractor/consultant or use various IoC libraries then this could be a godsend. IoC is a crucial part of my work and many of the patterns I use are very hard to implement without even a basic IoC container. this will hopefully break down some barriers for new comers who cant decide what to start with.

MEF is the Managed Extensibility Framework which allows post deployment extensions. Think about that; it allows me to have hooks in my application so that later on I, or a third party can easily extend the framework, like an improved way of bolting on Resharper to VS or as Glenn mention in this video like can be done in World of Warcraft with various plug ins. MEF is in its 4th release as of this week. Check it out. it has a kick ass team working on it (Glenn and Hammet  both get 2 thumbs up from me).

Live and code free.. be a hippie code, get loose man…

Some existing tools and libraries I use and recommend are:

Mock Framework: RhinoMocks

IoC: Castle, Unity & StructureMap

ESB: MassTransit

Yay! I have just found out that Perth is setting up an Alt.Net group… im super psyched about this… its exactly what this town needs, a good shake up about core coding fundamentals and best practices 😉

Cheers