Strategizing Continuous Delivery in the Cloud E-Book

Garima Bajpai

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 336

Veröffentlichungsjahr: 2023

Beschreibung

Many organizations are embracing cloud technology to remain competitive, but implementing and adopting development processes while modernizing a cloud-based ecosystem can be challenging.
Strategizing Continuous Delivery in Cloud helps you modernize continuous delivery and achieve infrastructure-application convergence in the cloud. You’ll learn the differences between cloud-based and traditional delivery approaches and develop a tailored strategy. You’ll discover how to secure your cloud delivery environment, ensure software security, run different test types, and test in the pre-production and production stages.
You’ll also get to grips with the prerequisites for onboarding cloud-based continuous delivery for organizational and technical aspects. Then, you’ll explore key aspects of readiness to overcome core challenges in your cloud journey, including GitOps, progressive delivery controllers, feature flagging, differences between cloud-based and traditional tools, and implementing cloud chaos engineering.
By the end of this book, you’ll be well-equipped to select the right cloud environment and technologies for CD and be able to explore techniques for implementing CD in the cloud.

Leseprobe

Strategizing Continuous Delivery in the Cloud

Implement continuous delivery using modern cloud-native technology

Garima Bajpai

Thomas Schuetz

BIRMINGHAM—MUMBAI

Strategizing Continuous Delivery in the Cloud

Copyright © 2023 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Preet Ahuja

Publishing Product Manager: Vidhi Vashisth

Senior Editor: Runcil Rebello

Technical Editor: Arjun Varma

Copy Editor: Safis Editing

Project Coordinator: Ashwin Kharwa

Proofreader: Safis Editing

Indexer: Rekha Nair

Production Designer: Joshua Misquitta

Marketing Coordinator: Rohan Dobhal

First published: August 2023

Production reference: 1200723

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB

ISBN 978-1-83763-753-9

www.packtpub.com

I would like to thank Canada DevOps Community of Practice, where I have been able to brainstorm a lot of ideas with chapter leads and senior community members. I would also like to thank the open source community, which provides us with a platform to steer thought leadership in the DevOps and continuous delivery space, especially the Continuous Delivery Foundation ambassadors. My gratitude toward my co-author, Thomas, and the entire team of Packt; without them, I would not have been able to bring this book to life. Lastly, I would like to express my gratitude toward Amit Kumar Mishra and my daughter Akira for their relentless support and encouragement.

– Garima Bajpai

First and foremost, I would like to thank my loving partner, Jacqueline, for her patience while writing this book and her support. Second, I would like to thank all of the people who supported my journey to the cloud in the last few years. Last but not least, I also want to thank my students for asking challenging questions that found their way into this book and those people who reviewed and gave guidance for this book.

– Thomas Schuetz

Contributors

About the authors

Garima Bajpai is a thought leader and industry leader in DevOps and cloud technologies. She is the founder of DevOps Community of Practice, Canada. She leads the ambassador program for the Continuous Delivery Foundation. Some might know her as a course contributor and instructor for various DevOps courses from leading certification bodies. She has over two decades of experience leading large-scale R&D with a variety of different teams and has helped them adapt DevOps to be able to increase team productivity when it comes to cloud resource deployment. Furthermore, she has collaborated on and contributed to giving many international conference talks, written several technical blog posts, and published white papers.

Thomas Schuetz is a cloud-native engineer, advocate, and educator living in Austria with a strong technical background in systems engineering. He is specialized in cloud-native continuous delivery as well as infrastructure-as-code, is a Cloud Native Computing Foundation and Continuous Delivery Foundation Ambassador, as well as being the maintainer of some open source projects, such as Keptn and K8sGPT. Besides that, he shares his experience with students at the University of Applied Sciences Burgenland, Austria.

About the reviewers

Nidio Dolfini has majored in SI and has a post-graduate degree in the cloud, with more than 15 years of experience in the IT area, in which he has worked at educational and technological companies. For about seven years, he was an IT coordinator, obtaining leadership, management, and communication skills, which allowed him to develop a strategic vision and a results-oriented approach. It was then that he decided to swap the management part for the technical, and today, he currently works as a DevOps engineer and a cloud professor. He always keeps up to date with the current trends and best practices. His focus is to aid his team in building and maintaining a reliable and scalable infrastructure and always bringing innovation.

I would like to thank Naval, Eduardo Pato, Felgas, and Ferrazani for believing in me and for the opportunity given. Dudu, Dirceu, and Herbert, for always supporting me throughout my ventures. Ana, for her patience throughout the times I had to study and prepare this book review. Bia and Sophia for loving me regardless of how far they are, and Teacher Bruna for helping me with my English course.

Antonio Masucci (Anto) is an experienced software engineer known for his expertise in DevOps and platform engineering. With over a decade of experience, he began his career as a backend engineer before transitioning into roles focused on DevOps and continuous delivery.

Passionate about sharing knowledge, Anto actively engages with the continuous delivery and platform engineering communities through his popular YouTube channel, OutOfDevOps. Through this platform, he fosters discussions on the latest industry trends and practices.

Throughout his professional journey, Anto has led platform teams and spearheaded digital transformations in various industries, including gaming, publishing, automotive, and finance.

I would like to express my deepest gratitude to my loving wife and my wonderful children for their unwavering support throughout my journey. Their constant encouragement, understanding, and love have been my pillars of strength, fueling my passion and drive to succeed. I am forever grateful for their presence in my life and the countless sacrifices they have made to uplift and inspire me. I am truly blessed to have them by my side.

Table of Contents

Preface

Part 1: Foundation and Preparation for Continuous Delivery in the Cloud

1

Planning for Continuous Delivery in the Cloud

Understanding the CD ecosystem

Defining the CD ecosystem

Characteristics of the CD ecosystem

Key components of the CD ecosystem

Managing the CD ecosystem

Key benefits of CD

Benefits of CD in the cloud

From CI to CD

Progressive delivery

Cloud-based implementations of CD

Summary

Further reading

2

Understanding Cloud Delivery Models

Cloud deployment models

Cloud characteristics

Cloud service models

Why is continuous delivery different in the cloud?

Opportunities and risks of practicing cloud-based continuous delivery

Opportunities for continuous delivery in the cloud

Challenges of continuous delivery in the cloud

Summary

3

Creating a Successful Strategy and Preparing for Continuous Delivery

Strategic goals and objectives of modernizing CD in the cloud

Key frameworks for strategizing CD in the cloud

Simple illustrations of frameworks for CD in cloud initiatives

Connecting business, transformational, and operational strategies

Outlining organizational prerequisites for CD in the cloud

Co-existence of Agile, DevOps, and cloud technologies and practices

Focus on engineering excellence

Ability to collaborate with the legacy, monolithic world

Operating models embrace third-party service providers

Communication and collaboration

Upskilling goals for the organization

Organizing for CD in the cloud

Key skills to improve CD posture in the cloud

Modernizing for CD in the cloud

Implementation

Managing CD

Management metrics

Trending cloud-based CD tools

Summary

4

Setting Up and Scaling Continuous Delivery in the Cloud

Choosing the right cloud environment, model, and tools

Preparation

Strategic analysis

Initial selection

Adopting and managing a CD practice

Understanding and owning the culture for CD in the cloud

Shifting left – cost, risk, and security management

Challenges for security with cloud-native CD

Chaos engineering

CD practice and its evolution

Key requirements for scaling CI/CD

Summary

Part 2: Implementing Continuous Delivery

5

Finding Your Technical Strategy Toward Continuous Delivery in the Cloud

Ensuring the technical success of your deployment strategy

Exploring monolithic and microservice architectures

What are monoliths?

What are microservices?

Are monoliths bad, and should we always use microservices?

Cloud-native platforms and considerations

Large-scale strategies

Multi-stage and multi-cluster environments

Rolling out applications at a large scale

Summary

6

Achieving Successful Implementation with Supporting Technology

Drawing a big picture of your strategy

Continuous integration

Templating and Kubernetes operators

Kustomize

Helm

Operators

Infrastructure as Code

GitOps

Platforms and developer portals

Missing parts

Summary

7

Aiming for Velocity and Reducing Delivery Risks

The role of velocity in CD and associated risks

Why is velocity important?

How velocity reduces delivery risks

Measuring CD performance

Observability

Deployment strategies

Basics of scaling and deployment strategies

Rolling updates

Blue/green deployments

Canary releases

Feature flags

Levels of deployment strategies

Things that change when you use a strategy

Deploying and releasing

Summary

8

Security in Continuous Delivery and Testing Your Deployment

Security basics

Securing your CI/CD environment

Making the pipelines secure

Supporting tools and technologies

Central authentication/identity management

Secrets management

Policy enforcement controllers

Auditing

Managing human error

Building a culture that allows for mistakes

Talking about errors

Post-mortems/documentation

Automation/testing

Summary

Part 3: Best Practices and the Way Ahead

9

Best Practices and References

Establishing and adopting best practices

End-to-end responsibility

Developing in a cloud-friendly way

Loose coupling

12-factor apps

Use proper versioning, avoid “latest”

Split configuration in reusable parts

Delivery best practices

Pipeline as Code

Treat every build as a release candidate

Automated testing and quality gates

Preview environments

Security best practices

Supply-c Levels for Software Artifacts (SLSA)

Secret management

Immutable infrastructure

More best practices

Case studies

Case study 1 – Coca-Cola Argentina app development and product delivery

Case study 2 – automate deployments with CI/CD pipelines on Azure DevOps

Case study 3 – developing complete end-to-end CI/CD pipelines at Ericsson

Summary

10

Future Trends of Continuous Delivery

Key challenges of the current state of CD

Functional advancements

Architectural advancements

Operational advancements

Adoption challenges and key recommendations

Summary

11

Contributing to the Open Source Ecosystem

Overview of the CD open source ecosystem

Open source licensing

The governance model and maturity levels

Stewardship to the OSS projects

Sandbox, incubating, and graduating projects

How to be a contributor to the open source ecosystem of CD

Long-term sustainability

Funding and investment in CD in cloud projects

Key considerations in funding open source projects

Examples of well-funded open source projects

Vulnerability management

Summary

References and further reading material

12

Practical Assignments

Overview

Case study

Short description of the case study

How to approach the case study

More about tasks

More about possible solutions

Associated references

Task 1 – business alignment

Guidance toward a possible solution for Task 1

Business alignment

Tactical alignment

Task 2 – operational alignment

Guidance toward a possible solution for Task 2

Task 3 – technical architecture and strategy

Guidance toward a possible solution for Task 3

Task 4 – getting into the cloud

Guidance toward a possible solution for Task 4

Task 5 – advanced technologies

Guidance toward a possible solution for Task 5

Task 6 – security and compliance

Guidance toward a possible solution for Task 6

Task 7 – finding the tooling and necessary services to start to implement

Guidance toward a possible solution for Task 7

Summary

Index

Other Books You May Enjoy

Part 1: Foundation and Preparation for Continuous Delivery in the Cloud

This part focuses on continuous delivery concepts and their relevance and benefits. Furthermore, the characteristics and usages of cloud systems in the context of continuous delivery are elaborated upon.

This part contains the following chapters:

Chapter 1, Planning for Continuous Delivery in the CloudChapter 2, Understanding Cloud Delivery ModelsChapter 3, Creating a Successful Strategy and Preparing for Continuous DeliveryChapter 4, Setting Up and Scaling Continuous Delivery in the Cloud

1

Planning for Continuous Delivery in the Cloud

This chapter provides a brief introduction to continuous delivery (CD) concepts, their relevance, and their benefits. In addition, we will also describe the step-by-step implementation of CD with the help of some industry-wide used tools and techniques, as follows:

Understanding the CD ecosystemKey benefits of CDFrom continuous integration (CI) to CDProgressive deliveryCloud-based implementations of CD

Understanding the CD ecosystem

This chapter is intended to reflect the recent development and evolution of the software delivery approach, mostly focusing on changes to CD and connected advancements underpinned by the emergence of CI technologies, new tools, processes, practices, and management structures. To understand the advancements of CD in the cloud better, it is important to connect the dots and learn about internal and external factors influencing the advancement of CD. The term CD has been around for a long time; yet, let us start from the basics. The most widely referred definition of CD is provided by Jez Humble (and can be found at https://continuousdelivery.com/):

“Continuous Delivery is the ability to get the changes of all types of new features, config changes, bug fixes, and experiments into production or into the hands of the user safely and quickly in a sustainable way.”

With advancements in CD, there are several attempts to redefine or refine the definition of CD. For example, AWS (at https://aws.amazon.com/devops/continuous-delivery/) defines CD as follows:

“Continuous delivery is a software development practice where code changes are automatically prepared for a release to production.”

According to another definition by Azure (at https://docs.microsoft.com/en-us/devops/deliver/what-is-continuous-delivery), CD is defined as follows:

“Continuous delivery (CD) is the process of automating build, test, configuration, and deployment from a build to a production environment.”

To understand it from Google’s perspective (at https://cloud.google.com/solutions/continuous-delivery), it is simply the following:

“End-to-end automation from source to production.”

Although there are variances and differences in definitions of CD, it makes it easier for us to reflect that CD is evolving and is defined by a set of characteristics that work together in the ecosystem.

As we move ahead in this book, we will describe the building blocks of CD and their relationship.

Defining the CD ecosystem

For now, let’s try to understand the factors influencing the evolution of CD to define the ecosystem:

Speed: It is evident that most of the definitions of CD lead to automation, making it visible that speed is one of the core drivers for the evolution of the CD and its connected ecosystem. Many key advancements are linked to removing the bottleneck to speed and lead time: starting from the evolution of practices such as CI/CD to the explosion of cloud-based pre-built pipelines, as well as including automation in build-test-deploy practices.Security: The fundamental shift toward securing software and addressing key risks with the utmost priority has led to the systematic evolution of the CD ecosystem with new tools and techniques, including security from the inception stages of CD.Software development itself: Developers are inclined to move away from traditional approaches to software development to more modern ways with the integration of Agile methodology, making use of more progressive, efficient tools and processes to eliminate lead times and quality issues. One example of such an application is Azure Boards, which provides a choice of Agile planning tools, many of which work in combination with CD practices.Software life cycle management: With velocity, scale, interdependence, and the growing complexity of the software landscape comes the need to simplify software life cycle management. Quick discovery and fixing of software bugs, accelerating software updates, comprehensive assessment of dependencies, and razor-sharp focus on vulnerability management are essential elements.Software operations: Finally, the return on investment (ROI) on software is realized in production. DevOps, SRE, and the emergence of cloud-based services are revolutionizing our CD ecosystem with a focus on building cross-functional teams, platforms, and tools.

The preceding factors indicate that the CD ecosystem comprises dynamic internal and external components. Taking inspiration from a natural ecosystem, if we attempt to define the CD ecosystem, we come up with this:

The CD ecosystem is a distributed, adaptive, and techno-functional system of CD practices, processes, tools, and techniques that support the evolution of CD.

Characteristics of the CD ecosystem

In order to be able to deliver continuously, we need a system of practices, processes, tools, and techniques that are reliable and can produce repeatable results consistently. Some of the basic ingredients for providing such outcomes are the following:

Self-organizing and adaptive: The CD ecosystem, as with any other such system, must be in a state of equilibrium. No single specific outcome can drive the construct and choice of practices, tools, or techniques entirely. For example, speed is one driver for CD, but the ecosystem must have components that keep the ecosystem close to equilibrium by including components/tools through which dynamics of security, speed, quality, and value are presented in a balanced way.Dynamic: The CD ecosystem consists of evolving tools and practices and integrates with emerging technology, so it makes sense that the CD ecosystem is dynamic. For example, the evolution of Kubernetes from an internal container ecosystem at Google managed by a community of contributors into an enterprise-grade de facto orchestration engine, with its adoption by cloud providers, adds an array of new features to CD. Interoperability and event-driven architecture evolution are key areas of progress to emphasize the dynamic characteristic of the CD ecosystem.Distributed: The CD ecosystem should be able to provide our developers and practitioners with an array of tools and services. It connects directly to the evolution of the marketplace approach. For example, cloud service providers such as Azure enable you to build and deploy applications on an array of platforms and languages. Azure also offers two options for version control—Git and Azure Repos, and many more such choices.Supports an “as-a-service” model: With time, the key components of the CD ecosystem will be degraded or replaced by other new and advanced features. We must focus on a consumption-based model for features and measure their usage over time. One of the key drivers of an as-a-service model is that it helps to build a self-regulating and self-sustaining ecosystem. Many services from cloud-based CI/CD tools and application vendors have community versions and tiered subscriptions for on-premises, hybrid, or enterprise versions, supporting a pay-per-use pricing model.

Key components of the CD ecosystem

For any ecosystem to thrive, the key components must act together to advance it by catering to evolving demands. The CD ecosystem will continue to evolve if progressive tools and applications continue to challenge the status quo – right from basic CI/CD tools and applications for version control and workflow automation through to specialized cloud-native CI/CD tools that can be run on any cloud and build a strong progressive foundation anywhere.

The CD ecosystem comprises three key components that continuously steer the evolution of the ecosystem by delivering value within and outside the boundaries of the ecosystem CI/CD tools and applications: consumers, producers, and practitioners. Let us look at them in detail:

The role of CI/CD tools and applications as a consumer: The increasing adoption of digital technologies creates huge market potential for CD. If CD provides a competitive advantage to organizations by delivering software features frequently reliably and cost-effectively, the ecosystem is bound to flourish. The role of consumers in the ecosystem is to provide feedback to CI/CD tools and application vendors and continue to experiment and modernize the CI/CD pipeline with progressive features, tools, and applications to help unlock new revenue streams.The role of CI/CD tools and applications as producers: The CI/CD ecosystem needs investment and integration with emerging technologies to facilitate a competitive advantage for consumers. The tools and applications that are the foundation of the CD ecosystem should also be the consumers of the ecosystem. For example, CI/CD tools and applications are often architected with microservices and rely on container-based deployment. They are designed to support interoperability and integrate well with other cloud-native tools and cloud-based services.The role of CI/CD practitioners as an actor in an ecosystem: The practitioners are the final actors in the ecosystem through which value is realized. The practitioners will churn out the waste in the CI/CD pipeline. Through the adoption of various tools and applications, practitioners will continuously optimize the ecosystem, and create perspectives on new applications, tools, and features. For example, pushing toward more interoperability standards with the rise of hybrid pipelines, the adoption of co-pilot features, and a more platform-centric approach toward CD to deliver software features seamlessly is paving the way for new developments.

Managing the CD ecosystem

Several organizations have already embarked on their CD journeys. With that, the need to effectively manage investments, develop and improve the current technical adoption, and steer strategic outcomes through CD becomes an urgent priority.

Many industry reports highlight that the full potential of CI/CD and the connected ecosystem is yet to be realized. There are multiple reasons associated with this, such as siloed initiatives, ad hoc investment, and lack of upskilling. These factors indicate the need to manage the CI/CD landscape with a multidimensional outlook.

The management of CD also must be structured yet agile in a way. Planning, organizing, implementing, and monitoring the outcome of CD must be modern and fit for purpose. To avoid delays, bottlenecks, and constraints, the management process should be tailored to CD.

In this subsection, we will present some guidance on effectively managing CD. We will start with a CD reference architecture, further elaborate on the role of CD frameworks, and eventually highlight the need to have a CD Community of Practices (CoPs). In subsequent chapters, we will detail these aspects along with other important dimensions of creating and implementing CD in the cloud strategically:

CD reference architecture: This refers to the abstract concepts that can outline a structure or a construct for CD:Provides a common vocabularyProvides guidance about the functions and their interaction (e.g., APIs)Can be defined at a different level of abstractionCan be instantiated for a particular domain or specific projectsCan be mapped to specific sets of goals, as no single architecture can fulfill all needs

An example of a reference architecture and associated service offering in the cloud is Open Source on AWS: https://aws.amazon.com/blogs/devops/choosing-a-well-architected-ci-cd-approach-open-source-on-aws/.

Another example of a CD reference architecture is one being worked on by the Continuous Delivery Foundation (CDF):

A CD framework: A framework is a pre-built general or special-purpose architecture that’s designed to be extended for a set of consumers, such as the healthcare industry, the defense sector, or the financial community. CD tools, along with cloud technologies, are constantly undergoing changes to improve the software development environment and practices. It is hard to keep pace with upskilling without structured support from the community of practitioners.

As an example of a community of practice, here are a collection of technical articles and blogs published or curated by Google Cloud Developer Advocates: https://medium.com/google-cloud.

The AWS Community Builders program is one of the unique programs launched by AWS for the community of practitioners to share resources and educational content and build a networking ecosystem to support the community.

Other communities provide similar guidance: the DevOps Institute’s DevOps in the Wild community and the CDF community for open source CD tools and best practices, to name two.

So far, we have introduced some terminology we will use throughout the book, and this section has ensured that you have a good understanding of the main concepts of CD and its key components. We also touched upon the aspects of CD in the cloud, which will be illustrated in the following chapters in detail.

Key benefits of CD

In this section, we will look at the benefits of CD in more detail. Building upon the idea of the key characteristics of CD being speed, enabling security and progressive practices for software development, and operation and life cycle management, let’s look at the benefits.

There are some industry references. DevOps Research And Assessment (DORA) is an initiative by Google to support organizations to achieve high performance by embracing DevOps according to actionable guidance, DORA metrics (https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance), which can give you a measure of the positive business outcomes from adopting CD. For us, it will be easier to map the key characteristics to the business outcomes and key benefits of CD:

Characteristics of CD

Description

Business outcome

Speed

How frequently can we release?

% gains on market shares from launching new products and services

Security

How trustworthy are we?

% reduction of the cost of risk mitigation and cost avoidance of security breaches

Agility in software development

How fast can we respond to the changing needs of the customer?

% revenue gains on the accelerated time to market for changes and new products

Simplifying software life cycle management

How resilient are we?

% gains from the cost reduction of application failures

Collaboration with software operations

How effectively do we communicate and share information between teams?

% gains from enhanced team productivity

Table 1.1 — Mapping CD characteristics to key benefits

Let us now look at the benefits of CD in the cloud.

Benefits of CD in the cloud

Taking one step forward, cloud service providers combined the benefits with the service offerings to facilitate better business outcomes:

Characteristics of CD

Business outcome

Service offering of cloud service providers

Speed

% gains on market share from launching new products and services

Automate the software delivery process through an already tested CI/CD pipeline.

Improve developer productivity by removing mundane tasks.

Agility in software development

% revenue gains on accelerated time to market for changes and new products

Feature development in increments, which are discrete and small so they can be delivered with agility.

Security

% reduction of the cost of a long list of risk mitigation and cost avoidance strategies aimed at security breaches

Cloud providers offer a marketplace of security tools, which can be easily integrated with the pre-built pipelines through APIs.

Simplifying software life cycle management

% gains from the cost reduction of application failures

With managed services from cloud providers, it is easier to roll out updates. What used to take weeks and months can now be done in days or even hours.

Collaboration with software operations

% gains from enhanced team productivity

Implementing practices adopted by several organizations.

Example: AWS has a number of certified DevOps Partners who can provide resources and tooling.

Table 1.2 — Mapping CD’s benefits to cloud service provider offering

In this section, you read a short overview of the CD ecosystem and how it can help you in achieving your goals. In the next sections, you will be introduced to the differences between CI and CD and where CD in the cloud can support you.

From CI to CD

When delivering software to our customers, the customer assumes that it runs reliably and without significant problems. Any misfunction or outage of the software—depending on its purpose—might lead to a loss of reputation on the customer side and the people and company that developed the software. Think of an issue where code was written weeks or months ago, the software is already deployed in the customer’s environment, and it crashes randomly after some time. While troubleshooting, we might tackle the following issues:

Time pressure: As the software has already been delivered to production and customers have been affected by its misbehavior, it is obvious to provide a resolution during this process. As people providing this might work under pressure, it’s not unlikely that new issues might be introduced.Determine which change introduced the misbehavior: In our case, the change might have been introduced a long time ago, so one of our major challenges might be finding out when or in which context the change has been introduced.Finding the needle in the haystack: Our software might consist of lots of components. If we can’t find out which change introduced the issue, we might want to find where in the code it happens.Dev/prod parity: As our working copy of the code might already have progressed further than the version we are fixing the issue for, we will also have to update newer versions of the software.

These are only examples of problems we might face while fixing such issues. To tackle such cases, we want to find problems in our software very early and build automation around building, testing, and publishing artifacts, called CI. The process of CI should ensure that the code checked in is continuously built and tested. Therefore, problems are found at a very early stage.

Using CI and CD methods, we can find problems early and avoid them hitting the customer’s system. Before we dive deeper into CD processes and implementation, we will take a brief look at the building blocks of a typical CI/CD infrastructure:

Figure 1.1 – Building blocks of a CD infrastructure

In current development setups, developers store their code in source code management (SCM) systems, such as Git, Mercurial, or Subversion. CI systems, such as Jenkins or Tekton, can either watch these repositories for changes on specific branches or tags or get triggered by the SCM systems to initiate workflows. These workflows may include static code analysis steps, such as linting and static security checks, before building, but also more dynamic tests, which can only be done against the running system, such as API tests or Dynamic Application Security tests.

Usually, these steps run on every commit in so-called feature branches. At some point in time, a developer might decide that a developed code part (feature) might be finished and therefore include it in the shared code base and raise a pull or merge request. As a best practice, there might be code reviews for this integration step, which can be automatic or manual. Humans will do the manual part. Furthermore, automatic checks can be done by a CI workflow, which should ensure that the code checked into the code repository is not only compilable but also stable and, in the best case, secure.

Depending on the release strategy, a successful merge to a central shared repository could trigger the CD process. This could also be done when the code is merged into specific branches or with defined tags. As discussed in later chapters of this book, the code will be deployed in various environments (stages) during the further CD process, and tests should ensure that the software is in a deployable state at the end of the process, and that deliverable artifacts are available. Although the terms CI and CD are often used interchangeably, the process of deploying automatically to the production systems is called CD.

In this section, we learned that it is important to find problems in software early by building and testing software continuously. Furthermore, CD helps us keep the software in a deployable state at any time. Last but not least, CD can help us in accelerating our time to market by deploying to production automatically.

Progressive delivery

Many issues could come up with continuously deploying to production. Even if the software is tested well during the previous phases and our deployment mechanisms are working perfectly, we can encounter situations where everything is running from a technical perspective and still the experience for the end users is very dissatisfying. For instance, a customer might click on a button on a website, and it takes about 30 seconds to get a response, although there is not much load on the system. Such things could come up because the software is not tested under the conditions present in the production environment, and the things users are executing have not been tested in this constellation before. Long story short, we should always aim to deploy our software often and automatically, but we need additional mechanisms that safeguard our deployment process. One of them is progressive delivery.

“Progressive delivery is the process of pushing changes to a product iteratively, first to a small audience and then to increasingly larger audiences to maintain quality control.”

(Orit Golowinski, https://www.devopsinstitute.com/progressive-delivery-7-methods/)

Using progressive delivery, the software is deployed in a phased way, ensuring that not all users are affected by a problem. In Chapter 6, we will take a closer look at Blue-Green Deployments and Canary Releases, which can be used to not only create preview environments but also to