Release Planning
Releases in the Kanban Framework or Scrum Framework are planned to deploy delivered features from one or many iterations or Sprints. In more advanced environments there may be a Continuous Delivery model and infrastructure that looks to ship delivered features as an integral part of the value stream and forms a seamless Kanban flow from concept to shipped.
Discussions about the release plan should include:
- work items ready for release
- release approach for work items
- identifying risks and strategies to mitigate the risks to the release
- logistics for the release
Release Pipeline
A release pipeline that enables work items to be ready for release and are ultimately shipped can be setup and is a main component of Continuous Delivery.
The main intention behind setting up a release pipeline is to make it easier for teams to release in a repeatable way that avoids issues, manual intervention and ultimately removes failures from the deployment process.
A bonus feature of a release pipeline is the ability to gain feedback quicker, whether this is feedback on the deployment process itself and if it works or if there are issues, and also feedback on the delivered features. Features can be in the customers' hands quicker, their reactions and interactions captured, and any adjustments done ready and queued up for the next release.
The shortening time of the feedback loop then allows organisations to aggressively develop features with real customer feedback and evidence rather than forced into making a number of assumptions and then waiting for the product to be deployed in longer, and arguably lethargic release processes.
Automation
Using scripts to automatically promote binaries can help to gain feedback at the touch of a button, speed up the deployment approach and provide a repeatable process.
Teams that are able to script how their code is shipped and deployed inadvertently assume the ownership of how the binaries are deployed, which gives them a fine tuned approach to deployment that is repeatable and can be continuously improved to remove issues from the deployment process. Assuming the responsibility for how binaries are deployed then allows system administrators to execute the scripts and report back any issues with little intrinsic knowledge of the binaries or the systems that they affect needed, making the deployment process less reliant on single individuals and more resilient.
See Also
References
- Kanban, Successful Evolutionary Change For Your Technology Business, Anderson D. J., 2013