Sitepass by INX › Resources › Legal › Release Management
The objective of Sitepass release management is to:
Service transition packages, builds, tests, evaluates, deploys, transfers or retires new or changed services or service components. It covers transition of new and changed services into supported environments such as release, planning, building, testing, evaluation and deployment. The purpose is to ensure that new, modified or retired services meet the expectations of the business from previous stages (service strategy and design).
Service transition includes the following processes:
Release management’s objective is to align release plans with business projects and ensure that the release units are successfully built, tested, verified and deployed with minimal disruption to the live environment. It is a framework and is absorbed by organisations according to their processes and policies.
From Sitepass perspective, release management focuses on the development and release of new systems, features, functions and infrastructure that aligns to the product vision in order to meet our client needs and requirements.
The goal of release management as part of service transition is to deploy releases into the production environment and establish effective use of service in order to deliver value to the customer and be able to handover to service operations in this case our ‘clients’.
This process is responsible for delivering new functionality, whilst protecting the integrity of existing services through communicating the relevant information and changes and coordinating properly with the engaged teams and stakeholders. It is required to be implemented by attaining necessary approvals and supporting documentation.
Release management is a link between software development and its final deployment. It’s an intermediary step to ensure the reliability of the code and to certify that the deployed code meets the business and stakeholder’s expectations.
It’s a process which aids in delivery of new and improved product features built by the development team for our customers thereby providing efficient, scalable and reliable services which is tracked and appropriately documented with minimizing the risk of impact on availability of services.
There are various roles & responsibilities involved in release management, and for Sitepass these roles are:
Roles | Responsibilities |
---|---|
Product Manager |
|
Business Owners/Stakeholders |
|
Development Leads/Business Analysts |
|
Software Developers |
|
Quality Analyst |
|
Release Coordinator |
|
Infrastructure and deployment team |
|
Our employees |
|
Clients and end user |
|
Release strategy adopted at Sitepass leverages the below listed servers for developing product features, fixing bug fixes and deploying releases.
The following table outlines the infrastructure used throughout the deployment strategy.
Server | Branch | Description | Supported Infrastructure |
---|---|---|---|
Local Development | n/a | Used by software developers for code creation and test/experiments etc | Locally available in Adelaide head office |
Feature servers | Feature Branch | Used by development team to deploy code developed in feature branches, and utilised by QA team for feature testing | Single instance of each feature server serving the traffic, the code is being utilised to fulfil client requests/issues |
Delta | Develop Branch | Used by development team for code creation, build etc. Additionally, used by QA team for sanity testing of features once those are fully tested in the feature server | Single instance of this server serving user traffic, the code is being utilised to fulfil client requests/issues |
Alpha | Master Branch | Once the code is developed in delta its being moved to alpha to complete
the feature development for next release candidate to be merged in the master branch
Utilised for Hot fixes |
Single instance of this platform is currently available supporting client requests/issues |
Beta | n/a | Is available and leveraged by the clients for testing of the platform. Also being leveraged internally by various business units for internal testing or demos. |
The server is hosted in Sydney AWS. |
UAT | Release | This is utilised primarily by clients as part of user acceptance testing and is also used by internal QA team. | The server is hosted in Sydney AWS. |
Production | n/a | Live environment where the code is released after successful deployment in
the Beta environment.
The code is primarily migrated from staging server, a standalone instance on AWS to both the production environment. |
The infrastructure architecture hosted out of Sydney AWS. |
The below diagram illustrates the code development stages used by the development team for code creation, build, merge and deployment.
The above diagram illustrates the code development stages used by the development team for code creation, build, merge and deployment.
Release management is a critical process for the deployment of new features, systems or infrastructure changes to Sitepass. The product development and management process employ a three-stage process of Planning, Development and Release. Whilst release management generally occurs towards the end of the process, it is involved in all stages within the process.
The planning phase of the product development process is to define the requirements for any new feature or infrastructure change that will be introduced. Feature suggestions, or new products that need to be developed to address business or client requirements are defined, scoped, analysed and during this period. Collaboration with clients and cross functional teams ensure a collective agreement towards the functions and impact of any new feature introduced.
Release Management within this phase, is leveraged to identify and manage the impact of this change through the identification of the following:
The development phase of the product development process is to build the features, systems or configure the infrastructure changes designed and agreed to through the planning phase. Most of the investment in time and resources is focused during the development phase, to build, test and finalise any features in preparation to be released.
Release management within this phase, is leveraged to manage the schedule and stage of each project in line with:
The release deployment phase of the product development process is where most release management activities occurs. As the final stage in the process, release deployment includes the activities which are central to the deployment of the product changes that are ready to be deployed to the production environment. Further information about this phase and the activities involved can be read in the release stages section.
Releases are monitored and tracked by the release manager, and each release contains the following information:
Below are some of the key performance indicators for release management:
KPI | Description |
---|---|
Number of major releases | This KPI is established based on release type and is evaluated as a high-risk release depending on the coordination involved between various functions and teams. These releases will usually be scheduled based on long-term vision and backlog items. |
Number of minor releases | This one is also factored on the release type and will be measured against scope of small but critical changes implemented. These will usually occur on quarterly basis. |
Number of hot fix releases | Hot fix is typically a low priority release comprising of bug fixes and is often released weekly. |
Number of emergency release | With the prevailing service levels, emergency releases are unexpected with the scope extending from an urgent client request to a critical security patch implementation. |
Number of outages/incidents caused by a release | Any outage caused during a release should be tracked and documented for better planning of releases |
Number of tickets/issues successfully resolved in a release | Is calculated against the number of tickets/issues addressed/fixed during a release. |
Number of tickets/issues that didn’t resolve in a release | This will account for number of tickets/issues that did not get fixed in a release leading to creation of additional tickets. |
Total release downtime | The difference between the estimated downtime and the actual downtime during a release. |
Unit Test Cases | Number of unit test cases covered for code creation |
Below are some of the critical success factors for release management:
Below are some of the benefits of the introduction of release management for Sitepass:
We continuously introduce improvements to our products, services and platform in order to meet the business requirements and maintain infrastructure stability and security.
Refer to service levels for a list of release classifications, notification periods and versioning.
Below stages occur throughout the release management process, the stages may vary for each release classification, however the workflow stages will remain as follows:
Release planning is a collaborative effort involving the product owner, business analysts, release coordinator and development teams to plan the deliverables for a particular release.
This stage focuses primarily on assessing the impact of issues/features going in to a release:
This stage comprises focuses on finalising the product developments by:
In this stage, the release coordinator coordinates with the following teams to ensure that the relevant activity is fulfilled to prepare for the release.
Team | Activity |
---|---|
Sales | To ensure all the product pricing changes are complete (if any) |
Review schedules | Any changes in schedules are complete |
Production | Any new improvements involving support requests creation should be well communicated and understood by the team |
Marketing | To see if any improvements/changes require marketing efforts |
Client Services | To ensure that the team is aware of the new changes being rolled out |
Client | To communicate all the changes to the client and verify if any external training is required |
User Acceptance Testing | Ensure a sign off is obtained on UAT from the client services team |
This stage seeks the necessary updates to the documentation informing end users and internal employees about the release changes. Below are the listed components:
Component | Reference site |
---|---|
Knowledgebase | https://support.mysitepass.com |
Release notes | https://release.mysitepass.com |
Status Page Notifications | https://status.mysitepass.com |
In this stage sign off is attained from all the key stakeholders to ensure the release is ready to be deployed.
This stage comprises of the below activities initiated to perform the actual deployment along with administering the release through:
Post release review records the lessons learned and/or any feedback for the release or any of its stages/steps. It involves hosting joint reviews for the teams to share feedback.
Managing everyone’s safety just got easier.