Software Release and Deployment Management

your organization has developed a true DevOps culture.

DevOps (development and operations) is a culture, movement, or practice that emphasizes the collaboration and communication of software development teams, security team(s), and other IT professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software, can happen rapidly, frequently, and more reliably.

The purpose is to:

• Deploy more often, with fewer failures;
• Have faster delivery of features and resolution;
• Have more stability, less fear of change;
• Spend more time to add value versus time spent on maintenance;
• Align infrastructure to business features.

Steps

1. All features, enhancements, and bugs for software products inside your organization are tracked as issues in the ticketing solution;
2. Changes are committed in a dedicated branch named with the ticket/issue number and the title of the ticket;
3. Continuous integration (CI) performs unit and functional tests, and if these pass, changes are accepted into the project's repository;
4. Changes are deployed to the development environment where regression and end-to-end tests happen before the new code is accepted in the develop branch;
5. The testing environment receives the new code changes, after which sample data is loaded to start performance and security tests;
6. Continuous delivery (CD) of the code into production is done by testing the changes in pre-production environments first, an environment that mimics the production one;
7. No changes are promoted to production without opening a ticket in the Change Management project and waiting for approval with proper sign-offs from each department involved in the process - see Change Management Policy;
8. In case of issues, IaC automation must restore a previous version of the code which was not impacting customers.

As part of this process, a deployment plan will be created. The Release Manager will be responsible for creating the release and deployment plan and getting it approved by Project or Programme Board.

The plan will include:

• Approach
• Prerequisites
• Method of Deployment
• Configuration Items
• Training
• Roles and Responsibilities
• Change Management
  • Backout Plan
  • Testing
  • Communication
• Timing and Timescales
• Risk Management
• Documentation
• Related Change Requests, Known Errors and Problems

For more info, refer to the Secure Software Development Lifecycle Policy

Approval is required for each change request. your organization approver is either the project's Technical Development Lead or the CTO.

• No software, update, patch, or feature is released with security defects or bugs (critical or high severity);

• Open Source Software (OSS) can be introduced into your organization proprietary software. The following criteria should be met:

  • Introduced OSS must have a measurable benefit
  • OSS must allow your organization to share their application as commercial and noncommercial without any binding on the OSS license
  • There is no equivalent your organization software or solution already deployed or easily available
  • Change requests must be written with the following details:
    • Description
    • Change reason
    • Affected systems, applications, and data
    • Version (for code, image, deployment, etc.)
    • Security scan status and results
    • Production environment, such as gcp-companyName-prod

• main is the ONLY branch which will be promoted to production:

  • main branch cannot be deleted;
  • commits to the main branch are restricted;
  • Merge Requests (MR)/Pull Requests (PR) can be merged only with the approval and after all the builds in the request are successful.

Several key software tools underpin an effective release and deployment management process. These are subject to change as requirements and technology are updated and so specific systems are not described here. However, the main types of tools that play a significant part in the process within your organization are as follows:

• Release Management System: the ticketing solution;
• Change Management System: the ticketing solution;
• Configuration Management System: git;
• Software Deployment Tools: CI/CD (+ artifacts repository).

Releasing features to a subset of your users or servers, seeing how they respond, and making updates to your features accordingly is a strategy your organization has implemented for rapid application development.

A typical dark launch begins by wrapping a new feature in a feature toggle (or feature flag). Once the feature is pushed to production, the development team (or project manager, or even marketing team) can begin turning the new version on for users, starting with a small percentage like 1% or 5% and moving up to larger percentages if everything continues running smoothly.

your organization makes use of Kubernetes Canary Deployments where possible. Canary deployment strategy involves deploying new versions of an application next to stable production versions to see how the canary version compares against the baseline before promoting or rejecting the deployment.

The nature of a release is that it is often planned many months in advance as a significant amount of work will go into it. However, circumstances may arise where a set of changes needs to be grouped into a release and deployed at short notice to fix a problem with the operational service.

The following definition of an emergency release has been agreed with the business:

"A release will be considered to be an emergency if it is required to correct errors in the current release that are having a major impact on business operations."

In common with the urgent change management process, emergency releases will, as far as possible, be handled in the same way as normal releases but the planning, assessment, and approval will take place within a compressed timescale.

The responsibility for determining that a release should be treated as an emergency rests with the Service Manager, based on consultation with the business.

Some of the less critical activities may also be carried out after the release has been rolled out. These will typically be items such as documentation. It is emphasized that these activities must still be completed even though the release was treated as an emergency.