When the release candidate is ready for production, your team will most likely have to manually or a partially automated deployment process. It may require coordination between multiple groups within your organization like a DBA, IT staff, and release engineers. Since they do not write any of the code or produce the artifacts, they are unable to deal with any failures that occur during the release process.
The longer the intervals where your team performs an activity, the less likely they are to fix any process bottlenecks. The beauty of extreme programming is that it uses "continuous process flows so that problems rise to the surface". Take for example the practice of quarterly releases, forcing the team to commit to having a maximum of 3 months between releases exposes bottlenecks in your teams software process.
Ideally you want your product to be releasable on a daily basis and your team should be able to perform a deployment upon each and every commit to the source repository but that takes of lot of discipline, automation, "correctness", and changes in attitude. Realistically, you will have to make little changes to help enable your team to practice "small releases". Here are a few to start with:
- Work with your product owner so that the next release of your product occurs withing the next 3 months. Get them to work with you to build enough slack into a release
- Work with your production team to automate all aspects of your release process
- Write component, unit, and acceptance tests and make them part of your build process
- Train your BA and QA team to use exploratory testing techniques instead of performing full fledged regression testing
- Automate your smoke tests with tools
No comments:
Post a Comment