Deployment Change
Deployment Change process is supported by a SM workflow cartridge that enables the execution of the process. This process is strictly related to the Release and Deployment Management process as through it a release is installed into a target environment (e.g. test, acceptance, live, etc.). The process is therefore triggered by the Release and Deployment Management process itself and returns the feedback on its result.
Of course the preconfigured process (the workflow cartridge) is just an accelerator and the tuning / completion of the initial configuration will still be required. To this aim, the Workflow Engine guide may be useful.
IMPORTANT NOTE: the configuration below is only one of the possible configuration to deal with the deployment change process. The need for a different behaviour of the process may be fulfilled by simple changes of the configuration.
Indice
Operational model
The preconfigured process has the objective to deploy a release and is a standard change. At the core of the process configuration is the following simple operational model.
From the Release and Deployment Management process a command (button) is available to trigger the Deployment Change process. This opens a new Deployment Change instance. This is done by an action which sets also sets a release team (a defined group). The members of the release team can therefore see the deployment change and set the owner of it. The owner performs or coordinates the deployment activities. When the activities are completed another action automatically gives a feedback to the Release and Deployment Management process.
Roles
For this process, the following organizational roles are defined:
| Organizational role | Description | itmSUITE® role mapping |
|---|---|---|
| Requester | See the Release and Deployment Management process for detailed information on who is enabled to start deployment changes | |
| Owner |
|
This role is picked up by a member of the deployment team (a specific group). |
| Deployment team member |
|
Resources belonging to the "Deployment team" group; the login identifier of one of these users is "DepTeamMemb"). |
| Deployment team manager |
|
Manager of the "Deployment team" group; the login identifier of this user is "DepTeamMan"). |
Process
A deployment change is opened during the execution of the Release and Deployment Management process and is kept linked to the instance of the release it is originated from.
A workflow is configured to support the Deployment Management process. The workflow is characterized by workflow statuses and workflow transitions. The figures below illustrate the process.
The table below explains the meaning of each workflow status.
| Workflow status | Description |
|---|---|
| "Default" | A preliminary status which is displayed when a deployment change is created. |
| "Opened" | The deployment change has been recorded and requested. |
| "Cancelled" | The deployment change is not confirmed and, therefore, cancelled. |
| "Closed" | The deployment change is completed and closed. |
And finally the table below explains the roles authorized to execute the workflow transitions.
| Source status | Destination status | Authorized executors | Comment |
|---|---|---|---|
| "Default" | "Opened" | Requesters | |
| "Opened" | "Cancelled" | Requester, owner. deployment team manager | |
| "Opened" | "Closed" | Requester, owner, deployment team manager. |
Related processes
The key related process is Release and Deployment Management. The tab Related Items of the deployment change and, in particular, the sub tab Tickets of it allows to view all the existing relationships between the deployment change and Release and Deployment Management.
Release and deployment management
A new deployment change can be initiated from a release and updating the deployment change will provide a feedback to the release itself.
Services
The deployment changes are opened on the "Deployment Management" service. The user "DeplManager" is the service manager of the "Deployment Management" service.
Management information
Many management information are available as fields in the deployment change management configured form. The following table illustrates the intended use of key information and its behaviour. NOTE: information are available (visible) and can be modified according to a specific configuration which is meant to be suitable for the organizational roles involved in the process.
| Information group or tab | Field | Purpose | Comments |
|---|---|---|---|
| General Information | Ticket Op Status | To show the operational status of the deployment change, see workflow statuses in Process section of this page. | Status changes are performed by means of the Save&Next command. |
| General Information | Short Description | To provide a short description of the deployment change. | Always visible. |
| General Information | Requester | To identify the name of the requester (who has requested the deployment change). | This field is automatically set to the identification code of the source release by the action creating the deployment change. |
| General Information | Creation Date | To show the date and time the deployment change was created. | This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information. |
| General Information | Edit Date | To show the date and time the deployment change was last updated. | This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information. |
| General Information | Creation User | To show the user who created the deployment change. | This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information. |
| General Information | Edit User | To show the user who updated the deployment change last. | This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information. |
| Ticket Classification | Project/Service | To show the service (or project) to which the deployment change is related. | This is automatically set at open time and can't be modified. |
| Ticket Classification | Ticket Type | To show the type of workflow executed. | This is automatically set at open time and can't be modified. |
| Ticket Classification | Release Type | To show the type of the release implemented by the deployment change. | This field is automatically set to the Release Type of the source release by the action creating the deployment change. |
| Ticket Classification | Release Number | To set the change scope.This is typically used for statistic reasons. | This field is automatically set to the Release Number of the source release by the action creating the deployment change. |
| Ticket Classification | Target Environment | To define the target environment for the deployment. | This field is initially left blank. The target environment is mandatory and can be chosen from a drop list of enabled values (e.g. "Live", "Test", etc.). |
| Prioritisation & Planning | Required Deployment Date | To set the required execution date for the deployment change. | This field (date & time) is mandatory and initially set empty. |
| Prioritisation & Planning | Planned Deployment Date | To communicate the planned execution date for the deployment change. | This field (date & time)is mandatory and initially set to empty. |
| Prioritisation & Planning | Actual Deployment Date | To communicate the actual execution date for the deployment change. | This field (date&time) is initially blank and can be edited. If empty, it is automatically set to the date and time of the transition to the "Closed" Ticket Op Status. |
| Ownership and Groups | Supervising Team | To define the supervising team. | This is set by the service manager and mandatory from the Ticket Op Status "In Analysis". |
| Ownership and Groups | Seployment Teamolution Group | To define the team to which the change is assigned for analysis and/or implementation. | This is set by the service manager and mandatory from the Ticket Op Status "Approval Requested". |
| Ownership and Groups | Owner | To define who is the change owner who should monitor the lifecycle of the change. | This is set by the service manager and mandatory from the Ticket Op Status "In Analysis". He/she can be changed by the service manager and the Owner him/herseilf. |
| Ticket Details | Details | To provide a more detailed description of the change. | An auto tracking field is used enabling to view the user who has updated. |
| Ticket Details | Anvironment Parametersnalysis | To provide a detailed analysis of the assessment of the change. | An auto tracking field is used enabling to view the user who has updated. |
| Ticket Details | Comments | To provide helpful comments. | An auto tracking field is used enabling to view the user who has updated. |
Fields can be mandatory to save the change in some workflow statuses. These fields are highlighted with a red asterisk.
Views
The following views are made available in the Tickets area of the home page:
| View | Content | Requester | Change owner | Technical team | Service manager | Change authority |
|---|---|---|---|---|---|---|
| Changes completed | Changes in statuses "Completed", "In Review". | X | ||||
| Changes requested | Changes in status "Requested". | X | ||||
| Changes owned | Changes in all the statuses but "Opened", "Cancelled", "Aborted", "Closed" where Owner is the logged resource. | X | ||||
| Changes routed to my team | Changes in all the statuses but "Opened", "Cancelled", "Aborted", "Closed" where Solution Group is the solution group to which the logged resource belongs to. | X | ||||
| Changes assigned to me | Changes in all the statuses but "Opened", "Cancelled", "Aborted", "Closed" where the Ticket Worker is the logged resource. | X | ||||
| Changes suspended | Changes in status "Suspended". | X | X | |||
| Changes to review | Changes in status "Completed" where Change Type is "Emergency" or where Change Type is "Normal" and Change Category" Significant". | X | X | |||
| Changes to authorize for implementation | Changes in status "Implementation Approval Requested". | X | ||||
| Changes to authorize for deployment | Changes in status "Deployment Approval Requested". | X | ||||
| Changes evaluated by Change Authority | Changes in status "Approved" or "Not Approved". | X | X | |||
| Changes approved for deployment | Changes in status "Deployment Approved". | X | X |
|
Additionally, the following views are made available in the Change menu for all the organizational roles:
| View | Content |
|---|---|
| Changes active | Changes in all the statuses but "Cancelled", "Aborted", "Suspended", "Closed" |
| Changes suspended | Changes in status "Suspended |
| Changes closed | Changes in status "Closed" |
| Changes cancelled | Changes in status "Cancelled" |
Notifications
The following notifications are configured:
| Trigger | Recipients | Purpose |
|---|---|---|
| A change is requested | Service manager | Alert that there is a change to manage. |
| A change is assigned a owner | Change owner | Alert that the change was assigned to him/her. |
| A solution group is assigned or changed for the change | Solution group manager | Alert that there are resource(s) to allocate to manage the change. |
| A change review shall be executed (the change is in workflow status "Change Review") | Change owner, service manager | Alert that a change review is to be done. |
| A change is completed | The change creator, the requester | Alert that the change is implemented. |
| A ticket worker is assigned | The assigned ticket worker | Alert that there is work to be done. |
| A change is suspended | The change creator, the requester, the service manager, the change owner | Alert that the change is suspended. |
| An change is closed | The change creator, the requester, the service manager, the change owner | Alert that the change has been closed. |
| A change is cancelled | The change creator, the requester, the service manager, the change owner | Alert that the change has been cancelled. |
| A change implementation approval has been requested | Change authority | Alert that a change implementation request has to be examined. |
| A change implementation approval request has been examined | Change owner, service manager | Alert that the change authority has given a feedback on a change implementation request. |
| A change deployment approval has been requested | Change authority | Alert that a change deployment request has to be examined. |
| A change deployment approval request has been examined | Change owner, service manager | Alert that the change authority has given a feedback on a change deployment request. |
Reporting
A set of standard reports are made available for the change management process. It is not required to have the REP module to use them, however the module is required if new or changed reports are needed. The available reports are placed under Change/Reporting menu.
The following table lists the reports available by default and their visibility:
| Report name | Content | Access |
|---|---|---|
| Change per category - trend | An histogram showing the change volumes per category monthly trend. | Service managers and technical team members. |
| Change per category - volume | A pie containing the split of changes per category. | Service managers and technical team members. |
| Change per service - trend | An histogram showing the change volumes per service monthly trend. | Service managers and technical team members. |
| Change per service - volume | A pie containing the split of changes per service. | Service managers and technical team members. |
| Change per service/category - volume | An histogram showing the changes volume per service and category. | Service managers and technical team members. |
| Change - analysis time | A pie showing the percentage of changes respecting the target defined for the "Analysis time"* objective (the time elapsed from the "Requested" to the "In Analysis" workflow status. | Service managers and technical team members. |
* "Analysis time" is defined within the OCE module.
A basic form of reporting is also provided by views. Views basically allow to list changes and their attributes but may also be configured to calculates sums, averages on some of them. The available views are illustrated in the dedicated section of this page.
Examples of use
In this section some examples of use of the configured change management process are given.
If you get lost, any time use the EXPLORE WORKFLOW command of the change management form. This enables to view the status of the workflow as shown in the figure below. By clicking on a relationship between workflow statuses, roles and users enabled to perform it are presented.
NOTE: the EXPLORE WORKFLOW command is available only if the ticket is first saved.
For more information on how to use any workflows, including incident management, please refer to the workflow execution guide.
Create and request a new change as a final user
- Login as "finaluser" user
- Activate the Self Service menu
- Choose a self service topic, self service category and finally "Change" as self service request (this determines the creation of a new change)
- Fill the change form, at least with mandatory fields, and save with the SAVE command (the change is now in workflow status "Opened")
- Set the change in workflow status "Requested" with the SAVE & NEXT command
You have now saved the change, take note of the ticket number for further reference and use.
Assign a change for analysis as a service manager
- Login as "servicemanager"
- Open the the desired change; you can do it quickly either by
- Access the "Changes Requested" view in the Tickets area of the home page and pick a change
- Access the Change/Changes active menu and pick a chanve in workflow status "Requested" among those listed
- Insert the reference number of a change in workflow status "Requested" in Quick Search, after selecting the search context "Ticket"
- Assign the key roles
- Fill the change form with Owner, Solution Group and, may be, Master Solution Group, Ticket Worker,
- Pressing the SAVE & NEXT command, choose the "1. Assign ticket" workflow transition
The change is now in workflow status "In Analysis".
