I was talking with a couple of co-workers yesterday during an afternoon caffeine run and the topic of release engineering came up. This was more than likely because one of the co-workers is our release mgr / engineer. We talked about the various hats one has to wear when working in release engineering and ways to become more involved. Having done release engineering for a few years at a couple of startups, I should have become more involved before now but such is life sometimes.
I bring up an agile environment because we are currently utilizing the Scrum framework when developing. It's something we've moved to a few months ago and the projects I've been on have been greatly enhanced by it.
The question came up though is how release engineering and management fits into this agile style. I made the statement that release engineering is more important in an agile environment because of all the moving pieces. You have sprints going on plus release planning. You are supposed to be able to deploy at the end of each sprint though you don't have to. That's lots of things to keep track of and having someone or a group keep track of all those is definitely a good thing.
So what's the best way to move towards this? Here are a couple of suggestions I offered, though I'm not sure how applicable they are to everyone.
Know Where Everything Is Located
We have lots of projects going on at the same time as well as plenty of things just in maintenance mode. Trying to figure out which machines code lives on or what databases are involved requires lots of local knowledge. One of the best ways for a release engineer to be looked to for information is to have the matrix of what is located where with what version being run. This crucial information is locked in many heads right now so pulling it out will take a while but once it's out, don't let it lapse.
Get Involved Early and Often
Show up to a few daily stand-ups and especially be there for the sprint planning and release planning. You need to know the skeleton calendar for all projects so you can raise any possible red flags such as 4 projects trying to launch in the same week. By being at the meetings, you can reiterate the need for all builds and releases to come through your group. Yes, developers will not want to do this in every case. They will view you as an extra step that isn't necessary. Don't let that dissuade you, instead remind them that you will be in the one coordinating with QE and Operations and they'll be free to continue development or play Jenga (inside joke).
These two things are the most important parts I think of becoming more involved as a release engineer. Lots of other things pop up on your radar but having these two as foundations will go a long way.
Technorati Tags:
release+engineering, scrum, agile