vss to svn – 7 steps to svn goodness

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”

🙂

Advertisement

Build and Release – a match made in heaven?

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…

A useful tip for variable substitution

Using QuickBuild for building and deploying apps is fun!  I’ve got 3 of my apps into QB now, and their build and deployment is almost completely automated.  I’m getting closer and closer to the Holy Grail of release management – the “magic button”.  You know, that button you push that just automagically a) pulls your code from the repo, b) builds and/or copies all dependent jars to the app local folder, c) builds (compiles and packages into a .war) the app and d) (the grand finale) automatically deploys the application to our Weblogic farm.

One thing we had to do (or rather, get the engineers to do!) was standardize on how we use environment-specific variables.  Obviously, for DB connections your best bet is to always use datasources whenever you can.  Then your apps just need to refer to those, rather than using database servername, db name, user, password, all that junk.  Not only does this streamline the migration from dev to qa to prod, but it also abstracts your database connection info, which is nice for several reasons (not the least of which is security).

But what about other variables?  What if your log location is different in dev vs prod?  Or what if you want to send error e-mails to a different address from qa vs prod?  You need to do some kind of variable substitution at build time.  Enter the .tmpl file.

Require (or ask, or beg, or bribe) your engineers to keep all of these “configurable” values in one file – typically an ApplicationContext.xml or something that looks like it.  Then, have them put the values for these variables in a properties file somewhere (app.properties or whatever).  The last step is to actually use a .tmpl file, and dynamically generate that .xml file using this instead.  If no values are passed through to the file from ANT or QuickBuild, then the app will just use the properties specified in the properties file.  But if you do want to pass them through at build time, all you need to do is create a variable for that config in QB (or ANT, if you’re not using QB yet!), and viola! – you’ve got the right stuff where it needs to be.

Subversion everywhere…

OK, so maybe we won’t use Perforce.  A mischevious consultant casually mentioned that a lot of his clients use Subversion, and essentially recommended that we use it too.  So now the management types have decied we need to evaluate and consider Subversion.  Fun.  We’ve been evaulating source control tools for about a year now, and we were sooo close to finally actually making a decision.  But alas, the saga continues.

It looks like Subversion is basically CVS with some improvements.  It’s all open source, which I suppose is kind of neat.  But along with open source comes all sorts of fun little troubleshooting.  At least with a commercial vendor, they’ll help us get things set up, and support us if we need it.  Of course, that kind of thing comes with a hefty price tag, and, well, you know, it’s not like our source code integrity is really a big deal or anything.  Certainly not worth spending a few grand to make things better.  Nah…

Also, the other fun thing is trying to figure out how to get our stuff from VSS into Subversion, while keeping all our labels and history and all that jazz intact.

Well, the good side of all this is:  we’ve thought this thing through to death, and whatever we do decide on, we’ll never be able to go back and say “oh, why didn’t we consider that?”.  It never hurts to be thorough when choosing a toolset you’re planning to have for years and years to come.

Scripting with ANT… Groovy

While ANT definitely is a great tool, and it’s benefits over MAKE well proven by now, it does have some limitations when it comes to scripting complex build and deploy tasks.  Well, not so much ‘limitations’, cuz it’s pretty open to extend it any way you could want. 

But anyone who’s ever tried to do something fancier than “grab code, compile, package into .ear file”, has had to get real creative with XML to get it to act like a scripting language.

Groovy looks like it could help make life easier for us build/release managers.

Article in JavaWorld… 

It’s even got an ANT Task.