Process and roles within RLM and the orchestrated ALM suite vary from one organization to another, but the common goal is to control the processes that get the work developers have done through a defined set of testing stages and over to IT Operations teams with confidence that the requirements and approved changes are addressed and contained in the released production package.
A typical flow of information, tasks, and automations to and from external systems (Dev and IT-OPs) is as follows:
Release Managers may work with executives, business analysts, development managers, and IT operations to lay out a schedule of release windows for the organization’s IT changes for a future period of time, perhaps planning a year or two ahead. The Release Manager may create release trains in RLM so that these release windows are laid out on the RLM calendar.
Problems can lead to the creation of a Request for Change (RFC), which is a formal proposal for a change to the IT infrastructure. xxx which typical role in SSO creates these? xxx The Release Manager may associate RFCs with a release train to target these changes for a specific release window.
The release management team will guide the larger team to determine and document the scope, timeframes, resources, risks, and dependencies for the release trains to make the best planning decisions possible, with contingency plans for moving RFCs to earlier or later release trains if necessary to address changing situations.
Release Manager may create application releases as part of the project or product planning of an application. These are planned to coincide with particular release trains, with contingency plans for moving application releases to earlier or later release trains if necessary to address changing situations.
Business analysts may open Business Change Requests (BCRs), which are xxx. BCRs may be associated with an application release to target a specific set of changes for a specific release of a specific application.
Release engineers (managers? xxx) create release packages for sets of executables and supporting files that will be deployed to various testing and eventually to production environments. The release engineers will populate these release packages as the development deliverables become available.
Application defects and enhancements may be documented in Development Change Requests (DCRs), which are xxx. DCRs may be associated with a release package to target a specific set of changes for a specific release package.
Release engineers create deployment tasks, or deployment process templates for deployment tasks that are repeated release after release for a particular application. As more information comes available, more deployment tasks may be created, details may change, and so on.
Development resolves DCRs through their work on the software and unit test their work. When the unit testing is done and the software is ready for integrated testing, they create the release-ready baselines and these are ready to be picked up by RLM. xxx The baselines are added to the deployment tasks as deployment units.
Deployment tasks are completed and updated as needed from one test stage to another. Development may deliver additional changes and new baselines are selected for the deployment tasks and deployed along with the release packages to repeat a testing stage as many times as necessary or to move to the next testing stage.
When the baselines have been fully tested in the pre-production testing stages, the release package is deployed to the production stage.
History exists in RLM for the release processes, and the existing entities can be copied for future similar releases for ease of populating and repeating the release processes.