Check out this nice write up about build automation.  In particular, note the bit about keeping tabs on code quality.

I think it’s often overlooked that “quality injection” is a huge benefit of CI.  Yes, it’s all well and good that your code compiles, but that doesn’t really tell you much about the quality or give you any useful metrics you can act on.

There’s a handful of utilities out there that you can tie into your build to collect info about your codebase (checkstyle, coverity, simian, findbugs to name a few).

Point is – when you start thinking about how you can leverage your automated build to inject quality into your process, things can get really interesting.

One of the challenges of investing the time and effort into pimping out your build and ci setup (or more generally, CM processes) is how to measure success. Where’s the ROI in having your top dude spend days writing ANT scripts?

Check out this great post about how to measure your success with change management.

We just released a redesign of justinlittle.com, check it out and let me know what you think!

As always, it’s a work in progress, but at least I’ve got a decent base to work with now…

If you like the design/layout, check in with Sleepless Media out of Santa Cruz, CA.  They did the design for me, and they’re a great team to work with.  I hacked up the html/css a bit (hey, what can I say, I’m not a design guy), their original stuff was even tighter.

They do really, really nice stuff, check out their portfolio of work.

This sounds like a pretty good match-up:

http://www.sqazone.net/modules/news/article.php?storyid=426

This is hilarious.  Agile Hitler.

I hadn’t realized quite how fitting my tagline was when I started this blog.  The “care and feeding” of software is one of the main roles of a release manager, or anyone involved in managing change to software for that matter.  It occurred to me today, that software has a lot in common with living things, more and more every year.

“What?!” you ask?.  How is a web based app like a living organism you wonder?  Well, there’s a lot of similarities, and it makes for a good analogy.  We’re decades into software engineering now, and we’ve discovered a lot of stuff along the way.

One key development I’ve noticed is that more and more, organizations (both software consumers and creators) are beginning to realize that developing apps is less like mechanical engineering and more like giving birth.  I’ve even heard people use giving birth as an analogy, and we’ve all heard some kind of app referred to as “my baby”.  It’s no longer an exercise of “identify requirements, design, code, test, release” in isolation – it’s a nearly never-ending repetition of this cycle.  Agile methodologies are compelling because they acknowledge this at the outset of a project, and cater to this reality.  Software is never “done”.  If it is, so is the company that made it…

Mechanical or even electrical engineering approaches are not really suited to software.  Sure, they provide a framework for getting things done, but there’s a key difference between what’s typically been “engineering” and the engineering of software solutions.

Engineering: the art or science of making practical application of the knowledge of pure sciences, as physics or chemistry, as in the construction of engines, bridges, buildings, mines, ships, and chemical plants.

Rarely do people start off to develop some kind of app, thinking they’ll “nail it” in version 1.0, and never need to spend more time/energy on it.  Certainly, there are phases in the development of an app, as there are in the life of an organism.  So while it is an ongoing cycle (the SDLC), there is a sort of linear path that an app goes through, that’s made up of each of these iterations.

In this 5 part series, I’ll ponder the following topics:

1. Definition of an “application”

2. Comparison of an app with an organism

3. Trends in software design, development

4. Release manager, build engineer as doctor, triage nurse

5. What does it all mean?

Hyperlink Legal has just launched their website. They’re a small company, specializing in creating hyperlinks in PDF docs for the legal industry. Check em out!

www.hyperlinklegal.com

Shmoop has just been released to the general public, check it out!  Shmoop is a learning aid, providing tons of awesome content about History, Literature, Poetry, and more to come.

It’s still in beta, so there’s bound to be some stuff missing… but it’s an swesome start!  I wish this was around when I was in school!

Using Subversion for source control is all the rage these days. Everyone’s doing the svn dance. In fact, my most popular blog posting is about vss to svn migration, so at least it’s a hot topic here anyway. I assumed there’s lots of people making the switch out there, and figured I’d write up a few things to think about if you’re considering the move.

Why subversion? Mostly because svn just works. It’s a great little tool for doing what you’d expect of a solid source control system. It’s lightweight, so you can use it just about anywhere. Also – it’s free, which is always nice. There are plenty of other options out there, and each have their merits. This particular post is about the journey from vss to subversion.

1. Why? Are you sure?  Switching source control systems can be a real pain, especially if you’ve got a boatload of source. It’s definitely worth the effort in 99% of the cases, but sometimes the payoff just isn’t worth the disruption. If you’re a heavy Microsoft shop for example, you might want to consider jumping in with both feet and just moving on to the whole Team Foundation thing.

That being said, subversion rocks. Use it.

2. Preparing the new repo – You’ve got to install subversion somewhere, and create your new repository.  You’ll need to decide if you want to use the svn: or http: protocol to access your repo remotely, most people just tunnel it thru apache over http:.

You’ll want to start off with a nice clean, standardized layout for your new repo.  A safe bet is to use the old “trunk, tags, branches” route, with some default dirs in place (src, web, db, qa, lib, whatever).

If you’re not sure about installing/hosting it yourself, there are a handful of places that’ll do it for ya (dreamhost, cvsdude, … )

3. Exporting the stuff from vss -  The trick here is to do it cleanly.  You’ll most likely end up needing to delete all the .vssver files and whatnot.  Also, decide if you really need the entire history of files in your new repo… that could get hairy. Migrating to svn AND keeping all of your checkin history intact in svn is outside the scope of this posting. We decided we didn’t and kept a backup (read only) copy of the old vss db around “just in case”. You know, in case we ever needed to refer to something 3 or 4 years old.

Guess what? We never looked back.

4. Importing the stuff to svn – This is where it can get fun.  You’ll want to map your existing vss repository’s directory layout to your shiny new one. I ended up using a little perl script to get them all added into svn correctly. (vss2svn.zip)

5. Updating other various things and people -  You may have some existing systems already pointing to your vss repo, make sure to list them all out and get em updated. We had a handful of build scripts that needed to be update to point to the new repo.

Also, be sure to communicate effectively to your team. You might even need to do a little PR for the effort, so make sure you’re clear on #1 above. Provide your users with ample docs and support info to make the transition easier. Maybe host a couple “svn how to” sessions, to get things moving.

6. Testing This needn’t be too complicated, just walk through a handful of typical use cases. For example, do a few svn checkouts, make sure you can connect and everything’s cool, try a build or 2 from svn, etc.

The key here is to find and address (or figure out workarounds to) the most likely issues, and be ready to help your users get around em.

7. Relax and have a beer You’re off! Now just relax, watch your source get modified, and start forgetting about “vss analyze and fix”

So I’ve taken to digging a bit deeper into the build side of things, so please don’t be upset if this turns into more of a build automation blog… It’s just where I’m spending a lot of my time lately.

I’ve started to see Release Management as a bit closer to the business side of things, and looking at what I do as more “build and deployment automation”. At my previous job (where I was when I started this blog), I did pretty much everything form managing SVN, to automating builds and deployments, to managing a bunch of servers. Since getting out of Academia and into the “real world” of business, I’ve noticed that these roles tend to be a little more separated.

Now that I’m consulting, I even made a little online resume thingie for your enjoyment – check it out!

http://www.justinlittle.com/

I am available for consulting too! Wouldn’t it be neat to be able to say you hired the guy who “wrote the blog” on release management?

Right now, I’m working on helping a small software company in Silicon Valley automate the heck out of their build. We’ve got a desktop app written in C#, and we didn’t really have any automated builds at all. It’s pretty cool walking into a place that has a clean slate, and being able to completely build out a system from scratch.

I can’t really say I love working with MSFT products anymore, I think I’ve gotten spoiled with the explicit and transparent nature of working with Linux/Java stuff. It seems like MSTF is trying to do everything for you, which is cool until things start breaking and you need to troubleshoot. OK, that’s my mini MSFT-bashing rant, I’ll stop now, I promise.

So Bill G and the Gang have some pretty interesting little tools together, most notably MSBuild in conjunction with Team Foundation Services. I can’t say I love it, but it does (sort of) work. I pretty much eschewed their whole solution, and just wrapped a call to MSBuild inside my ANT scripts, and then wrapped that in CruiseControl.NET for scheduling of builds and for email notifications on builds events. It all seems to work pretty well, the only real hiccup was getting ANT to play nicely with Team Foundation’s source control.

I just use the tf.exe command line client form an exec inside my ANT script, but it’s not pretty. Mostly cuz doing a “get” makes everything read-only (kinda like vss), and that doesn’t really work for me cuz the build actually produces some artifacts/shuffles around some files. Since I don’t really know what MSBuild is up to behind the scenes, I ended up just making them writable after “get”ing them using hte old “attrib” command. Weak sauce.

Other than that, CruiseControl.NET seems to be pretty happy. We’ve now got nightly builds popping, and all is good in the world. Now if I could only get my hands on a decent GUI based testing tool for WinForms, then I could run a handful of smoke/regression tests after the build happens, so we know we didn’t break anything…