Demo Showcase Suite – A History – Part 9

Continuing on my series recounting how we got going on Demo Showcase Suite

7.  I wanted a reliable build and deployment process from the start

Okay this is pretty basic, and something I’ve insisted on for each project I work on.  You can’t afford to build production software on a developer’s machine.  It’s a no brainer though I’ve seen it done many, many times.  What we did on this project, was to convert from using CruiseControl.NET to TFS Builds.  This was new for me.  Why would we do this you ask?

First, we had converted from VSS to TFS.  I thought it would be better to be consistent and use the integrated tools we had.  Second, we were also having scaling problems with our current CruiseControl server, and we were going to need to upgrade it anyway.  So we made the leap to TFS with the plan to retire the CC.NET Server.

The other thing converting to TFS did was to take me out of being the expert on the builds, and I was able to delegate learning about it, and doing the setup to someone else.  I didn’t have time to do it, and as long as we were using something that I had put together, the likelihood of me continuing to be ‘the build guy’ was too high.  My very first job when I started in IT in 1994 was managing the nightly builds and version control.  In the 14 years leading up to the start of the project, I was always the build guy.  Now, I’m not the build guy anymore. 

We ran into some issues with deployments to Azure later when we tried to build on a 32 bit machine, so we had two build servers, a 32 bit machine for the client application and a 64 bit machine for the server apps.  This is probably not needed.  With a better understanding of configuration manager in Visual Studio, we probably could have everything working on just one, but we had so many problems with the vsmdi files that by the halfway point of the project, we were seriously considering other options.  Having a split build, and running the tests only in the Test build, not Prod and QA, helped a lot as well.

As far as the deployment process went, we scripted everything to get as far down the Azure path as we could, but we still had to manually upload to Azure, deploy and swap. There were two of us who became the experts on this, and kept everyone else’s fingers out of the Azure pie, just to be safe.

We spent a lot of time building the MSI for the client to have it do everything we wanted it to do.  A lot of what we learned we are able t0 apply to other projects right away, and though it took far more time to get it perfect than we wanted to spend, it sure is nice to have a process we just always trust.

I’m feeling ambitious tonight (and wanting to get onto technical stuff sooner, rather than later), so I’ll cover #8 and #10 tonight.  #9, as it turns out, is a whole series unto itself.

8) I wanted the team to be able to provide me with feedback quickly and easily and to give both myself and the PM a heads up well in advance of a red flag issue becoming critical.  No surprises.

I think I’ve covered this already, but this was all about communication.

• We implemented the scrums, as previously talked about. 
• We used task tracking in TFS to flag blocked items.
• When someone is worked up about something, we dug in and broke the task down so I could see and understand what the problem was.  Don’t let people stew, whether it be a technical issue or a personal one.  Get it out in the open and deal with it.
• We had whiteboards in the middle of the work areas.  If there was a major issue, we grabbed people and whiteboarded it out with input from everyone.

I think we did really well in this one.  There were almost no surprises from within the team, and the few that were came from me not listening carefully enough when tasks were starting to slide in the early days of the project.  I learned to listen for the signs that trouble was brewing, and made an effort to head it off earlier.

10)  I wanted to enrich my technical knowledge base.

I had no idea how much I would learn on this project.   I still can’t believe how much I was working on that almost no one else in the world was doing.  When it came to doing the first part of the security system, I think there were two or three of us on the MSDN Forums bouncing ideas back and forth.  Dependency Injection, Rhino Mocks, WPF MVVM.  I learned so much in the first few months, I thought I was going to drown.

For the record, I am not going to claim, as I begin writing about the technical aspects of the project, to be the expert in any one area.  I am sure (absolutely positive, actually), that for each area I will get into, that there are a dozen people, if not a thousand, who know more.  I’m just going to show you what we did, for better or worse.  Some will laugh and point and snicker at some of the code.  Hopefully I can get some feedback on better ways to do things.  Hopefully someone out there getting started on Azure or MVVM or Silverlight or Demo Showcase will get some information that saves them some time or money.

If you have a specific area of the Demo Showcase architecture you want to hear about, let me know, and I’ll try to cover it in an upcoming entry.  If you have a question about how to do something in Demo Showcase, or have a suggestion for a new feature, send it in.  I’ll get it on the list.