Works on my machine

Are you really making your builds with Visual Studio? Please tell me you aren’t using VS in the command line to compile your application. You do realize there are better ways, don’t you?

Some suggestions:

• Use a command line tool such as MSBuild or nant for long running builds – VS takes a while to compile a long running build because of the visual feed back it provides. It does a fair job and all, but it’s not going to beat running msbuild or nant. MSBuild is the easier of the two to pick up because it knows how to use the solution file as the build script. With nant, you have to write your own. For both, you will need a separate script to do things like deploy files or run unit tests.
• Use TeamCity or CruiseControl.net to automate your build process – CruiseControl and TeamCity will help you automate your builds. CCNet requires build scripts; TC does not.
• Automatically pull updated source code – have your build process pull updated source code each time. This way you can take some of the pain out of the build process and find out if the build works.
• Run your automated builds on a separate machine or different folder – Meaning, don’t run your automated build in the same place you work on your code. This avoids the “works on my machine” problem.
• Use known tools – Sure you can make your own build server, but should you? Look for known tools which you can extend or configure to meet your needs. Building your own for your special circumstance will likely bite you later when that special circumstance changes; or you just outgrow it.

Building your application doesn’t have to be painful. It doesn’t have to result in moans and growns when you find things are missing. You can automate it with moderate or little effort, and then let it run often. You will get a better idea of how your work is going and find out more quickly. This is basically what Continuous Integration is about. It’s not hard, and you will see the benefit quickly.

Git move part 2

Just so you know, we are starting the move from googlecode to github. There was a little re-org of the code so some projects won’t build yet, but the repo is there. We’ll update the site with the github link when everything is compiling. Also, we might add a project page on computeristsolutions.com. Feel free to vote for a project page in the comments if you are so inclined.

-j

Hello Git

We just moved company code from subversion to git. And I’m very happy about it! Over the years, I’ve used Visual Source Safe, ClearCase, CVS, Subversion, and now Git. Of those, Git is my new favorite. Yes, I’ve heard good things about Mercurial and bz; just haven’t used them. I’m currently working with someone who has some good points on TFS too.

The reasons are simple: performance, local history, distributed repositories, easy merges, and selective change sharing.

We have a master repository currently on unfuddle (recommended). Commits and merges are so ridiculously painless and performance is so much better, that small and frequent commits are just natural. We haven’t really taken advantage of the branching features yet, but feature branches are something I intend to play with.

Next up, moving our open source repository to GitHub. I expect git tooling will improve as more people use git on windows. For now, I’m using msysGit and command line tools.

-j