Release Management in the system provides Release and Deployment Managers with a centralized repository for managing the introduction of changes, regardless of size or risk, to the environment. Two examples for rolling out a Release are detailed below, as Releases can potentially be very complex, which requires great flexibility in the system.
The first example illustrates a software rollout, with software being upgraded, replaced and a couple of new installations. Although this Release may be considered a little complicated, the nature of the Release is low risk. Due to the minimal business criticality level of the Release, it has been decided that this deployment will not be controlled by Change Management. The second example that manages the update of Microsoft Exchange, a higher risk Release, controls the Deployment with Change Management.
Before commencing the examples, the system needs to be configured to handle Release Management and the following elements must be in place:
Users assigned the Release & Deployment Process
Release Objective: To rollout the latest update of Office 2008 to customers. Replacing existing software for customers that have Open Office, and installing new software for customers without access to any Office applications.
The example will apply the system default Release Workflow that includes an added Workflow State of Trial Deploy and also has a number of Approval States. It includes Deploy and Trial Deploy States as the Workflow stages for creating the related Deployment Tasks in the system.
The Release Team that will action the Deployment Tasks has also been divided into three Groups: Software, Hardware and all Deployment Technicians.
To create the Release:
Go to Change>Releases
Click New
Complete the Release information
Release Fields |
Description |
---|---|
Name |
Enter a Name that reflects the objective of the Release. |
Priority |
Set the Priority, which will correspond to the target timeframes for the SLAs associated with the Release via the RFCs. |
Team |
Select the Release Team who will oversee all part of the Release. |
Workflow |
Set the Workflow that includes the relevant stages to manage the Release. The Release Manager moves the Release through the stages of the Workflow, relevant to the events being undertaken and completed. |
Status |
This is set to the Default Entry State of the selected Workflow. |
Next Action |
Based on the assigned Workflow, select the next Workflow State for the Release, as required by the next Release activity. Some States are Approval States, when the Release moves to an Approval State the Approve and Reject options are visible. The Release Manager selects the appropriate option and the system automatically moves the Release to the pre-configured next State, relative to the option applied. |
Manager |
From the drop-down list of Managers assigned to the default Entry Point of the assigned Release Workflow, select the Release Manager to manage the project when it is initially created. The User defined here, is the Manager who can edit the Release after it is saved and then move it to the next State. |
RFC Control |
If the Control Deployments via RFC option is enabled in Admin>Setp>Privileges>Requests, this field will be displayed. Select Yes if the Deployment is to be routed through Change Management, to enable the scheduling of Deployment Tasks. Select the RFC Workflow to manage the Change Request associated with the Deployment, and set the default open State or Deployment State for the Tasks. |
Description |
Enter information that describes the goal of the Release. |
Select Save.
From the above screen snap, we can see that Simone Supervisor is the Release Manager assigned to the Release and that the Release is of low Priority, will be handled by the Release Team and managed using the Release Workflow. The Release is currently in the default entry point of the Release, the Plan State. It should be noted that moving through the Release Workflow is determined by your organization's business processes and the defined Workflow. The system is to be used as a central repository to manage Releases and a point of reference to keep all relevant parties updated regarding a Release.
To associate the Items that are to be created or updated as part of the Release, the Release Manager has to define the reason for the Release and assign the relevant Item Type to the Release. This is achieved within the Item Types tab of the Release. For our example, there will be three reasons for the Release:- Upgrade existing software, replacing existing software and installing new software.
As a Release Manager, to assign Item Types to the Release:
Select the Item Types tab inside the Release information screen
Click Edit
Click Add
Assign the Reason of Update
For customers with Office 2008, based on the system configuration within the CMDB Item Type of Office 2008, we will just be updating the software version number in the Item Details tab.
Search and select the Item Type Office 2008 in the Find Item Type field
When the Item Type is associated with the Release, the fields available on the Details Tab of Items using the Type are displayed.
Enter the information that is to be updated against the Item in the CMDB and Save
For our example 2011 will be entered in the Version # field.
To replace Open Office with Microsoft Office 2008, click Add
Select the Reason of Replace
The Find Item Type field is displayed next to the New Type field.
Search and Select the Item Type to be replaced within the Item Type field
For this example it is Open Office.
Select the Item Type link for the Item Type to be replaced
Search and Select the Item Type that is to replace the existing Item Type
For this example, Office 2008 is the replacing Item Type.
Select the Item Type link for the Item Type information to be replaced
The fields contained on the Details tab of Items applying the Item Type are automatically displayed.
Enter information into the fields that are to be updated on the Items in the CMDB
For this example, the Version # details is updated to include 12.0.3.
Click Save
To create new Items in the system, click Add
The Reason of New is assigned by default.
Search and select the Item Type to be applied to newly created Items in the CMDB
For this example, new Items using Office 2008 are being created.
Assign the Item Type to the Release
The fields available on the Details tab of Items using the Type are displayed.
Enter the information that is to be updated against the Item in the CMDB
For our example 12.0.3 will be entered in the Version # field.
Click Save
After all Types have been assigned to the Release, move the Release to the next relevant State.
For this example, the Release moves to Plan Approval and approval is given. The system automatically moves the Release to Build.
As the Release is not to be managed using Change Management, the Release Manager can move directly to the Deploy tab to create the Deployment Tasks.
Deployment Tasks, the activities completed by Technicians included in the Release Team Groups, are created in the system by considering the physical location of the Customer or Organizational Unit. That is, when grouping the tasks that are to be completed as part of a Release, the system presents the information based on Customer location so Technicians can be deployed to specific locations to complete jobs.
Tasks can be created on a per Customer Deployment basis for Items that are assigned specifically to Customers. Or, for Items that are shared across Org. Units or by an Org. Unit, the Create option of Deployment per Org. Unit can be used for creating the Deployment. The Global Deployment option allows the Tasks to be created for the whole Organization as the Item being updated, created or replaced is owned/accessed by all Customers in the system.
Once the Customers are assigned to the Deployment, either directly or via an Organizational Unit the Release Manager must define the Group of Technicians within the Release Management Team who will action the Tasks and set the stage of the Release Workflow for the Deployment Tasks to move into an Active State ready to be completed by Technicians.
To create the group of Deployment Tasks:
Select the Deployments tab inside the Release information screen
Click New
The screen expands to show the options for the type of deployment to be created, the list of Customers who own an Item associated with the Item Types included in the Release Types tab and the Search Options box.
Select the type of Deployment that is to be created
For this example, per Customer Deployments will be created as all Items associated with the Release are owned directly by Customers. The list of Customers can be sorted into Org. Unit groups by clicking the toggle in the Org. Unit Column Header.
Assign the Customer(s) to the per Customer Deployment by selecting the field next to the Customer name and clicking
The selection is included in a Selected Customers window to the right of the main window. When all Customers are assigned to the Deployment, the group of Technicians who will action the Tasks and the Workflow State where the Tasks will become active in the system must be defined.
Click Next
Select the Group of Technicians who will work on the Deployment Tasks from the Group drop-down list
For this example the Software Technicians will be assigned.
Assign the stage of the Workflow where the Deployment Tasks will become active in the system
As the Release is related to simply upgrading or installing Office 2008, the Deploy State will be assigned as the action State.
Select the Items to be included in the Deployment
For this example, as the replacement and upgrade of Items is simple software, all Items will be created as one Deployment that will result in individual Tasks being created.
Click
Click
For the new installations of Office for customers select within the Items field
Tick the relevant Item Type and define if the Item is to be shared or one created for each Customer
Click
Click Done.
All Tasks are now saved with a Status of Pending assigned. When the Release Workflow moves to the Deploy State, the Tasks' Status will automatically by updated to Open, prompting Technicians to complete the Deployment Tasks and move their State to Closed - Resolved. When all Tasks are completed and moved to Closed - Resolved, the Release will be automatically Closed.
The Deployment activities created within the Deploy tab of the Release are listed in the Deployments and Deployment Tasks tabs of Change in the system. The Release Manager works the Release through the assigned workflow within the Details tab of the Release. When the Status of the Workflow is set to the Deploy State defined within the Deployment, the Tasks will move from Pending to Open.
For this example, within the Releases>Release#>Details tab the Release Manager has moved the Release through the Workflow States of Plan, Plan Approval, Build, Test and is currently assigned the State of Deploy Approval. Selecting Accept will move the Release to Deploy, and the associated Tasks will automatically move to Open.
Within the Change > Deployment Tasks tab, Technicians can edit Deployment Tasks by adding Notes using the New Note button, which are stored in the Notes tab, or update the Status of the Task to Closed-Resolved. When all Deployment Tasks are completed, the Deployment is automatically closed by the system. When all Deployments are closed for a Release, the Release Manager can close the Release within the Details tab, by moving the Release Workflow Status to the Exit State.
Item details in the CMDB are also automatically updated, based on the information included in the Release.
Although this is considered a less complex activity as it involves only one Item, due to the business critical nature of Exchange the risk is higher. Therefore, as a Release Manager, it has been decided to manage this Release using Change Control. To manage Deployments using Change Management, ensure the Administrator has enabled the Control Deployments via RFC option in the Setup>Privileges>Requests Tab.
Release Objective: To update Exchange to Microsoft Exchange 2010
The example will apply the system default Release Workflow that includes an added Workflow State of Trial Deploy and also has a number of Approval States. It includes Deploy and Trial Deploy States, as the stages of the Workflow where the related Change Requests (RFCs) are automatically created for the Deployment, and only when the RFCs hit the Deploy State configured for the RFC Control within the Details tab of the Release do the Deployment Tasks become active. The Change Manager can view all Deployment Tasks related to the RFC within the RFC Summary screen, and when all Tasks are moved to Closed-Resolved the Change Manager can close the related RFC.
The Release Team that will action the Deployment Tasks has also been broken down into three groups, Software, Hardware and all Deployment Technicians.
To create a Release with the Deployment Control managed by Change Management:
Define the settings within the Details Tab and set the RFC Control option to Yes
Click Save
From the above screen snap, we can see that Simone Supervisor is the Release Manager assigned to the Release and that the Release is of low Priority, will be handled by the Release Team and managed using the Release Workflow. The Release is currently in the default entry point of the Release, the Plan State. It should be noted that moving through the Release Workflow is determined by your organization's business processes and the defined Workflow. The system is to be used as a central repository to manage Releases and a point of reference to keep all relevant parties updated regarding a Release.
Move to the Item Types tab
Click Edit
Select Add and set the Reason to Update
Within the Find Item Type field, search for Exchange
Click on the Exchange link to add it to the Release
Upload Media Attachments, if relevant
If an electronic upgrade file is to be used for the upgrade, it can be uploaded within the Media Attachment field. This would then be made available within the Deployment Task associated with the Release.
Enter information that is to be updated on the Details tab of the Item being updated
These will automatically be updated in the CMDB when the Deployment Task moves from Open to Closed-Resolved.
Click Save and Save again.
Move to the Analysis Tab.
Within the Analysis tab, the Release Manager can access a list of existing RFCs that are yet to be associated with the Release. To add an existing RFC to the Release, the checkbox is marked next to the Request # link, and the Add button is clicked. The RFC no longer appears in the Analysis tab, and is now visible in the Elements tab, where it can be removed if the association was made in error.
For this example, it is assumed no relevant RFCs exist in the system, so we move to the Deployments tab where the RFC will be created as a result of the Deployment.
To create the Deployment:
Select the Deployments tab inside the Release information screen
Click New
The screen expands to show the options for the type of deployment to be created, the list of Customers who own an Item associated with the Item Types included in the Release Types tab and the Search Options box.
Select the type of Deployment that is to be created
For this example, a per Org. Unit Deployment will be created as the Item associated with the Release has shared ownership. When selected, the Organizational Unit associated with the Item that uses the Item Type associated with the Release is displayed in the Org. Unit. list.
Assign the Org. Unit by selecting the field next to the Org. Unit name and clicking
The selection is included in a Selected Org. Units window to the right of the main window. The group of Technicians who will action the Tasks and the Workflow State where the RFC will be created to manage the Deployment must be defined.
Click Next
Select the Group of Technicians who will work on the Deployment Tasks from the Group drop-down list
For this example the Software Deploy Group of Technicians will be assigned.
Assign the stage of the Workflow where the RFC will be created for the Deployment
When the Release Workflow moves into the Deploy State, for this example, an RFC will be generated. This RFC will be assigned the Change Deployment Workflow and be assigned to the Change Team. When the RFC is assigned the Status of Deployed the Deployment Task will move from Pending to Open, allowing the Team member from within the Software Deploy Group of the Release Team to action the Deployment Task.
Select the Item Type to be upgraded in the Deployment
If an Item Type is not displayed in the list, click to search the CMDB.
Click
The selection is displayed in the Select Items window to the right of the main window. If an incorrect assignment has been made, click.
Click Create
Click Done.
All Tasks are now saved with a Status of Pending assigned. When the Release Workflow moves to the Deploy State an RFC will be created. When the RFC hits the Release's RFC Control Deploy State the Tasks' Status will automatically be updated to Open, prompting Technicians to complete the Deployment Tasks and move the State to Closed-Resolved. When all Tasks are completed and moved to Closed - Resolved, the Release will be automatically Closed.
The Release Manager moves the Release through the lifecycle of the Workflow as activities are completed. For this example, within the Releases>Release#>Details tab the Release Manager has moved the Release through the Workflow States of Plan, Plan Approval, Build, Test and is currently assigned the State of Deploy Approval. Selecting Accept will move the Release to Deploy, and an RFC will automatically be created.
From the above RFC, we can see that the Change Team has been assigned the RFC, and they will move the Request through the Change Deployment Workflow.
This Workflow includes the stages of Pending>Approval>Schedule Outage>On Hold>Deploy>Closed. When the RFC is assigned the Deploy State, the Deployment Tasks created in the Release, and now available in the Change>Deployment Tasks tab, will move automatically move from Pending to Open, and the assigned Technician can action the Task before moving the Deployment Task State to Closed - Resolved.
When the Task Status is set to Closed-Resolved, the updated Details contained in the Release will automatically be updated on the relevant Item in the CMDB. The Change Manager can view all Deployment Tasks related to the RFC within the RFC Summary screen, and when all Tasks are moved to Closed-Resolved the Change Manager can close the related RFC. When the Deployment Task is completed, the Deployment within the Change > Deployments tab is automatically closed by the system.
When the Deployment is closed for a Release, the Release Manager can close the Release within the Details Tab, by moving the Release Workflow Status to the Exit State.