concept release in category software development
This is an excerpt from Manning's book Agile ALM: Lightweight tools and Agile strategies.
Running an unreliable, fragmented development process doesn’t empower a team to track and improve their work continuously. This is where software configuration management (SCM) can help. SCM helps improve the development process by tracking and controlling changes in the software. These processes are commonly implemented using version-control systems (VCS). SCM makes changes in the VCS visible, and it adds meta-information to the system to track why the change was made. Above all, baselines (identifying a specific version of the code suitable for release) and change-sets (linked to artifacts or work items) provide traceability to the development process and accelerate release management.
Figure 5.1. Integration and release management system: Sources and build scripts are shared in a VCS; a CI server builds, tests, and deploys versions; and a component repository stores ongoing versions as well as releases of the software (as binaries). Several roles and responsibilities exist; a release manager takes care of creating and staging releases.
A component repository stores binaries and acts as a cache for artifacts.[1] Binaries can be separated into snapshot versions and released versions. Snapshots express artifacts that are currently under development. Released binaries are final, baselined versions of artifacts that fulfill defined quality requirements. A release is a special type of version—either the version after reaching a deadline (in a timeboxed environment, for example) or the version that implements all requirements (tasks) and fulfills the requirements of test management. The release might represent a minor milestone (for instance, the completion of a sprint) or a deployable release candidate that includes all of the requirements expected for delivery to an end user. Typically, the sources that correspond to released binaries and that were produced by the team are labeled in the VCS.
Creating the entire release from a release branch is a good pattern. Doing so ensures that the main development can continue on the trunk without having any undesired side effects on your release. Imagine if some of the changes weren’t ready in time for a scheduled release. In this case, you’d want to revert the changes that aren’t complete, and this is much easier if you’re using a release branch that contains only the tested and completed features approved for the release.