Release and deployment management with Git

Release and deployment management

Release and Deployment Management aims to build, test and deliver the capability to provide the services specified by Service Design and that will accomplish the stakeholders requirements and deliver the intended objectives.

Purpose, goal and objective

The purpose of Release and Deployment Management is to:

1. Define and agree release and deployment plans with customers and stakeholders
2. Ensure that each release package consists of a set of related assets and service components that are compatible with each other
3. Ensure that all release and deployment packages can be tracked, installed, tested, verified, and uninstalled if appropriate
4. Record and manage deviations, risks, issues related to the new or changed service and take necessary corrective action
5. Ensure that there is knowledge transfer to enable the customers and users to optimize their use of the service to support their business activities
6. Ensure that skills and knowledge are transferred to operations and support staff to enable them to effectively and efficiently deliver, support and maintain the service according to required warranties and service levels.

The goal of Release and Deployment Management is to deploy releases into production and establish effective use of the service in order to deliver value to the customer and be able to handover to service operations.

The objective of Release and Deployment Management is to ensure that:

1. There are clear and comprehensive release and deployment plans that enable the customer and business change projects to align their activities with these plans
2. A release package can be built, installed, tested and deployed efficiently to a deployment group or target environment successfully and on schedule
3. A new or changed service and its enabling systems, technology and organization are capable of delivering the agreed service requirements, i.e. utilities, warranties and service levels
4. There is minimal unpredicted impact on the production services, operations and support organization
5. Customers, users and Service Management staff are satisfied with the Service Transition practices and outputs, e.g. user documentation and training.

Scope

The scope of Release and Deployment Management includes the processes, systems and functions to package, build, test and deploy a release into production and establish the service specified in the Service Design package before final handover to service operations.

Value to business

Effective Release and Deployment Management enables the service provider to add value to the business by:

1. Delivering change, faster and at optimum cost and minimized risk
2. Assuring that customers and users can use the new or changed service in a way that supports the business goals
3. Improving consistency in implementation approach across the business change, service teams, suppliers and customers
4. Contributing to meeting auditable requirements for traceability through Service Transition.

Well-planned and implemented release and deployment will make a significant difference to an organization's service costs. A poorly designed release or deployment will, at best, force IT personnel to spend significant amounts of time troubleshooting problems and managing complexity. At worst, it can cripple the environment and live services.

Release design options and considerations

Service Design will define the approach to transitioning from the current service to the new or changed service or service offering. We will discuss common options for release and deployment that are considered in Service Design. The selected option will have a significant impact on the release and deployment resources as well as the business outcomes. It is important to understand the patterns of business activity and user profiles when planning and designing the releases.

Options for deploying new releases to multiple locations are illustrated in this figure:

1. Big bang option - the new or changed service is deployed to all user areas in one operation. This will often be used when introducing an application change and consistency of service across the organization is considered important.
2. Phased approach - the service is deployed to a part of the user base initially, and then this operation is repeated for subsequent parts of the user base via a scheduled rollout plan. This will be the case in many scenarios such as in retail organizations for new services being introduced into the stores in manageable phases.

Figure also illustrates a possible sequence of events over time as follows:

1. There is an initial launch of the Release 1 of the system to three workstations (1-3).
2. Two further workstations (4+5) are then added at the same time.
3. Release 2 of the system is then rolled out in a big bang approach to all workstations (1–5) at once.
4. Two further workstations (6+7) are then added, in another step.
5. There is a phased implementation of the upgrade to Release 3 of the system, initially upgrading only three workstations (1–3) and then the remaining four (4–7).
6. A further workstation (8) is then added to the system.

Variations of the phased approach include:

1. Portions of the service are delivered to the live environment in phases, but all end users are affected simultaneously (e.g. incremental changes to a shared application).
2. Each release is deployed gradually across the total population of end users (e.g. one geographical location at a time).
3. Different types of service elements are deployed in separate phases (e.g. hardware changes are first, followed by user training and then by the new or changed software).

Phased implementation is only possible if the service has been designed to allow new and old versions to coexist. If this is not possible then the only alternative is to upgrade all affected parts together in a big bang implementation. For elements such as documentation, for skilled staff it won't be a problem but for many instances of hardware and software it is possible. For other transitions, it can be virtually impossible to achieve.

This figure illustrates phased deployment to a number of different geographical locations.

It assumes that new versions will work alongside the previous one. The example used assumes that new functionality is implemented first in the head office of the organization, then in a pilot branch and finally in the remaining branches. If there are a very large number of locations to deal with, it may still take a long time to implement the initial system or upgrades in all branches, thus increasing the likelihood of needing to support even more versions of the system in the live environment concurrently.

Push and pull

A push approach is used where the service component is deployed from the centre and pushed out to the target locations. In terms of service deployment, delivering updated service components to all users, either in big bang or phased form, constitutes push, since the new or changed service is delivered into the users environment at a time not of their choosing.

A pull approach is used for software releases where the software is made available in a central location but users are free to pull the software down to their own location at a time of their choosing or when a user workstation restarts. The use of pull updating a release over the internet has made this concept significantly more widespread. A good example is virus signature updates, which are typically pulled down when it best suits the customer. However at times of extreme virus risk this may be overridden by a release that is pushed to all known users.

In order to deploy via push approach, the data on all user locations must be available. Pull approaches do not rest so heavily on accurate configuration data and they can trigger an update to user records. As some users will never pull a release it may be appropriate to allow a pull within a specified time limit and if this is exceeded a push will be forced.

Automation vs manual

Whether by automation or other means, the mechanisms to release and deploy the correctly configured service components should be established in the release design phase and tested in the build and test stages.

Automation will help to ensure repeatability and consistency. The time required to provide a well-designed and efficient automated mechanism may not always be available. If a manual mechanism is used it is important to monitor and measure the impact of repeated manual activities as they are likely to be inefficient and error-prone. Too many manual activities will slow down the release team.

Many of the release and deployment activities can be automated. For example:

1. Discovery and installation software can check whether the required prerequisites and co-requisites are in place before installation of new or changed software components.
2. Automated builds can significantly reduce build times that in turn can resolve conflicts and delays.
3. Automated configuration baseline procedures save time and reduce errors in capturing the status of configurations and releases during build, test and deployment.
4. Automatic comparisons of the actual live configuration with the expected configuration help to identify issues at the earliest stage.

Git workflows

Unlike Centralized Version Control Systems, the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects.

Central repository model

There is a single repository that all developers push to and pull from.

If you setup a repository for your team on a server that everyone has SSH access to, Git can very easily function as a centralized repository. This may be common on small teams with non-public projects where you don't want to worry about a hierarchy. The strength of this model is that it forces everyone to stay up to date with each other and it doesn't depend on a single role.

Even large teams could use this, but in general there are a lot of gains to be made in larger teams with a different or hybrid model.

Dictator and lieutenant model

This is a highly hierarchical model where one individual has commit rights to a blessed repository that everyone else fetches from. Changes are fetched from developers by lieutenants responsible for specific subsystems and merged and tested. Lieutenant branches are then fetched by the dictator then merged and pushed into the blessed repository, where the cycle starts over again.

The process works like this:

1. Regular developers work on their topic branch and rebase their work on top of master. The master branch is that of the dictator.
2. Lieutenants merge the developers topic branches into their master branch.
3. The dictator merges the lieutenants master branches into the dictator master branch.
4. The dictator pushes their master to the reference repository so the other developers can rebase on it.

This model is much better for large teams, and can be implemented with multiple levels of lieutenants in charge of various subsystems. At any stage in this process, patches or commits can be rejected.

Integration manager model

This is where each developer has a public repository, and there is also one blessed repository. A person or core team has commit rights to it, but many other developers have public forks of that repository. When they have changes, they issue a pull request to an integration manager who merges, tests, accepts and pushes these changes.

The process works as follow:

1. The project maintainer pushes to their public repository.
2. A contributor clones that repository and makes changes.
3. The contributor pushes to their own public copy.
4. The contributor sends the maintainer an e-mail asking them to pull changes.
5. The maintainer adds the contributor repo as a remote and merges locally.
6. The maintainer pushes merged changes to the main repository.

This is largely how community-based repositories work and how many smaller open source projects are managed.