Essential guide to CI/CD, ITIL and tools to bridge the two

Essential guide to CI/CD, ITIL and tools to bridge the two

Continuous integration and continuous deployment (CI/CD) drive software development and release in DevOps. Companies based in traditional ITIL practices often want to reap some of CI/CD’s benefits but aren’t sure how to combine the two.

In this article, learn the technology stack options for building a strong CI/CD pipeline, why companies rooted in ITIL are running CI/CD alongside, and best practices for a hybrid ITIL-CI/CD approach.

What is CI/CD?

CI/CD stands for continuous integration and continuous delivery or continuous deployment. These automated software development practices make it possible to release application updates on a fast cycle, sometimes several times a day or even hourly, without hurting performance.

Continuous integration, continuous delivery, and continuous deployment are closely related to each other, and most organizations see these functions as one pipeline.

The driving motivation behind CI/CD is to make the process of updating software smoother, faster and less risky. CI automates software building and testing, continuous delivery automates packaging, and continuous deployment automates deployment.

CI/CD allows change to proceed gradually, rather than with a big bang.

Without CI/CD, going live with code changes and system updates can be a white-knuckle experience. Bugs, conflicts, and even system failures arise more frequently. This can disrupt business operations and users.

What is continuous integration?

Continuous integration is an automated process that brings code changes from multiple developers together frequently. This triggers automation to build and test the new code.

Each developer works independently on their tasks. Then the team combines their changes in a central store daily or multiple times a day.

Each merge launches an automated CI sequence.

  • Building — Putting the new code into executable form. The specifics of this process vary depending on the programming language.
  • Analysis — Checking the new code for errors, security vulnerabilities, and quality or reliability issues.
  • Packaging – Preparing the new software for release by putting together all the code, scripts, metadata, and documentation needed to install the update.

Merging code updates frequently uncovers conflicts and integration problems much sooner than the traditional waterfall method. This speeds updates and improves software quality. Continuous integration requires developers to be in constant communication.

Continuous integration is a fundamental principle in Agile and DevOps cultures. (DevOps grew out of Agile, emerging around 2009.) They embrace delivering work in small batches, frequent iterations, and continuous learning. This contrasts with the older waterfall approach in which activities proceed sequentially.

What is continuous delivery?

Continuous delivery takes the code changes and prepares them for release using automation. This entails sending the code to a staging, non-production environment and more testing. In continuous delivery, teams prioritize making the software deployable at any time, on demand.

Automated testing enables the pipeline to process a continuous flow of updates that would be too much for people to coordinate and keep up with manually.

CD testing evaluates whether the code integrates with other parts of the main software or other applications (integration testing) and whether the software meets performance requirements (functional or end-to-end testing). There are other checks too. All these strive to determine how the new code will perform when it’s live.

One piece of continuous delivery is not automated, the final decision to deploy the release. A person must make that approval.

What is continuous deployment?

Continuous deployment is like continuous delivery except it automates deployment, rather than holding it for approval. Continuous deployment puts the software changes into production automatically, releasing the updated software to users without human intervention.

Since CI/CD involves frequent small updates, deployment usually happens in the background without any fanfare.

Continuous deployment makes software changes routine, with no downtime or code freezes and no impact on users. The practice decreases risk, and the benefits include speed, quality, and reliability.

CICD Stages

 

What Is the difference between CI and CD?

Continuous integration and continuous delivery/deployment work toward the same goal, to make software releases faster and more reliable. The differences among them are in scope and degree of automation.

Continuous integration is narrower in scope than CD, focusing on frequently merging small changes into an update. Teams just beginning a journey toward CI/CD often start here and do only CI for a while. CI automates the building and testing process.

CI is part of both continuous delivery and continuous deployment, however, continuous delivery and deployment both move beyond CI by automating the release process.

They diverge at the point of deployment. Continuous delivery needs manual approval of deployment. In continuous deployment, the code is put into production automatically.

Continuous integration vs continuous delivery vs continuous deployment

Continuous integration, continuous delivery, and continuous deployment act as a continuum. Each goes farther than its predecessor towards automating the software production pipeline.

An organization practicing CI/CD releases software changes to its users frequently. The cadence of development and deployment becomes regular and consistent. This contrasts with lengthy stretches of development time interspersed with stressful release days, when a big update may cause major disruption.

What Is the difference between CI/CD and DevOps?

Organizations that practice CI/CD often embrace DevOps, but there is confusion over how they relate. DevOps is a model that combines software development and operations functions to speed development and improve quality. CI/CD is a tool and principle of DevOps.

DevOps encompasses people, culture, and tools and grew from the Agile movement.

DevOps came about in response to inherent tension in the traditional siloed approach to development and operations.

On one hand, companies want to seize opportunities and meet customer needs rapidly. They want new software features and updated applications to pursue these goals.

Users also need system stability and availability, and operations is tasked with ensuring this.

These two forces historically put developers and operators in conflict. DevOps solved this problem by having the two teams collaborate closely or unify.

In DevOps, developers and operators have an integrated, highly automated workflow aimed at rapid release of high-quality software while maintaining a secure and stable system.

Tenets of the approach include:

  • Cross-functional, collaborative teams
  • Fast and frequent delivery of software releases
  • Continuous integration and delivery

Continuous integration and delivery are methods that enable the DevOps approach. As I discussed earlier, CI/CD powers a fast release cycle.

CI/CD vs ITIL

The predecessor to CI/CD was Change Management, one component of the ITIL (IT Infrastructure Library) framework. Rather than rapid and frequent releases, developers who employ Change Management use a phased, sequential release process that entails detailed planning and approval.

What is a CI/CD pipeline?

A CI/CD pipeline connects the steps in releasing new software into a continuous flow. The pipeline uses automation to trigger merging, testing, building, validating, delivering, and deploying an update. The pipeline path travels from new code to production.

Organizations typically use CI/CD platforms and services for their pipelines.

CICD Pipeline Graphic

Benefits of CI/CD

CI/CD reduces risk of software deployments and contributes to the stability and performance of the system through its lifecycle.

Other benefits include the following:

  • Quicker deployments
  • More reliable and robust system performance
  • Rapid detection of faults and vulnerabilities
  • Reduced frequency and duration of rollbacks
  • Decreased or eliminated downtime
  • Information sharing through alerting
  • Improvements in MTTR metrics such as mean time to recover, mean time to repair, mean time to restore
  • Ability to compare performance over time
  • Visibility into trends such as infrastructure demands and volume
  • Shorter lead time

CI/CD monitoring and CI/CD pipeline monitoring

CI/CD introduces two opportunities for monitoring. The first one is to manage your monitoring configuration in a source control system, and employ CI/CD to ensure that any new application is monitored before being deployed. In this model, the automated tests in your CI/CD pipeline would fail any code deployment that doesn’t include related monitoring and alerting rules. This strongly incentivizes developers to set up monitoring checks and alerts for their applications.

The other monitoring opportunity is to monitor the CI/CD pipeline itself. When the CI/CD pipeline is down, there is no production impact that directly affects your business. However, it does have a direct effect on developer velocity. A malfunctioning CI/CD pipeline means that developers can’t merge their code into version control (or at least can’t test it). It also means that can’t deploy their code to production. This significant slowdown in developer velocity has a major, albeit indirect, impact on the business. For this reason, it is highly encouraged to setup monitoring for your CI/CD pipeline and treat it as a mission critical service.

Monitoring vs observability in CI/CD

People confuse monitoring and observability, which are related. Observability represents the degree to which people can understand what is happening inside a system based on external outputs like data about performance. Monitoring is one activity that contributes to observability.

Observability is a property or quality of a system and relies on more than monitoring alone. Other activities that aid observability include alerting, visualization, logging, analytics, and tracing.

Continuous, total observability is a goal, but one that will probably always remain out of reach. It implies having a perfect ability to assess system performance and diagnose problems at all times.

Complexity generated by CI/CD

I’ve already talked about the many benefits of employing CI/CD. However, there are also new challenges that CI/CD introduces. CI/CD involves putting software through rapid changes, which increases the risk of incidents and potentially even customer-facing outages. The technology stack also undergoes more frequent changes, increasing fragmentation.

In order to build a strong technology stack that allows you to manage complexity better, it is beneficial to understand the hierarchy of management tools. There are three primary layers to IT management:

  • The bottom layer includes monitoring, change management, and configuration management. These management systems interact directly with your infrastructure.
  • The middle layer handles event correlation and automation. This layer stitches together disparate datasets from your various management tools, and drives process automation.
  • The upper-most layer consists of collaboration and communication tools, such as ticketing/ITSM, notifications/on-call, and chat.

Roles impacted by CI/CD

DevOps plays a central role in CI/CD. But CI/CD affects other personas as well, such as your Network Operations Center staff.

  • IT Service Manager – The IT service manager role originated in the older paradigm of ITSM. That approach focuses on governance, control and following best practices. The service manager role prioritizes the IT service lifecyle such as service strategy, design, and continuous improvement. CI/CD strives to accelerate the development and release process. ITSM’s change management best practices are often seen as obstacles to CI/CD. But many organizations see benefits in both ITSM and CI/CD. They adjust DevOps and service manager roles so the two can work together.
  • IT Operations Manager – The IT operations manager role is a subspecialty of IT Service Management in the ITIL approach. IT ops managers focus on the operations phase of the IT lifecycle. There is significant overlap with ITSM. Again, companies that want to reap the benefits of both ITIL and CI/CD look for ways for IT Ops managers to collaborate with DevOps engineers. Leveraging the automation at the heart of DevOps for ops management is one popular way.
  • NOC Engineer – The NOC (network operations center) engineer role has also evolved with the rise of CI/CD, primarily towards working more collaboratively with DevOps and learning to adapt to rapid change. Likewise, DevOps team members gain exposure to the NOC’s priorities, especially around issues that could affect business services.
  • Site Reliability Engineer – SREs have a lot in common with DevOps engineers. Both are cross functional roles, combining software engineering and operations. Both embrace automation and monitoring, both aim to dismantle siloes, and both seek to speed up the release process.

Site reliability engineering originated at Google in the early 2000s when the company brought software engineers into operations. SREs strive for stability and scalability, and they only launch software updates when system faults are within defined tolerances. SREs use CI/CD to reduce risk.

DevOps people strive for a rapid flow of work from development to production while also maintaining reliability and security. DevOps staff look to CI/CD to increase the velocity of software development.

Another difference is that the definition of DevOps is looser and more open to interpretation because there is no central authority on DevOps. Google framed SRE and published two books documenting the approach.

The two methodologies are not in conflict. It is often said that DevOps focuses on what to do while SRE focuses on how to do it.

The ITIL model and CI/CD

When practiced in their purest forms, ITIL and CI/CD are diametrically opposed ways of delivering and deploying software updates. But the two models coexist, and they hybridize and influence each other.

I’ll explore the reasons why shortly.

What is ITIL?

Britain’s Central Computer and Telecommunications Agency developed ITIL (IT Infrastructure Library) in the 1980s as a set of best practices to operate the full spectrum of IT services, including software development.

ITIL is a framework for IT service management, among other things, and strives to achieve efficiency and strong management of IT for the benefit of the business. ITIL has gone through several updates over the decades. In 2014, the British government set up a joint venture with a for-profit company to to take over management of ITIL.

The most recent version, ITIL 4, cites seven guiding principles designed to help those responsible benefit from these high level best practices.

  • Focus on value
  • Start where you are
  • Progress iteratively with feedback
  • Collaborate and promote visibility
  • Think and work holistically
  • Keep it simple and practical
  • Optimize and automate

Developments outside ITIL, notably the Agile movement and DevOps, heavily influenced this update.

Some developers and IT decision makers view ITIL as outdated and structurally misaligned with the goals, scale, and velocity of IT today. These people often are from companies born in the cloud era.

However, many organizations still use ITIL, which looks at technology as a service to the business. They include companies that have been around for decades and have large legacy systems on-premises or a hybrid of on-premises and cloud-based systems.

While CI/CD and Agile are all about constantly updating software to respond to evolving needs and market forces, the architecture of these legacy systems does not lend itself to rapid-fire, iterative change.

Legacy systems are designed as one unit, a model known as monolithic architecture. In today’s world of microservices and containerization, each component can run independently. This flexibility is a good fit for CI/CD.

In addition, some use cases and industries prioritize the advantages of ITIL – predictability, highly controlled change, and detailed service level agreements. Proponents perceive this as lowering risk.

Supporters include organizations that work in tightly regulated industries, with large stores of highly sensitive data, such as banking, healthcare, government and education.

Event management in ITIL

Under ITIL, event management is a defined process to monitor changes in state for business services. This could be human-initiated state changes (e.g. software deployment) or a machine-generated one (e.g. low memory on server).

Events can be informational (no action required), warnings (you may need to act to prevent a problem), and exceptions (something has gone wrong, and action is needed to resolve it).

An incident is an event, but not all events are incidents. Incidents are unexpected service disruption or system problem. Event management focuses on detecting and correcting events such as incidents.

With the increasing complexity of IT systems, billions of events can take place on a company’s network daily. These events produce alerts and alarms in a volume that exceeds human capacity to process.

So, companies have turned to automated solutions. Event correlation software ingests event data and detects problems. This speeds resolution and results in greater system stability.

The steps in this process are:

  1. Event notification – An automated monitoring solution sends a notification that an event has happened.
  2. Event detection – The tool assesses the event and interprets it.
  3. Event logging – The solution records the event and the follow-up actions.
  4. Event filtering and correlation – Insignificant events are filtered out. Then the event management system correlates event data to incidents and outages.
  5. Event response – Depending on the severity of the event, the system may automate responses or escalate an incident for action.
  6. Event closing – When the problem is fixed, the system logs and closes the event.

In the latest advance, event correlation has evolved from early rules-based solutions. The technology can now leverage artificial intelligence to identify the causes and solutions of incidents, a phenomenon called AIOps.

Change management in ITIL

In ITIL, change management is a process to execute updates smoothly with minimal risk of disruption. The change management process is top-down and rigid in ITSM compared with DevOps. As DevOps has grown, ITSM change management has become less popular

The steps in managing a change to systems and services in ITSM are:

  1. Log a request for change (RFC) – The department or person who has asked for the change provides a description, the reasons for the change, timeline, business justification, and other supporting details.
  2. Review change request – The change manager reviews the requests. They may reject some outright, seek more information on others, or move them forward for evaluation.
  3. Change evaluation – Depending on the scope of the change, this can be a detailed and formal process. A committee of evaluators, sometimes called a change advisory board, assesses how the change would affect other parts of the organization, the cost, risks, and technical merits. The group looks at the pros and cons of the change, and it ranks all requests in priority order.
  4. Change approval – If the committee decides to move forward, it approves the change request.

How change management compares to CI/CD

Companies with roots in ITIL/ITSM are curious about the potential to improve their change processes with DevOps. But some worry that the gaps between the two make it impossible to use both methods.

In some key respects, ITIL change management and CI/CD appear incompatible.

Attribute Change Management CI/CD
Process control Joint decision making by people Automation
Authority Structure Committee model Developer autonomy
Priority Safety Velocity
Risk mitigation Documented risk analysis and testing plan Automated testing
Orientation Service Innovation
Pace Limited, speed of people Fast, speed of machines

Organizations coming from ITIL may also worry that moving to CI/CD could compromise their security and compliance.  A hybrid model can enable them to have the best of both methods.

How ServiceNow seeks to enable DevOps

ITSM-driven companies are often loyal users of ServiceNow, a platform that facilitates ITIL practices. Many firms wish they could venture into DevOps from the comfort of the familiar ServiceNow environment.

ITIL will remain ServiceNow’s priority, but the company has sought to address this desire by offering third-party integrations that support DevOps and CI/CD activities. However, the fit is not seamless. ServiceNow, which was originally architected to support static and monolithic architectures, does not adapt to dynamic infrastructure, such as cloud, containers and microservices as easily. Many companies also find that its Change Management model is difficult to integrate into a CI/CD pipeline.

Pros and cons of ServiceNow’s approach to CI/CD

ITIL shops that want to try CI/CD have to weigh the advantages and disadvantages of ServiceNow’s approach.

On the plus side, ServiceNow facilitates traditional ITIL Change Management processes. This optimizes uptime, stability and compliance.

However, ServiceNow might not be the best tool for fast-changing environments such as CI/CD. The platform in its default state doesn’t deliver the full DevOps experience. In many ways, ServiceNow workflows mirror the slower pace of ITIL with its highly process-driven approach.

CI/CD is all about automation and enabling the pipeline to flow at the speed of machines by eliminating manual work. ITIL’s many gates and checkpoints are speed bumps that CI/CD wants to eliminate.

Companies that use ServiceNow may not be able to handle the volume of data required for successful automation and encounter bottlenecks.

Best practices for using CI/CD alongside ServiceNow

What’s the solution for companies that are happy with ServiceNow for ITIL but frustrated with its shortcomings in CI/CD? To run ITIL and CI/CD in parallel, they must convert automation’s firehose of data into actionable information on a human scale.

There are two key enablers for bridging this gap: event management and AIOps. Best practice for companies that want to pursue a hybrid approach is to use an AI-driven event management solution.

Next-gen event management tools leverage AIOps and move beyond the rules-based, manual approach. These solutions integrate into ServiceNow and all the sources of machine-data. This goes beyond the scope of traditional event management by ingesting alerts, change data, and information from different topology sources such as configuration management in virtualization environments.

These advanced event management solutions filter out static, cluster the alerts that remain into incidents, and correlate those to their causes. This enriched data provides root cause analysis.

An AI-powered event correlation engine, such as BigPanda’s, acts as a bridge between CI/CD and ITIL in ServiceNow by automating ITIL processes that are complex and slow-moving. Smart ticketing synchronizes incident data and ticketing tools, so ITIL companies can use their existing ticketing workflow.

Additionally, BigPanda can identify the root-cause of incidents logged into ServiceNow. It accomplishes that by collecting change data directly from CI/CD pipelines, and employ machine learning to correlate changes to incidents.

To learn more about BigPanda integrated with ServiceNow, click here.