Deployment
This stage involves deploying the release to the production environment after the authorized technicians approve the release.
Deployment involves the following:
- Ensure that the target environment is ready to admit the commissioned release.
- Analyze the CIs involved and mitigate any potential risk of disruption.
- For releases that involve deploying multiple components, create a sequence of tasks and map task dependencies to avoid any scope of error.
After these initial preparations, you can start deploying the release.
After the release is deployed to the target environment, you must verify whether the deployed release functions as expected for stakeholders and end users. When the deployment poses any major issue at any point of time, you must be well-prepared to back out of the release with minimal or no interference in the production environment.
To add and view deployment-related details,
- Go to Releases.
- Choose all or a specific customer from the drop-down in the header.
- Go to the details page of the required release.
- Click Deployment on the left pane.
The following tabs are displayed on the canvas:
- Details:
- spot edit the relevant fields to provide the expected and actual deployment time frame.
- Describe the deployment and attach the necessary files under Description.
- Attach records of the issues found while testing.
- The downtime scheduled in the planning stage will be listed.
- Tasks: Add, edit, organize, delete, pick up, trigger, and close release tasks, assign owners to the unassigned tasks, and configure task dependencies. Learn more.
- Notes: Provide deployment-related additional information. You can also add deployment notes via conversations.
- Approvals: Define approvers for various approval levels required to complete the deployment. Learn more.
- Status Comments: View all deployment status comments provided in the release form.
Related Articles
Workflows Use Cases
Workflows Pointers Workflows can be configured for All Customers as well as for a specific customer, but not site-specific. This setting is module-specific. Separate workflows for incident requests and service requests can be configured. If an asset ...Use Cases
Scenario: Convert Incident to Service Request Currently, only incident requests can be created via email using the default template. However, Zylker wants to create service requests based on specific keywords found in the email, aligning with their ...Notification Rules Use Cases
Notification Rules Pointers Supported Modules: Requests, Problems, Changes, Projects, Release, Solutions, Assets, Purchase, Contracts, Tasks, and other general events. Supported Notifications: Email, SMS, and Push. Actionable Messages can be enabled ...Stage and Status
The progress of each stage in a release life cycle is tracked by specific statuses. You can create and manage stages and statuses for the release under Setup > Customization > Release Management > Stage and Status. Users with Edit Releases permission ...Release roles
The release roles allow you to define access permissions to various stages in releases. You can either customize the default release roles or define new roles as required and associate these roles with users when creating a release. Association of ...