The cycle generally starts with the design, followed by build, test, and transition. Transition activities involve the management of moving a built object into production. Before this can happen, there needs to be a streamlined process to manage the movement of packages from the lower to higher environments. There should be precise policies, principles, and processes that guide the releases to ensure that the activity does not become an ambiguous chaotic method. While these represent half the story, there is the technical aspect of moving the packages: the methods we use to deploy to minimize risks and maximize predictability.
In the waterfall world, releases and deployments happened very few times, and the periods were defined in blood and followed to the hilt. So the onus of a process to drive it, procedures to deploy, and the means of deployment were not as significant as the process of development and testing.
Today in the DevOps industry, things are not what they used to be. The final production units of releases and deploys have become one of the pillars of development and operations. They happen all the time, and without human supervision as was the case earlier. So, it is imperative to tighten the processes and rein in the activities through automation to allow the two sets of activities to be seamless and not act as blockers, because in DevOps, speed is everything. And blockers/impediments are meant to be bulldozed one way or the other. This is an important topic from DevOps, Agile, and ITIL perspectives.
Release management
Deployment management
In ITIL V3, release and deployment management practices were combined into a single process. In ITIL 4 the context has changed, and the world has become more digital, with a lot more releases and deployments. So, it makes full sense that there are dedicated practices to give both the topics the due respect they command.
Although ITIL does not specify that in-depth knowledge is necessary from an examination standpoint, I shall dig deep because they are critical pieces from whichever industry you consider and look at them from. I will ensure that you get a good grip on both practices.
You can expect about one or two questions on the ITIL Foundation exam from the release and deployment practices. You will be tested on your cursory understanding of the topics.
Release Management
Release management is a practice that is common to both the development and operations activities of a program. In other words, you do releases for items that are enhancements and you do releases for break-fixes as well, especially those that aren’t urgent.
ITIL Definition of a Release
A version of a service or other configuration item, or a collection of configuration items, that is made available for use.
The definition might sound cryptic but it will not after I explain it.
The enhancements or a new product or service that is being introduced get developed in a lower environment such as a development environment. The access to it would sit with the developers alone. After completing the development and unit testing it, developers promote it to a higher environment, say, a test environment. A test environment is accessed by the testing teams that perform testing against the functional requirements (and technical design). Testing could be done by humans (manual) or by machines (automation). If tests are satisfactory, then the developed software is moved to the next higher environment, say, the acceptance testing environment where users perform testing similar to what the testers did in the testing environment. If all is well, the software is packaged as a release; on a preset and agreed date, it is moved to the highest environment, which is production. This movement to production is referred to as a release. In the release, you might have just this software, or a few software pieces clubbed together, and often packaged along with nonurgent incident fixes as well. When the release goes into production, the released software is available for general use, which is generally access controlled. I considered an example here of a software, but it is quite likely that along with the software there could be hardware changes going in as well; maybe enhanced processor capacity or a set of servers being load balanced. So it is important to imagine a release as a package that could contain software enhancements, new service introductions, break-fixes, and hardware changes. It’s a package where a number of changes go into the system during the same window, referred to as a change window.
ITIL Definition of Release Management Practice
The purpose of the release management practice is to make new and changed services and features available for use.
Change Control vs. Release Management
I have conducted several trainings in a classroom setting and online as well. The most asked question when I start talking of release management is this: what is the difference between change control and release management? It seems that what the change control practice does is the same as the release management; that is what I get asked about. This section is dedicated to those questioners. In this section, I will not differentiate between release and deployment management practices as the story drawing a thin line between change and release is straightforward if release and deployments are considered together.
Change control vs. release management
Release Management in SVC
SVC Activity | Involvement | Details |
|---|---|---|
Plan | Medium | Release plans to agree the release schedule, types, and techniques are defined and agreed during this activity. |
Design and Transition | High | The heart of release management practice works in close coordination with the Design and Transition activity. |
Obtain/Build | Medium | The release components are built and tested in the Obtain/Build activity. |
Engage | Low | The enhancements and break-fixes that go in are agreed with the customer base or come through various third parties. |
Deliver and Support | Medium | Releases change the existing service, and this requires updated documentation, training, and new methods of providing support. Release management practice provides the required artifacts and knowledge needed for support. |
Improve | Low | Improvement items also go through the cycle of design, build, and release. |
Change control is a process that is responsible for obtaining all approvals and authorizations from relevant stakeholders and controlling what changes go in. The release management practice, on the other hand, deals with the management of technicalities of the changes. For example, let’s say that a change has been raised to deploy a new version of the software. The change control process exists to put the change in front of the jury (change authority) and to help obtain approvals and authorizations so that the change can be deployed seamlessly. The release management practice manages the requirement gathering, coding, testing, and deployment activities of this change.
Deployment Management Practice in SVC
SVC Activity | Involvement | Details |
|---|---|---|
Plan | None | Deployment management practice does not feature directly in the overall planning, as this is generally carried out through the release management planning. |
Design and Transition | High | The deployment management practice plays a critical role in Design and Transition, as the practice is at the center of moving packages to environments. |
Obtain/Build | High | In a DevOps project, the difference between Obtain/Build and deployments is nonexistent, as the incremental nature of development and deployments ensures close collaboration between the two. |
Engage | None | Deployment management does not have a directly role to play with end users or other stakeholders. |
Deliver and Support | None | Deployment management does not have a direct role to play with the delivery of services or its support. |
Improve | Low | Improvements, like other enhancements and changes, go through the cycle of release and deployment. |
It ensures the efforts that go into development and testing are not wasted if change management decides not to approve the changes.
If there are modifications to the solution proposed by the change authority, then rework can be avoided.
The release management practice manages the overall planning, build, test, and deployment portions of the project. However, after the tests have concluded, the release status is put back into change control’s court. Change control’s authorization is a necessary step to ensure that all the entry criteria for deployment to begin have been met. It also provides oversight before changes to production are set to begin.
The deployment and postimplementation review activities are owned by the release management process, and the results are duly reported to change management for change closures with the appropriate status.
In this sample process, the release has been ping-ponged between release and change control practices at least six times. It can go higher; the higher the number of exchanges, the better it is for ensuring the quality of governance and sharing accountabilities.
Release Fundamentals
I have broken down release fundamentals into chunks for ease of understanding.
Release Components
As discussed earlier, releases include both hardware and software components that go into production. Well, that is not all. As a part of the release, there are other components that need to be refreshed as well. Training, for example, is a critical aspect. If certain functionalities of the software are changing, then the end users need to be trained before the release, the documentation needs to be updated inline with the enhancements and new services, and accesses may need to be sorted. This list is different for every application that is going through the release cycle.
Not all release components come from the service provider alone. Third parties at times provide packages or components that can go into the release. An example could be a package that is needed for an existing integration to work in the upcoming versions of the third-party software that integrates with the service provider managed application. Not only third party but COTS and open source products making it to the release is possible as well.
The scope of release management therefore is spread as far and wide as the service stretches; they need to look at risks coming from third-party systems, the infrastructure that hosts the software, and all components of the service.
Types of Releases
Releases come in various sizes and cycles. You may be making a small change to a functionality that is almost harmless, or you could be refreshing software including its architecture. Or you may be moving your software components from an on-premises infrastructure to cloud, which is quite impactful if things were to go south. Or you could be making changes to a middleware, which could potentially impact 20 applications that are feeding off of it.
Examples of release types are minor releases, major releases, and emergency releases.
Major Releases
Major upgrades to software generally come under major releases. The business impact of major releases can be anywhere between high and critical. This type of a release is the mother of all releases and takes priority if there is going to be a minor release happening at about the same time. A number of resources are usually dedicated to the building and executing of a release, and from a compliance angle, all the hawks should watch it with extra attention.
In my experience, major releases are few and far between. In most cases, they are done on an ad hoc basis, with some organizations deploying at least four major releases in a year. For example, you might notice the updates being applied to the Windows operating system. Some changes are quick and may not even demand a restart. However, additions, modifications, or the removal of integral features happen on the back of major releases that could require several minutes of installation followed by multiple restarts .
Minor Releases
As the word minor suggests, minor releases include release units that are small and do not usually bring down the business if the release goes south.
Minor releases are usually carried out as often as a weekly basis or as late as monthly. It all depends on the number of changes that are getting pumped in and the number of resources available to work on them.
Emergency Releases
Emergency releases are the planning and execution counterparts of the emergency changes. They come into play on the back of an emergency change and are deployed (usually) to fix an incident and to avert negative business impact.
The number of emergency releases reflects negatively on the organization and the project. Therefore, this is a type of release that’s not preferred or planned but rather gets imposed by the turn of events. It is also not uncommon that the release policy allows emergency changes to be helicoptered in only between releases, say, between two minor releases.
Release Schedule
Releases normally have a period associated with them. If they’re not, or if they are carried as and when needed, these releases are referred to as ad hoc releases. At times, to put in a break-fix that has a major impact, unscheduled releases are made. These are done on the back of emergency changes and are referred to as emergency releases. Then there are scheduled ones, which could be daily, weekly, monthly, quarterly, half-yearly, yearly, and so on. Daily, half-yearly, and yearly are quite rare. Even the other periodic releases may have a theme associated with them, like weekly releases for security patches, monthly for configuration changes, and quarterly for major changes.
All these periodic releases are soon to go out the window with DevOps taking over. In DevOps, releases will be done in a modular fashion and as and when the testing of the piece of functionality is completed. Nobody is going to wait to assemble the pieces for a fine sunny morning. It gets pushed to production as it gets fully tested.
We looked at the change schedule in the last chapter, which consisted of all the changes that are in the pipeline and in approved status. A release schedule also exists that is similar in nature but contains all the releases that are in place. It’s a schedule that has a visibility between a customer and a service provider. The common practice is for the customer and the service provider to discuss and come to an agreement on what a release schedule will look like, and to chart out the dates along with the themes. A release schedule for the entire calendar year can be published in the final quarter of the previous year. This gives a semblance of predictability for the business on when the releases are expected, and when the enhancements and other changes are due to go in .
Release Reviews
Releases and changes are similar. Like a postimplementation review for a change, a similar exercise called a release implementation review is conducted after every major release. The objectives are to understand how things played out and to identify missteps, and subsequently the lessons learned from the release. This will help better the upcoming releases, and takes the service provider a notch above in the maturity scale.
Waterfall vs. Agile/DevOps
Let me explain how releases work in a waterfall project, compared with a project that is run in Agile/DevOps mode.
Consider there are three features that are to be developed. In a waterfall approach, all the three features are developed first, then tested, and then deployed/released into production.
If the same project was to be executed in an Agile/DevOps fashion, the development, testing, and deployment of the three features are done iteratively. If the release plan demands that the three features be deployed to production in a single release, then each of the features are independently deployed into lower environments, packaged, and released all at once to production.
Waterfall vs. Agile/DevOps releases
Release Management in Agile/DevOps
In Agile/DevOps projects, release management has not been completely transformed. It has become stronger through iterations. The activities in release management are now viewed by a different lens that’s ready to accept the facts based on the things at hand, rather than foretelling the future.
Using Agile Release Trains
The range of planning that we have started to do under releases is not limited to a sprint alone, which is the Agile/Scrum way of working. However, using the SAFe framework and applying release management to Agile release trains (ARTs) gives us a steady plan for the upcoming 10 to 12 weeks. The entire ART represents a release with software packages pouring in every couple of weeks at the end of each sprint. When we put the sprints together along with their outcomes, the end product is the release package.
Applying Release Management to Continuous Deployment
In the DevOps world, the release management process can be adapted depending on the kind of process (continuous delivery or continuous deployment) we leverage. Let’s say that we plan to employ continuous deployment where every time a package is tested successfully, it gets deployed automatically. Release management’s role here is to ensure that the path to production is stable, relevant, and consistent.
The release management process will have a lot of planning and execution during the initial two phases rather than the final two phases. Still, if a faulty package makes its way to production, the ball falls back into the release management’s court to fix the pipeline and the associated factors that make the pipeline work (such as testing scenarios, scripts, and so on). Also, release management has to identify multiple release windows for the deployments to take place because the possibility of deployments happening multiple times a day is routine in a continuous deployment process.
Applying Release Management to Continuous Delivery
In continuous delivery, however, sanity can be maintained to a certain extent. The release management process becomes bimodal, with release planning and builds/tests using the iteration model, and deployments and reviews taking the traditional sequential approach.
The plan for continuous delivery works well with ART, with the planning exercise being done once every 12 weeks and refined as the sprints go along. The sprints are executed in iterations with the software packages, getting them to a state of readiness but not getting deployed. When all the pieces of the release are developed and integrated, the deployment happens (sequential) followed by a review of the release.
Most organizations will tend to go with this approach, mainly because it gives people in charge a sense of control. Since continuous delivery still commands a manual trigger before deployment, the decision makers feel comfortable in opting for a process that not only accelerates production but also awaits a formal order before hitting production.
Maturity is leading the way toward continuous deployment. The decision makers, after a few releases, will realize that their decisions have always been backed by the figures, that the releases put forth in front of them have always been good for production, and that their decisions have become just a formality. So, the end game will always be with continuous deployment.
Release Management Techniques
Although in DevOps we intend to be brave and encourage experimentation, the core principle of reducing risks for existing services is not sacrificed. While we make rapid changes to the service, the software, the hardware, and other pieces of the services that users enjoy, the transition to the upgraded service should be as seamless as possible. To achieve this, we leverage a few techniques that help us mitigate the risks that come with making changes to stable environments.
Proof of Concept and Pilot
While making major changes to a product or a service, we first test the waters by carrying out a proof of concept (POC). The purpose of a POC is to prove that the path you are embarking on does work and to avoid progressing too far ahead with development and testing, only to find out that the end result you are trying to achieve is not possible. POCs are generally carried out if you are making architectural changes, technology changes, and introducing new concepts.
For example, a bank moving from mainframe technology to a SAP-based technology for running their banking engines would like to see some critical transactions demonstrated on a SAP platform before they can give their go-ahead for full blown development. If you are introducing test automation on a product, you probably would like to see if it works through a POC before start making a full-fledged journey. Likewise, changes that are transformational in nature could take the POC route to give the sponsors confidence that the solution does indeed work.
Well, POC is just half the battle in convincing the sponsors and other stakeholders that a particular solution does work. After the success of a POC, stakeholders often initiate the next phase of development, called the pilot phase, and not full blown development.
A pilot is the next step in the development process after POC, where the idea is to take a piece of the functionality, develop and test it, and run it against real data. A successful outcome further proves that the path taken indeed does work. The pilot release testers will be limited; call them a private group who test the developed functionality and give their feedback.
Do not get confused between pilot and beta releases. Both are different. In a pilot release, you only develop a small piece of functionality to prove that the overall solution will follow suit. A beta release is generally buggy, meaning the testing and fixing is still in flight. A beta release will consist of either the entire solution or a solution that is reaching completion.
Blue–Green Release
Blue-green release approach
We have two parallel environments, designated as blue and green. Both the environments are identical; however, one of them is active and the other passive. In this example, let’s say that the blue environment is active and the green is passive. This refers to the load balancer routing all the user requests only to the blue environment and not to the green environment.
Let’s say that we have a release on hand that requires mandatory downtime to install and configure packages, followed by elongated sanity reviews. In this scenario, the passive node (green) gets deployed first. As there are no user requests getting routed, there is no question of seeking downtime. The users continue to operate normally in the blue environment. When the deployment is successful and the environment is production ready, the load balancer routes all the user requests to the green environment. While users are busy operating in the green environment, the blue environment goes down, gets deployed, and becomes production ready. The load balancer can either be set back to blue or be shared between green and blue; this is a decision of the architects. Voila! Both the environments have been deployed with packages that required downtime, but the users never felt the effects of the downtime .
Feature Toggles (aka Feature Flags)
Using feature toggles is a software development technique whereby you effect feature changes without making changes to the code. During the design and development life cycle, developers employ the branching technique to create multiple feature branches. Feature toggles (switches) are introduced that turns on or off the feature based on certain criteria.
Feature toggles illustration
Come December when Christmas shopping sets in, feature F1, which is designed to introduce certain promotions to attract buyers, is activated (i.e., toggle turned on). Users will be able to see feature F1 in action. All these feature changes were introduced without making code changes; all that was done was changes to the toggle switches through a configuration file .
Use of feature toggles is an effective technique to minimize the risks that are introduced due to changes being introduced in the system. Imagine that during the Christmas shopping time, you make a code change and a bug in the system brings down the entire portal for 20 minutes. The downtime results in losses to revenue and portal reputation. To avoid such misadventures, feature toggles are introduced well ahead of time and, as and when they’re needed, are turned on and off.
This is not the only application of feature toggles. You can segregate your user community based on various criteria, be it the level of service that is subscribed, geography, etc. Using feature toggles, users in the UK get features F1 and F2, users in the United States get F2 and F3, and users in India can enjoy all the features (F1, F2, and F3), for example .
Engagement with Service Value Chain
Deployment Management
ITIL Definitionof Deployment Management Practice
The purpose of the deployment management practice is to move new or changed hardware, software, documentation, processes, or any other component to live environments. It may also be involved in deploying components to other environments for testing or staging.
The practice exists to provide guidance around deployments. A general misunderstanding is that deployments refer to moving packages to the production environment alone. However, it is not true. Moving software packages to any of the lower environments as well are deployments. Deployment essentially means movement from point A to point B. The point A is most likely an artifact repository and point B could be any of the environments that are under the scope of the deployment management practice.
Also, deployments are generally referred to as software package movement to environments. From the ITIL 4 point of view, deployment of infrastructure also comes under the practice’s purview. Deployment of infrastructure is an infrastructure-based activity, so how does it relate to moving from one place to another, you might ask. Today, most of the infrastructure in vogue is in the cloud, and provisioning infrastructure is generally a coding exercise. Using a code (referred to as Infrastructure as Code), infrastructure can be built in the cloud. So you are basically moving the resources from a generic pool to a specific pool and provisioning dedicated infrastructure for a dedicated use. This is essentially deployment of infrastructure, hence its inclusion in the ITIL 4’s scope under the deployment management practice.
- 1.
Deployment of software packages to lower and production environments
- 2.
Deployment of infrastructure for lower and production environments
Deployment Approaches
As discussed earlier, deployments are moving packages from point A to point B. The concept is simple enough, but think about the volume, complexity, and constraints that might exist. Compare it with a courier company such as DHL that needs to ship packages across the globe. How do they move their couriers around? Do they ship out every customer’s package separately or do they bundle their customers going to a particular location together? What if there are dangerous goods? Will those be sent on a plane along with the other packages, or will they go via a ship or other means. While you start thinking along these lines, you can understand how deployments are quite complex and why they warrant a separate practice, rightfully so.
- 1.
Big bang deployment
- 2.
Phased deployment
- 3.
Continuous delivery
- 4.
Pull deployment
Big Bang Deployment
The big bang option is derived from the big bang theory, which states how the universe came into being from a single super force. Likewise, when software is deployed, it gets deployed to everything that’s under the scope at the same moment. In other words, all users will get to experience the software (or the trauma of deployment) at the same time.
Big bang and phased deployment approaches
The upside is that all users will be in a position to enjoy the upgraded services at the same time, and the service provider can claim to be consistent with its services. This is generally preceded by a pilot (or multiple pilots) to ensure that the software does work.
When the pilot is deemed successful, a time is set and the users are made aware, and then the entire scope of the targeted system will receive the release package.
The big bang option is almost never considered in these modern times. You might have noticed that releases happen to certain smaller regions first (pilot) followed by, say, the United States. iOS updates are known to follow this pattern. The downside of deploying to everyone at once is pretty significant. Any screw-up will result in a disaster, and the negative business impact that follows is unbearable. Therefore, no organization likes to take chances by pushing everything out worldwide in one go .
Phased Deployment
The alternative to the big bang option is to deploy in a phased manner. In Figure 13-5, an initial pilot to a sample set of users is followed by a phased deployment to region 1 first, followed by regions 2, 3, and 4. It is OK for the deployments to have weeks and months between them to allow for the learning to sink in and corrective actions to be implemented before the following release. This is the biggest advantage of a phased approach. Organizations can manage their risks and target their audience based on various parameters. For example, say an organization would like to deploy packages during usual downtimes in different regions of the world. This may be the Diwali season in India, Christmas in the United Kingdom, and Rosh Hashanah in Israel.
I don’t see any obvious downsides to the phased approach except that it requires a lot of continued planning and differences in release version between users, so this may end up being a support challenge. But there are a number of ways to mitigate this.
Different features are deployed separately, so users can enjoy certain features first and then get the rest later.
All users face downtime at the same time, although the deployment happens in phases. This usually refers to a deployment taking place right on the tail of a previous one.
A combination of geographical deployments, feature-wise deployments, and downtime for all
Continuous Delivery/Deployment
Continuous delivery/deployment
The simplicity exists because there are no constraints that hold the developed piece of functionality going into production. This is an ideal scenario that eases the way packages are delivered to customers with no frills or thrills. As you already know, in continuous delivery a manual trigger is needed to deploy into production; in continuous deployment, deployment into production is automated, meaning no manual triggers to move packages into production.
It is simple and straightforward. But it is not without its rank of risks. There is the burden of getting things right the first time, and the risk of exposing flaws to end users demands careful determination and perhaps quality checks; the role of humans in this process would be minimal. There is also an (over) dependence on automation to keep the pipelines flowing from the development’s continuous integration cycle until it is deployed into production. But getting continuous delivery to work is an outcome based on deep thinking and maturity of the organization in running DevOps and automation .
Pull Deployment
The previous three approaches we looked at were push approaches, where the packages were pushed from a tool to either production or to an end user machine. The end user did not have much of a choice other than to accept these packages. What if the end user was in the middle of a client presentation when a software package is pushed that is overt in nature. Think of those restart messages that you get on your laptops and how annoying they can be when you are in the midst of some activity. I can say that I share your pain!
Imagine if you had the power to install the packages when you needed rather than when they —like after completing all your work and just before you are about to log out for the day. That would be wonderful, in my opinion.
The pull deployment option does exist, although it’s not as popular as the other three approaches. In this approach, software packages are made available to users and users are notified of it. So users will basically follow a set of instructions (like clicking a specific link) to pull the packages at their own time. The software packages usually reside in a software repository called a definitive media library (DML), and the users will be provided access to download a package and permission to install it on their laptops.
One of the common processes to achieve this is through the service requests management practice. Say that a user wants some software and he is required to log a service request with appropriate details. After the service request gets approved, an email gets shot out with a link or a notification message from a pull deployment software pop-up. The user can choose to trigger the software package installation/movement at their convenience. This method is effective in ensuring that the user’s productivity does not get affected and to ensure maximum customer satisfaction feedback.
This might not be an all-weather option. If there are urgent security updates that need to go in sooner than later, then pushing in a big bang way is possibly the best option. In conclusion, an organization needs to have all the options up its sleeve and should use the approaches in appropriate circumstances .
The term deployment could also refer to retiring certain features, which necessarily means cleaning up of code and updating the older packages with newer ones.
Deployment Process
Deployment management is a practice from the technical management group in ITIL. It should not be mistaken for a practice that deals with tools and techniques only. There are process aspects that are critical to making the practice’s objective a success.
- 1.
Deployment planning
- 2.
Deployments
- 3.
Review and close
Deployment Planning
A good plan wins you half the battle. When it comes to deployments, it is no different. You need to plan the deployment in terms of the timing, the approach, and the people involved in carrying out the deployment. Next, the mode of deployment is also important. Is it manually done or through automation or a mix of both?
Sort Out Ownership
First and foremost, the ownership needs to be sorted out. Who is going to perform the deployments? Common sense says that the team responsible for the operational aspects of the environment must carry out the release activities. This is an ideal way to keep the accountability with a single team and not keep the environments vulnerable to changes by multiple groups.
Complex Environments
How do you deal with an environment where multiple suppliers are involved?
It is important to start drawing the boundaries and responsibilities for every supplier. Your outcome will likely say, for example, that supplier A is responsible for all changes pertaining to an SAP system. All packages that are to be deployed into SAP need to be vetted by the SAP team.
This can be achieved with a strong CMS in place. Unless you have a good CMS in the organization, you wouldn’t know what systems exist and how they interact with each other. Without this information, you would be shooting in the dark at best.
Keep Processes Consistent but not Common for Environments
There are multiple environments in any organization where software packages move. The same level of scrutiny is not needed for all the environments. A different process for every environment is practical. However, keep these processes consistent for all the deployments that go in.
For example, for a test environment, you may seek a one-step approval from the development manager before a package is moved to the environment. The approval is a stamp that all the bugs that are identified in the development environment are fixed to satisfactory levels. For moving to the UAT environment, you may require two sets of approvals: one from the test manager and the next from a product owner. Moving the changes to production may follow the change control process. So, you will find that the process to move packages is different for every environment but it is consistent for all suppliers and teams that are involved.
Infrastructure Deployments
Infrastructure deployments work similar to software packages. The service provider generally holds the ownership to infrastructure. As and when new infrastructure components are needed, they are spun up; every new component deployment can be controlled.
What about deployments that the suppliers carry out? For example, Microsoft installs security patches and VMWare carries out urgent patches as well. If the supplier has a free run of installing patches as needed on host machines, then how does the service provider retain control of the infrastructure deployments?
It is imperative that either the suppliers provide the information (and seek approval) of patches that are being rolled out in advance, or provide the patches to the service provider to plan the deployments on their own. This way, the service providers will still remain in control, which is the right position to be in. You would want the owner to be fully in control of the changes that are proposed and that are going in.
Deployments
The actual deployment that is to be carried out is done during the change window for production deployments and during designated times for nonproduction environments; this is led by the processes for the particular environment.
The deployments are carried out based on the approach that has been agreed and the tooling that is identified. It is important that the people involved in deployments are the teams that have the ownership of deploying to the environment, and they will work closely with the other teams whose packages are getting moved. For example, if a supplier wants to install a COTS product plug-in into a production server, the supplier technician will also be present during the deployment activity, along with the operational team that has the ownership of the environments.
It is also a good idea to keep track of all activities performed during deployments. Keep a log that is timestamped, to help in future analysis as needed.
Deployment Reviews
Similar to conducting postimplementation reviews after carrying out a change, deployment-specific reviews must be employed as well. This provides an insight into the health of the deployment and a tool for learning and improving the maturity of the deployment process.
In DevOps, there is plenty of weight given to learning and experimentation. One of the best ways to learn is to record what was done and then review the logs to find inconsistencies.
Definitive Media Library
The DML is a repository for storing all licensed copies of procured software and software that has been developed in-house. The repository can be an online one or a physical one, but it needs to be access controlled.
The software that gets accepted into the DML is controlled by the change control practice, and only those copies that are authorized by change control into the DML are allowed to be used during the release and deployment management processes. The software that gets into the DML is expected to be analyzed, quality tested, and checked for vulnerabilities before getting accepted.
In the case of a physical DML where CDs, DVDs, and other storage media are used, it is expected that the storage facility is fireproof, can withstand the normal rigors of nature, and is secure against media thefts.
Medium to be used and the location for the master copies to be stored
Security arrangements for both online and offline storage
Access rights, including who has access and how it is controlled
The naming convention for the stored media to help in easy retrieval and tracking
What types of software go into the DML, for example, source codes or packages
Retention period
Audit plan, checklist, and process
Service continuity of DML if disaster strikes
Deployment Tooling
Deployments are carried out generally using tools. The days of manual deployments are soon approaching extinction.
The tools either are automated using an integrator tool such as Jenkins or Bamboo, or triggered manually by deployment personnel. Today, the preference is to build a pipeline wherein deployments are a part of the pipeline, to ensure consistency and avoid human intervention and hence errors.
Deployment tools are often integrated into the development suite such as Azure DevOps, where the Microsoft tool includes aspects of code management, user story management, and manages deployments as well, along with a host of other functionalities.
- 1.
Tools must have the functionality to store audit logs, which is critical for analysis and problem management activities
- 2.
There must be easy integration with the change control practice: say, for example, every deployment must be able to confirm the change request number and the status before it can trigger deployments.
- 3.
It goes without saying that deployment tools must be easy to use and stable to ensure consistency.
- 4.
Deployment tools must be flexible enough to integrate with the various development tools that are on the market, and also expose APIs so that even the bespoke tools, if any, could leverage the deployment tools.
- 5.
Integration with service request management tools will help in pull approach deployments, which has been discussed earlier.
- 6.
Integration with configuration management tools will ensure that the deployments are governed by the foundational practice, which is ideally the single source of truth .
Engagement with Service Value Chain
Knowledge Check
- 13-1.Which of the following is the correct release definition?
- A.
A version of a service or other configuration item, or a collection of configuration items, that is made available for use
- B.
A service that is deployed into an environment that is used by users
- C.
A deployment that consists of software and infrastructure packages that change the functionality of the service
- D.
Any change that has significance for the management of a service or other additions, removals, and modifications
- A.
- 13-2.Which of the following is not a type of release?
- A.
Major release
- B.
Standard release
- C.
Emergency release
- D.
Minor release
- A.
- 13-3.What is the difference between a POC and a pilot?
- A.
A POC is conducted to prove that the solution can be implemented. A pilot develops and implements a small piece of the functionality.
- B.
A POC is conducted to provide ample proof that the services are still valid. A pilot is used to ensure that the service is fit for purpose.
- C.
A POC is done to ensure sponsor engagement and to provide valid proof that the solution is valid. A pilot provides functional specifications that further provide proof that the solution is on the right path.
- D.
A POC is used to bring about transformation changes to a product or a service. A pilot is leveraged to identify a functionality that can be developed and tested successfully.
- A.
- 13-4.Which of the following is not a valid type of deployment approach?
- A.
Phased deployment
- B.
Continuous deployment
- C.
Continuous delivery
- D.
Emergency deployment
- A.
- 13-5.What is the role of a DML?
- A.
A repository where the software code is stored and is pushed to the pipeline for further building and testing
- B.
A repository that stores IT spares and software that can be accessed by valid personnel only
- C.
A repository for storing all the software used by the organization to provide services to end users
- D.
A repository for storing all licensed copies of procured software and software that has been developed in-house
- A.