Why an RM blog?

When I first started working at my current job 7 years ago, there were just a few of us managing the web content for the whole organization (a grad business school).  At that time, there were a handful of departments with sites, and a few faculty members were starting to put their course material online.

Since then, we’ve grown into a full-blown software development crew, inside the school.  We’ve got a dozen or so engineers, biz analysts, a QA team, a few more layers of management (fun!), architects, plus a whole offshore team in India. 

As we’ve grown, we identified a need for someone to focus on some of the administrative stuff involved with supporting a team of engineers.  First it was VSS, then we needed a slick defect tracker, obviously.  And, of course, we need a central way for apps to get deployed to servers, so we don’t have chaos in the production app environment.  And, well, to make sure what we test in QA is gonna work in prod, we’ll need a process to make sure they’re the same.  And on it goes, you get the idea.  I became that guy.

It’s not really Windows admin, or Unix admin either.  But I gotta know IIS and Apache inside and out, and .NET, Tomcat, Jrun and Weblogic too, just for fun!  It’s not quite web development, tho I’m often tweaking vbscript or perl or jscript or C# or whatever the heck we’ve got runnin.  It’s not quite tech support, though when something’s broken in production, chances are I can get it sorted out (and I better!).  It’s a cool spot to be in, getting to see everything come together, and getting to tackle all sorts of interesting problems.  But it definitely presents some unique challenges.

I was having a tough time finding a good source for info about dealing with these kinds of issues.  Sure, there are phat software suites that’ll do everything from resolve merge conflicts to do automated nightly builds and tests, blah, blah, bah.  But unless you’re building huge, hardcore apps with serious development discipline and strictly enforced processes, those things can be a bit too much.

All you really need is a decent source control system, a bug/issue tracking system, and some solid processes and strategies to manage how to push code through it’s natural lifecycle: development, unit test, deploy to qa, controlled test (and sign-off), deploy to production.  Of course, you gotta track and manage all sorts of dependencies too: inter-app/service/server dependencies, restart orders, branch/merge issues, etc.  I just couldn’t find a place to discuss or research all sorts of general release-related issues. 

As I was bitching about it one day a friend says, “dude, sounds like a good opportunity for a blog.  You should make one”.  And so it goes, another blog pops up on the web… 

Advertisement