Rob’s Mind Flow

Robots is one of my kid's favorite movies. I like it too. "See a need. Fill a need." is the motto of the main character. He's a young inspiring inventor. It's a phrase he heard as a child from one of his role models, Big Weld, an older, successful inventor. I struggle with wanting to do things right. To provide the right solution at the right price and on the right schedule. And that's all well and good. Great goals. "Right" isn't always easy to quantify. Who gets to define "right" in this case?

Choose a platform, a language a framework. Define the specs and create and architecture. But dang, how do I know if it's "right?" It isn't when I say it's right. It's when the users say it's right. That's the key. Isn't it? If it doesn't fill a need - and provide a good experience - then it isn't right. Even if my architecture is perfect, my code pretty and I've got a green light on all my tests.

Yeah, I know, the "acceptance test" is the final test and of course if that doesn't pass it isn't right. But it is still possible to do something that is accepted, but still not right.

So, it doesn't matter if you use Ruby, PHP, ASP.NET (Web forms or MVC), mySQL, MSSQL, Oracle, Linux, Windows, Mono, Perl, TDD, BDD or any other software, tool, platform or framework. If you don't fill the need you don't win.

So I've decided on my toolset. It became rather obvious as to what I was going to use as soon as I started looked. I have to also admit that I had looked into CI before so I had a bit of an idea as to what I was going to use. Here's my list:

• CruiseControl.Net
• Subversion
• NAnt
• NUnit (would prefer xUnit, but I’m going to get setup with NUnit first).

So this is where I’m starting and will be the base set of tools. I’m going to probably add NDoc, FxCop and some other tools to the list soon, but wanted to get up and going quickly and the above list is the bare minimum I think.

Subversion and CruiseControl.Net are already installed and working just fine. NAnt, NUnit are on the CI server and ready to go. That was the easy part.

Like I’ve mentioned before I’ve mostly worked alone and inside Visual Studio so the biggest learning curve is coming from writing the build scripts. The XML configuration file for CruiseControl.Net is fairly straight forward. It isn’t the easiest thing I’ve ever done, but I’ve almost got my head around it. The biggest hurdle is writing the NAnt build files. Just a matter of getting my head around it. I’ll try to get some thoughts together as I learn it and post them here. It’s hard to say much while I’m still in the learning process myself.

Let’s talk a bit about CruiseControl.Net Configuration

I’m running cc.net as a Service. I’ve move the ccnet.config into a config subdirectory and added that directory to svn. My first project in the ccnet.config is one that watches the config svn repository for changes. The ccnet.config file is also simplified a bit. I’m putting projects in separate XML files and using entity definitions to include them in the ccnet.config file.

Here’s a sample of what my ccnet.config file looks like:

The cc-config project is used for watching for updates to the config file. I know that cc.net watches for changes to the ccnet.config file itself, but it was ignoring changes to the projectName.xml file. Adding this project seemed to overcome that and will refresh all the projectName.xml files whenever a change is committed to svn.

I’ll get into more detail in the project configuration files in a later post.

Ok. Things are changing around here. I have typically worked on projects solo and to some degree in a vacuum. I’m now working on larger projects with more stakeholders involved. This requires a change in my programming practices.

I learned a while about the importance of a version control. I’ve been using Dynamsoft’s SourceAnywhere (http://www.dynamsoft.com/) for about 3 years now. I like it and it has served me well. It was very easy to setup and get going for the newbie. All wasn’t perfect, but very good and easy. Everything was on my development machine which isn’t ideal, I know, but it worked for me. Now I’m changing my workflow a bit and my tools are changing to fit that workflow as well.

I’ve just started using CollabNet’s Subversion (http://www.open.collab.net/products/subversion/) and TortoiseSVN (http://tortoisesvn.net/) for versioning and SCM. It was fairly easy to set up and get started. Not as easy as SourceAnwhere, but not like painting the Mona Lisa either. Here’s a fairly good tutorial on the setup process http://www.west-wind.com/presentations/subversion/, but the Subversion and Tortoise documentation is incredibly helpful and well (and that’s saying something for free software).

As a side note: using TortoiseSVN and Subversion allows me to put anything under versioning control: Design files, Word docs, planning documents, anything. TortoiseSVN integrates with the explorer in Windows and with a right-click anything can be put into a Subversion repository.

I did miss the Visual Studio integration so the addition of one more piece of free software fixed that: AnkhSVN (http://ankhsvn.open.collab.net/).

Now instead of my versioning repository being on my development machine it is on a separate server for all of us developers to access.

The next step is continuous integration. I’ve got another developer or two that will need access to files as well as other stakeholders (and myself) who would like to know the status of the latest commits. Having a tool to build, test and generate reports when new code is checked in will be a great improvement to what I’ve been doing.

Over the next few posts I will outline what software and tools I’m using and how things are going. I don’t anticipate this being a lengthy process – nor do I see these posts being great tutorials – just pretty good information.

As I post other articles I’ll try to remember to update this one with links. If I don’t, well, just say something a bit mean under your breath and forgive me.