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… 

Advertisements

3 Responses to “Why an RM blog?”

  1. Wayne Says:

    Hello,

    Quest has recently released a release management solution for distributed custom applications. Foglight Release Manager provides deployment automation, enforces separation of duties, and audits the deployment process for business-critical distributed applications.

    I was wondering if you would be interested in taking a look at the product.

    Please let me know at your earliest convenience.

    Thanks.

  2. fedellisaz Says:

    zaebalo hule ti ne postish ku4ka
    daesh posting!

  3. Tom Says:

    I read this and chuckled. I totally relate having gone through the same transition for nearly an 8 year period. Now starting again. Being in the thick of things has both its challenges and rewards!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: