Chad Perrin: SOB

31 May 2007

10 tips for developing deployment procedures (or: Deployment Is Development)

Filed under: Geek,Popular — apotheon @ 07:56

People* have a tendency to think of deployment as something the admins do — if developers put any thought into it at all, it’s usually an afterthought, and not one that is considered very important. That is, of course, a huge mistake: deployment is a development concern, too.

  1. Have at least two (types of) boxes on which you test deployments at every stage of development. One should be an example of a standard machine in the production environment, and the other should be whatever close approximation you have as part of the development environment. That means that during development of a desktop application, for instance, you should at every major development stage test it on both an end user desktop system and on your own development workstation (or close equivalent). Make sure the thing deploys under wide-ranging circumstances, and ensure that if it doesn’t deploy properly during testing it hurts enough to make you consider deployment matters very carefully. For independent consultants, this may mean requesting a test box from the admins at whatever organization is paying you for development.
  2. Make sure you actually test deployment at every stage. It is becoming ever more fashionable to develop in stages so that at every interim goal you have something that actually runs when it comes time for testing and project specification assessment. When those interim goals are met, make sure you deploy and test as though it were the final deployment to the production environment, and make sure you don’t skip either the production environment test box or your own box in the deployment test (though of course you might want to try the test box first in case it blows up). Don’t consider the milestone reached until it deploys smoothly to both.
  3. Make sure deployment/installation is a largely automated process. Use scripts where necessary, employ the system’s software management applications for deployment where at all possible to integrate it with the environment and reduce confusion, and ensure no steps of deployment are missed. Have a complete, functional, automated installation process working and tested before you declare your interim goal met.
  4. Use automated testing scripts to verify that everything is where it needs to be after a test deployment, and make sure that it’s an automated, idiot-proof verifier so you can incorporate it in the final product. Ensure that, at minimum, it logs any discrepancies it finds so that you have a record of what went wrong during deployment, providing you with a neat and orderly to-do list of things to fix. Make sure that the end-user or sysadmin that will be doing deployment can use the verification system without your help, since somewhere down the line someone you’ve never met will be doing exactly that — guaranteed, assuming your software is good enough that it’s used more than once. Your verification should check locations, version numbers, and file permissions. Integrate your testing scripts into the automated deployment process. Actually use it yourself for test deployments, even on your own machine, and design it so that’s possible without a bunch of special-case handling.
  5. Make sure real human beings test the software after every test deployment to make sure it operates as expected at this stage of development.
  6. Keep necessary configuration to a bare minimum. Best of all would be to have no necessary configuration options at all, with the possible exception of asking whether custom configuration options are desired. Provide opportunity for custom configuration, though, in case something nonstandard is desired.
  7. Provide easy rollback in case of a failure. Test the rollback every time. You should keep track of original system state, and include an automated “undeployment” process for returning the system to that state. This should, just like all other operations, work on both the test machine and your own machine, without any special case handling necessary. Provide opportunities for custom configuration of the rollback procedure, and for some sysadmin you’ve never met before to use only parts of the automated process in combination with manual changes if necessary, but make sure that no user interference is actually required for the rollback procedure.
  8. Follow these guidelines every time. You may think a given project is not big and important enough to bother, but if it’s small and unimportant that just makes it easier to follow these guidelines. I’m not perfect — I don’t always follow these guidelines myself. I should, though, and I intend to do so a lot more in the future. Practice makes perfect, and you definitely want things to be as close to perfect as possible — right?
  9. There’s no excuse for deployment failure. If deployment fails, it means you forgot to account for something. If someone tries (and fails) to deploy it on the wrong type of system, the problem is that you did not account for that type of system — not that the choice of system on which to deploy it was wrong. If some other piece of software changed things so that your deployment didn’t work, the problem is that you did not account for the potentially varied circumstances in deployment. You may not want to tell them that it’s your fault, but you should think of it as your fault anyway: even if it’s because the guy deploying it is an idiot, the problem is that you didn’t make deployment idiot-proof enough.
  10. Extra Credit: Voluntarily test-deploy other people’s software on your system all the time, and help them solve their deployment issues as much as possible — but without actually doing development for them unless it’s specifically appropriate for you to do so. Being on the other end of the developer/deployer divide can help you hone your sense for how to develop high quality deployment procedures for your software. The more you know about what your software is going to be doing, and the conditions under which it’s running — and the more you know about the problems of others’ software deployments — the better you’ll be at developing quality deployment procedures for your own software.

That all adds up to being a better developer with happier clients. While you may consider deployment an “admin problem”, I guarantee most admins and end users think of software that’s difficult to deploy as a “developer problem”, and whether you think that’s fair or not, it affects your success and reputation as a developer. After all, if it doesn’t deploy, it doesn’t work.

* We’re assuming developers qualify as “people”, here.

(Credit where it’s due: This was in part inspired by Justin James’ Time to improve application deployment and a comment to it by Wayne M. titled Deployment Philosophy.)

21 May 2007

epigram: copyright vs. immortality

Filed under: Cognition,Liberty — apotheon @ 01:02

The likelihood that an idea will endure is inversely proportional to the lifespan of its copyright.

In other words: Ideas that are committed into the domain of the public upon inception are more likely to survive into posterity than those whose archiving, distribution, and freedom to pass from one mind to the next are restricted by monopoly power.

(originally HERE)

20 May 2007

a casual review of 28 Weeks Later

Filed under: Review — apotheon @ 04:32

I watched 28 Weeks Later in the theater with friends last night. This was the sequel to 28 Days Later, a well-made “zombies are FAST!” movie from a few years ago that begins with a man waking from a coma 28 days after the fit hits the shan (as ’twere) in London. As one might guess from the title, 28 Weeks Later takes place about 28 weeks later, when the situation appears to be under control and people are starting to repopulate Britain.

The special effects were good. Scene direction, overall, was good. Acting was good. The plot was good. The script was passable, in general, though not as good as that of 28 Days Later.

The story execution was not so good.

The cinematography was downright awful. Sure, the shaky hand-held camera thing can be good for effect, useful to instill mood, and so on — once or twice in a movie — but when something like 80% of the movie is that way, there’s a real problem. Flickering lights can be useful now and then, but a regularized strobing that just seems to go on forever is a monumentally bad idea

There were little plot problems. I’m thinking of things like that scene in the huge underground room, something like a basement or parking garage, where probably hundreds of people were herded in “for their own safety” and locked in. Think about it — they put them in there, lock them in, then turn out the damned lights. Then, of course, nobody guards the doors. Next thing you know, they’re infected by the zombie that broke in through the back door. Yeah, good plan. I mean, sure, you could make a case for them having been herded in there just to keep them out of the way while you go warm up the napalm, but that doesn’t fit considering the napalm solution didn’t come along until much later.

Other small plot problems included the idea of having the snipers take out individual people after it was determined that target selection was pointless. Why bother? Just evacuate them and nuke the place if you’re going to kill everyone anyway. The only reason to have the snipers shoot anyone not infected in a real-world situation like that would be to keep them away from places you don’t want them going — otherwise there’s no damned reason to waste the time, the bullets, and the soldiers.

There were a number of other minor problems like that.

Then, there were the major problems. Aside from the cinematography, the single most unwatchable thing about the whole movie was that ridiculous damned scene with the helicopter killing zombies with the rotor blades. What the hell? Are they taking cues from Grindhouse now? Who thought this was a good idea, and why isn’t he dead?

The best thing about the movie, I think, was the way they made reinfection happen. That was interesting and (mostly) believable (there’s always the problem of why Mum wasn’t under guard, but I’ll ignore that in the interests of suspension of disbelief). The second best thing was probably the napalm (oooh, pretty).

Don’t go to this movie expecting cogent and incisive political statements — anyone who tells you otherwise is reading his or her own political leanings into the movie. Don’t go expecting to be swept away by a compelling character-driven story that wrenches at the heartstrings — it was all pretty emotionally tepid, all told, with the exception of the constant annoyance with the stupidity every single non-military character in the movie (and some of the military characters, but in more abstract ways that don’t generate as much annoyance). Don’t go to this movie at all if you’re prone to motion-sickness — the filmmakers seem to have thought they’d win an Academy Award for emulating the cinematography of the most confusing parts of The Blair Witch Project throughout the entire damned flick.

In fact, just skip the movie. See it in the dollar theater when it leaves the main theaters if you must, or download it for free (note: I cannot recommend illegal downloads, blah blah blah). It’s really not worth the money to pay full price for major theater, ownership, or even rental.

I saw a trailer for Resident Evil: Extinction, which is apparently coming to theaters this fall. Hopefully, that won’t be as disappointing as 28 Weeks Later or Resident Evil: Apocalypse.

Older Posts »

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License