Tue, 12 Aug 2008
You've gathered the requirements, written the code, debugged it, received the new requirements, rewritten the code, got more change requests, reached a 'compromise' with QA (and hidden the bodies) and now you want to have the sysadmins do the release.
Don't be like everyone else - when it comes to releases too many people fail at the last mile and make obvious mistakes. In an attempt to save myself some pain (and have something to point co-workers at) here are some of the software release principles that I hold dear.
Out of hours releases will have adequate support
Or as I like to think of it - "out of hours releases will hurt you as much as they will me. And a little bit more" If the release is important enough to require me in the office late at night or over the weekend then it's important enough to have development support and a manager present Just In Case. It'll also force people to be a little more considerate of my time and availability.
No live release will happen after 4pm (at the latest)
There's nothing quite as frustrating as getting two third of the way through a live release, hitting a problem or needing clarification of something that the staging environment didn't pick up (yes, I know it should have. Let's fix it for next time) and discovering it's 6pm and everyone else is already on the tube or in the pub.
You then have the pleasure of either backing the release out (if you actually can) and explaining why you killed the scheduled release or hanging around with half an upgraded system waiting for someone to get your voice mails and call you back. Which is even less likely to happen if you ignore...
No release will happen on the day before a non-work day.
Or the day the lead developer goes on holiday.
"We're nearly done. Can you get $dev to have a look at this line in the application error log please?" "Actually he's in Peru for the next three weeks. I'll get someone else who's never seen the system before to confirm that everything's fine." Apart from the obvious sign this is a made up conversation (application error logs that contain information - HAH!) I've been bitten by this a number of times. It always seems to end with some other poor developer with a postage stamp of hand over notes looking sheepishly at me while explaining that the log line could never happen.
You'll provide me with a list of what's changed
When you're developing you should maintain decent change logging above and beyond 'commit -m'. I'd like the world to agree that commit messages are for developers and release notes are for sysadmins; let's pretend I'm not paranoid enough to read the commits list anyway.
If you're using one of agile methodologies that uses stories for everything then feel free to put the story number in the notes to provide some background. However I still expect a one sentence summary of each change.
If you don't have a decent, and comprehensive, list of changes expect me to get... inquisitive about undocumented changes. I will diff the packages (better version of this coming soon) or source code (and if I ever get the time to look at SQL::Translator I'll be aggressively double checking your schemas). If you don't mention it I can't prepare (and add monitoring) for it, QA can't test all the new paths and I'll make a point of in the release retrospective meeting.
It should be possible to stagger releases across machines
I'm a fan of the one, few, many approach to software releases. I want the ability to role out the new system in chunks. I should be able to break off a couple of web servers so I have a warm standby just in case something goes wrong. I know this gets difficult to do once you involve databases but it's still a goal that should be considered - especially with read only copies of the data, replication slaves and data snapshots in the tool belt.
So in closing, I'm a demanding bugger. However, just like my Cron Commandments post, it's nice to have this list somewhere online to point people at.
Like this post? - Digg Me! | Add to del.icio.us! | reddit this!
Posted: 2008/08/12 22:12 | /sysadmin | Permanent link to this entry | This entry and same date
YAPC::EU 2008 - Not for me
Since I've been asked where about at the conference I am I should probably
mention that I'm not attending YAPC::EU this year.
Despite the excellent job the organisers did last year at the Nordic Perl
Workshop a combination of factors stopped me going back to Copenhagen.
The first one (and it's shallow but true) is that I've been there now. I like conferences in places I've never been before. If I'm going to spend a chunk of my own cash on travel I want to grab an extra day or two and have a wonder around. While Copenhagen was nice I did most of the city (and the mermaid, the river boat and got very sunburnt) last time I was there.
The second reason is there just ain't many interesting talks. While there are a handful I'm eagerly awaiting the slides from they are spread out over the entire conference. There are a number I've seen, a bunch I've no interest in (some in topics I already have a grounding in, some by people I can't watch for an hour) and only a few that I'd get out of bed early for. And we're not talking before ten am even for those. I don't think it's a perl wide problem - YAPC::Asia had a very interesting line this year and I'm sorry I missed it.
Add those two together and I can't really justify the time or money. So I've saved this years YAPC money and spent it on PyCon UK 2008 instead. It doesn't require me to suffer through an airport, I'm pretty sure I'll know almost nothing about any of the sessions beyond what I've seen on reddit and similar sites and, considering that work is all python on new projects it can't hurt for me to pick up some of the same technologies that our developers use.
Like this post? - Digg Me! | Add to del.icio.us! | reddit this!
Posted: 2008/08/12 15:35 | /events | Permanent link to this entry | This entry and same date
Yumdpkg-provides
I've never really felt as proficient with apt and dpkg as I did with RPM.
There always seems to be another option I've never seen before.
Luckily there are also big holes in my knowledge of yum to make me feel well
rounded.
After reading yum options you may not know exist and spending a while puzzling out how to get the same results in Debian (apt-file seems to be the closest fit but I never got the invocation right) I decided to write dpkg-provides.
It's not packaged, doesn't have a manpage, requires the network and isn't integrated with the existing tools. At least I know how I'd get the information now - from the web. Who'd thought it?
Note: it's actually quite simple to work out which package provides a file
that you've got installed locally (dpkg -S '*/df') - it's more
of a pain to probe packages you don't have installed.
Like this post? - Digg Me! | Add to del.icio.us! | reddit this!
Posted: 2008/08/12 15:13 | /tools/commandline | Permanent link to this entry | This entry and same date
Copyright © 2000-2010 Dean Wilson
