VSS to Subversion migration

Sorry for the dearth of posts lately, I’ve just been having too much fun with Subversion to post. Bad Release Guy! That, and about a hundred releases or so…
🙂

We have finally *officially* decided to use SVN, rather than Perforce. I’m actually pretty happy about the decision, I’m finding SVN to be a nice, simple, straightforward source control system. It doesn’t have all the “bells and whistles” associated with Perforce or ClearCase, etc., but it is a solid tool and does what a good version control system should.

The setup and install was pretty trivial, not a big deal at all. The only remaining item is to tie this thing up to my local authentication/authorization system. It’s proving to be more of a pain than I had hoped, and I’m not thrilled about just using SSH or Apache’s basic auth to control access to our repository.

I’ve put together some VSS to Subversion migration scripts (in perl) that have worked out quite well. It’s basically just a simple “get latest and add to SVN”, no labels or file history or anything gets moved over, but I’ve noticed the “VSS way” of doing things is not exactly based on best practices anyway. So we’ll just keep our old, VSS repository around in the meantime in read-only mode, in case we need to do some historical reporting.

If you’re interested in checking out my VSS to SVN migration scripts, have a ball!

Advertisement

Release Management – QA or engineering?

There seems to be some debate around where in an organization Release Management really belongs.  Is release management a function of engineering, or is it a function of quality assurance or quality control?  A case can be made for both, or neither.

On the one hand, release management is certainly a function of engineering or software development.  What good is a slick piece of code if it can’t be integrated, tracked, and released into the world?

On the other hand, the release manager is the last line of defense for what actually gets deployed.  So in that sense, the release manager must be acutely aware of quality issues.  Obviously, the release engineer can’t be completely in on all the requirements or business needs – that’s outside of his scope.  However, he must be aware of things like system resources, monitoring, logging, etc.  All the things going on behind the scenes to ensure quality of response and uptime.

Release Management as an engineering function

Often times, relatively small software development teams don’t recognize or appreciate the need for a central resource to handle build, deployments, and environment maintenance.  Typically, you’ll find one engineer in the group who’s familiar enough with SCM systems, web services, UNIX/Windows admin, etc to step in and fill the role.  Depending on the size of the team and the complexity of their development processes, this is often sufficient. 

In any case, someone needs to take ownership of these issues, and that someone should have at least some knowledge of complex systems and how applications are built and deployed.

Release Management as a Quality function

The release manager definitely needs to work closely with the QA team, in order to properly plan and allocate resources to test apps before releasing them into production.  In some cases, the release manager can help a QA engineer determine the nature of a bug, and whether it’s an environment/server config issue, or simply a bug in the app.

My humble opinion is that release management sort of “straddles” both engineering and QA, and as such really belongs in either it’s own organizational unit, or could fall in with operations/IT management.  I guess it really comes down to how your team is organized and what the real needs are.