Deployment?
I'm sitting here in Zurich with some colleagues working on some guidelines for teams who are starting to use Agile in an evironment formely exclusively RUP-based. We have a stack of Agile books, all by big-name authors, from which we are farming references for them to use. Not one of these books has anything (so far as we can find) to say about deployment, actually getting the software into the hands of the user. The very word is not in the index of any of them. Oops.
Subscribe to:
Post Comments (Atom)
6 comments:
Yes, support and deployment are the ugly cousins of software development, worse than testing. Give it a few hundred years and someone will finally tackle them :-)
Some simple goals:
1. Package creation should be automated.
2. Version numbers should bumped, even if the change is minor.
3. Installation should be 'fully' automated (if possible).
4. Rollback should be possible.
5. Multiple versions should be installable on the same box.
6. Errors should be easy to report.
7. Installations should be verifiable.
- There's probably a lot more, controlling operational complexity should drive some of the base functionality of the software (it doesn't have to be hard to deploy something, but it often is).
Paul.
What would you want them to say?
Packaging, system-testing, staging and deployment is very application- and organisation-specific.
@nat: Well, I think I'd want them to say that those who package, system-test, stage, deploy (and subsequently manage) applications are significant stakeholders. And that as stakeholders they have requirements (whatever the application- and organisation-specific details may be).
And these requirements must be met and planned to be met, and tests demonstrate that they are met, even. None of Paul's list of stuff above seems very context specific, and all seems quite valuable.
One of those folks that I was talking to today challenged a claim I made about automated functional tests. What if, he said, doing a genuine end-to-end test under production conditions involves, as it does in one of his projects, going and driving a train around and then looking at some telemetry?
Deploying a system like that takes a bit more than tagging the head of trunk and waiting for the servers in the basement to catch up. That seems to be what too many folks in the community at large seem to assume will always be the case. And maybe it will. Often, even. It would be nice of the thought leaders suggested finding out.
Even the latest fad for Software-as-a-Service (SaaS) doesn't really avoid the problem. The service provider still has to deploy applications and their updates into the compute cloud somehow.
It occurred to me that there might be something in the literature about continuous deployment, since deployment automation is a pre-requisite. I wasn't disappointed. Here's a selection of references:
* http://wiki.smartfrog.org/wiki/display/sf/Pattern+-+Continuous+Deployment
* http://safari.oreilly.com/9780321336385/ch08
* http://www.tacitknowledge.com/services/continuous_deployment
Tools include SmartFrog, Greentree and BuildProcess.
What the Agile books should say is that testing is insanely critical to the success of Agile. Because you are releasing more frequently, QA needs to be involved earlier and with tighter collaboration with development.
Because you need to hand off to QA more frequently, it is imperative that you are able to deploy to QA consistently, easily and with excellent traceability back to the the build and the tests run in the development environment.
Further, because we release more often, we should be really, really good at deploying. The deployments we do in QA should follow the same automated scripts we'll use in Production (albeit at a different scale) so that we not only test the software, but also the deployment process.
I think some of the commenters need to go beyond simply "I can deploy automatically" and consider environment provisioning and post-deployment validation. It's all very well being able to deploy, but that's no use if it takes 6 weeks to acquire the environment, a nanosecond to deploy, a week to validate the result and 100 handmaidens to reset the environment back to a usable state. These become significant factors on large projects.
Post a Comment