Mastering DevOps on Microsoft Power Platform E-Book

Uroš Kastelic

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

Seitenzahl: 643

Veröffentlichungsjahr: 2024

Beschreibung

Mastering DevOps on Microsoft Power Platform is your guide to revolutionizing business-critical solution development. Written by two Microsoft Technology Specialists with extensive experience in enterprise-scale Power Platform implementations and DevOps practices, this book teaches you how to design, build, and secure efficient DevOps processes by adapting custom software development practices to the Power Platform toolset, dramatically reducing time, cost, and errors in app modernization and quality assurance.
The book introduces application life cycle management (ALM) and DevOps-enabled architecture, design patterns, and CI/CD practices, showing you why companies adopt DevOps with Power Platform. You'll master environment and solution management using Dataverse, Git, the Power Platform CLI, Azure DevOps, and GitHub Copilot.
Implementing the shift-left approach in DevSecOps using GitHub Advanced Security features, you’ll create a Power Platform tenant governed by controls, automated tests, and backlog management. You’ll also discover advanced concepts, such as fusion architecture, pro-dev extensibility, and AI-infused applications, along with tips to avoid common pitfalls.
By the end of this book, you’ll be able to build CI/CD pipelines from development to production, enhancing the life cycle of your business solutions on Power Platform.

Leseprobe

Mastering DevOps on Microsoft Power Platform

Build, deploy, and secure low-code solutions on Power Platform using Azure DevOps and GitHub

Uroš Kastelic

József Zoltán Vadkerti

Mastering DevOps on Microsoft Power Platform

Copyright © 2024 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: Surbhi Suman

Book Project Manager: Uma Devi

Senior Editor: Runcil Rebello

Technical Editor: Yash Bhanushali

Copy Editor: Safis Editing

Proofreader: Runcil Rebello

Indexer: Tejal Soni

Production Designer: Prashant Ghare

DevRel Marketing Coordinator: Marylou De Mello

First published: September 2024

Production reference: 1090824

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB, UK

ISBN 978-1-83588-084-5

www.packtpub.com

To my rock-solid life partner and our three extraordinary kids. Thank you for your tremendous support, patience, and inspiration to be more.

- Uroš Kastelic

To my beloved little warriors, Nandor, Botond, and Marton, who bravely faced the long, dark winter weekends with independence and imagination, allowing me the time to bring this book to life. And to the light of my life, my dear wife, whose unwavering support and love made this journey possible. Without her, I would not have dared to embark on this adventure.

– József Zoltán Vadkerti

Contributors

About the authors

Uroš Kastelic is a technology specialist in low-code/no-code at Microsoft, where he helps large enterprise customers implement and adopt Microsoft Power Platform. He holds a Master of Science (M.Sc.) degree in computer and information science. Prior to joining Microsoft, he worked as a software developer on various projects. He joined Microsoft in 2014 and has worked in different roles. For the last five years, he has been helping organizations with their application modernization projects and the implementation of DevOps practices, supported by Microsoft Azure services. He is a Microsoft Certified Trainer and an Expert with many certifications in Microsoft Azure and Power Platform technology, as well as being actively engaged in various tech communities.

I would like to extend my gratitude to my parents, who taught me to always reach for the stars. I would also like to thank Microsoft for helping me to grow professionally and personally. Thank you, the Packt team and technical reviewers, for the support throughout the writing process and making this book possible.

József Zoltán Vadkerti is a senior technology specialist at Microsoft with a computer science (MSC) degree from the Karlsruhe Institute of Technology. He has almost 20 years of experience in software development. Since 2015, he has been working in different roles for Microsoft, with a focus on application development and innovation. He has deep technical knowledge of Microsoft Azure, cloud-native architecture, serverless, DevOps practices, applied AI, and Microsoft Platform. He is a Project Management Professional (PMP®), Microsoft Certified Trainer, Azure Solution Architect Expert, and DevOps Engineer Expert. Today, he is one of the most experienced Power Platform professionals at Microsoft in the CEE and MEA region. József currently resides in Budapest with his wife and three boys.

I extend my deepest gratitude to my family, my wife, and my three heroes, who inspired me to undertake the writing of this book. I would also like to thank my employer, Microsoft, for fostering an environment where I could “learn it all” and empowering me to share this knowledge widely so that, together, we all achieve more.

About the reviewers

Ralph Rivas is a seasoned professional with over two decades of experience delivering quality software and solutions, currently with Sogeti, part of Capgemini, where he works in the corporate Applications and Cloud Technologies group, focused specifically on Power Platform and the M365 ecosystem, actively promoting and growing technologies and features to help customers make the most of their digital modernization journey. More recently, he has also been part of the global technology team, promoting and advancing low-code and Gen AI platform initiatives aligned with Microsoft and the industry.

As an MS MVP for BizApps, he is a frequent speaker at many community events as well as being the Chicago UG leader and cofounder of the M365 Chicago Community Days event.

Praveen Gujar is a distinguished product leader having a transformative impact on digital advertising, ML/AI, and cloud technologies, honed at LinkedIn, Twitter, and Amazon Web Services. Renowned for building large-scale enterprise products and driving business growth, Praveen transitioned from a hands-on engineer to a strategic technology leader. At LinkedIn, he spearheaded AI/ML-powered products, co-founded the DataHub and Business Manager platforms, and enhanced advertiser trust through AI models. Additionally, he leads LinkedIn’s Associate Product Manager intern program and mentors emerging tech professionals. Praveen’s career is marked by innovation, strategic vision, and a commitment to mentorship.

Osazee Odigie currently works as a senior consultant at Deloitte, UK, where he is actively involved in delivering cloud transformation and business application development projects. He has worked in the technology space for more than six years as a platform engineer and Power Platform developer. A strong advocate of Infrastructure as Code (IaC) and open source applications, he specializes in building IaC accelerators for Microsoft Business Applications development. He volunteers for the Microsoft Power Platform Connectors open-source project and has developed two premium connectors published by Microsoft.

Table of Contents

Preface

Part 1: Understanding DevOps on Microsoft Power Platform

1

Mastering DevOps and ALM for Efficient Software Development

SDLC – what it is all about

Phases

Methodologies

Agile, Scrum, and Lean

The Agile manifesto

Lean management

Scrum

What is ALM?

CI and CD

DevOps-enabled architecture patterns

Summary

Further reading

2

Getting Started with Microsoft Power Platform

Technical requirements

The rise of low-code/no-code

The current and the future state of LCNC development

Understanding the benefits of LCNC

Getting started with Microsoft Power Platform services

What is Microsoft Power Platform?

Setting up our first environment

Power Platform administration

The Power Platform admin center

Power Platform management and automation for administrators, makers, and developers

Admin and management connectors

Governance, compliance, and data privacy

Data residency

Compliance offerings

Data protection

Starting to build real-world business solutions

Creating solutions using templates in Power Platform

Enterprise templates

Power Platform patterns

Other ways for building business solutions

Customer stories

Summary

Further reading

3

Exploring ALM and DevOps in Microsoft Power Platform

Why implement ALM and DevOps in Power Platform?

Plan and track

Development

Build and test

Deploy

Operate

Monitor and learn

ALM and DevOps tooling

Application modernization with an LCNC approach

Application modernization options

Building Power Platform adoption journey

The Power Platform adoption maturity model

Ways to improve the maturity level

Summary

Further reading

Part 2: Implementing DevOps on Microsoft Power Platform

4

Understanding Power Platform Environments and Solutions

Technical requirements

What comes to a solution?

Versioning of solutions and packages

What about data – Dataverse and data modeling aspects

Environments, managed environments, and environment strategy

Managed Environments

Environment strategies

Managed pipelines – Our first CI/CD

Power Platform pipelines

Step-by-step walkthrough – creating our first CI/CD pipeline

Summary

Further reading

5

Streamlining Power Platform Development with DevOps Tooling

Technical requirements

Git – the single source of truth

Power Platform CLI

Power Platform build tools for Azure DevOps

GitHub Actions for Power Platform

Managed pipelines – source control integration with Git

GitHub workflows

Dataverse with Power Automate cloud flows

Copilots in Power Platform pipeline development

Summary

Further reading

6

A Deep Dive into Continuous Integration/Continuous Deployment (CI/CD) Pipelines

Technical requirements

When everything comes together

Branches and environments

The Power Platform catalog

Azure pipeline templates and reusable GitHub workflows

The ALM Accelerator for Power Platform

Automated testing in DevOps and Power Platform pipelines

Summary

Further reading

7

An Overview of DevSecOps in Power Platform

Technical requirements

What is DevSecOps?

Setup

Plan and Design

Commit (CI)

Deploy (CD)

Operate and Monitor

Security model of Power Platform

Secret scanning and static code analysis tools

Solution checker

Spinning up DevSecOps projects at scale

Security of DevOps processes

Summary

Further reading

8

Demonstrating ALM and DevOps Implementation

Technical requirements

Exercise – repository management and branch strategies for the applications

Exercise – building CD pipelines and a release train

Exercise – backlog management in GitHub

Exercise – testing solutions

Exercise – monitoring the applications

Exercise – introducing feature flags

Summary

Further reading

Part 3: Exploring DevOps Best Practices and the Road Ahead

9

Implementing the Fusion Development Approach

Technical requirements

What is the fusion development approach?

Common examples of the fusion development approach in Power Platform

Empowering collaboration with open source development practices

Building a catalog process

Additional tools for developers using Visual Studio

Microsoft Azure and Power Platform together

Application hosting services

Integration Services

Data analytics

AI services

Data storage

Example of an Azure and Power Platform integration scenario

Creating a Web API and a Power Platform custom connector with Visual Studio 2022

Creating a Power Platform custom connector with Azure APIM

Applying ALM to custom connectors

Summary

Further reading

10

Enabling Pro-Dev Extensibility in Power Platform

Technical requirements

Enabling the power of the integration – connectors

Connectors

Connection references

Environment variables

Example – Decoupling configuration from the application

Overview of canvas components and component libraries

Canvas components

Component libraries

Managing the life cycle of the component library

Getting to know code components

Code component composition

Creating your code component

ALM for code components

ALM for Power Pages

Use of the PAC CLI for Power Pages

Using Power Platform Build Tools with Power Pages

Using Power Platform pipelines with Power Pages

Summary

Further reading

11

Managing the Environment Life Cycle with Design Best Practices

Technical requirements

Building on the design best practices

Power Platform Well-Architected

Power Platform landing zones

Automating environment life cycle management

Infrastructure as code (IaC) over ClickOps

Power Platform management with Terraform

Traditional automated environment management approaches

DLP considerations when managing environments

Power Platform CoE

The CoE Starter Kit

Example of environment management

Summary

Further reading

12

Looking Ahead with Copilots, ChatOps, and AI-Infused Applications

Technical requirements

The era of AI and the rise of GPTs

Introduction to AI

GPTs

Responsible AI

Microsoft Copilots and Copilots in Power Platform

Copilots in Power Platform

Copilots’ usage from the perspective of a maker

Extending business solutions with AI Builder and Azure OpenAI

Introducing AI Builder

Using AI models and AI prompts

Introducing Azure OpenAI

ChatOps and Copilot Studio

A closer look at Copilot Studio

What is ChatOps

Integrating Microsoft Teams with GitHub and Azure DevOps

Building ChatOps for Power Platform with Copilot Studio

ALM for Copilot Studio

Summary

Further reading

Index

Other Books You May Enjoy

Preface

Microsoft Power Platform is the world’s leading low-code, no-code platform – a modern application runtime on which an infinite number of business solutions can be realized. The more complex and business-critical these scenarios become, the more need there is for professional DevOps processes. This book focuses on the well-known practices of custom software development projects and the mapping of these common activities to the Microsoft Power Platform toolset. We explore every phase of the software development life cycle and the tools and capabilities that are provided by this Software-as-a-Service (SaaS) product to delve into the usual DevOps activities, such as packaging, building, deploying, testing, and releasing solutions, in detail. In addition, we take a deep dive into DevSecOps processes and introduce the security-infused development practices in Microsoft Power Platform. You’ll learn about modern DevOps tools such as Azure DevOps Services and GitHub and the different ways to implement DevOps processes for Microsoft Power Platform. With the right DevOps implementation in place, our solutions can run in highly regulated industries in a controlled and governed manner.

We strongly believe that low code is for professional developers. Microsoft Power Platform is one of the rapid application development frameworks and the only framework that provides a UI for citizen developers (makers). The platform was created for professional developers and engineering teams to reduce the go-to-market time of business applications. But, this only works if it is backed by professional DevOps processes.

As a unique approach, this book brings these two orthogonal worlds together: low-code/no-code enthusiasts who can build complex solutions on one side and professional developers who know about DevOps and Application Life Cycle Management on the other side. This knowledge is a unique opportunity for you, dear reader, to build up competencies that will give you a compelling advantage in the job market.

As a final thought, with the rise of generative AI solutions, developers’ work will change significantly and the focus will shift to prompt engineering and larger building blocks. Since AI agents can act in different roles (as developers, testers, or project managers) and can synthesize applications on their own with only provided prompts, instead of writing code lines, we craft components. These components can correspond to the building blocks offered by Power Platform. Considering the Copilots for Power Platform, a kind of new application crafting era has just begun, which can only be successful if DevOps processes are implemented in the same way as in the case of custom development projects.

Who this book is for

This book is designed for professionals in the field of software development and IT operations who are interested in learning about Application Life Cycle Management (ALM) and DevOps processes specifically for Microsoft Power Platform. It is suitable for the following people:

Software developersDevOps engineersCloud architectsSite reliability engineersTestersLow-code engineers

The book will be particularly beneficial for those who already have a basic understanding of software development processes and tools used in software development life cycles. Additionally, it is an excellent resource for professional developers who are curious about the ALM and DevOps aspects of Power Platform.

What this book covers

Chapter 1, Mastering DevOps and ALM for Efficient Software Development, provides an overview of the most significant breakthroughs in the software development industry, such as Agile, Lean, and DevOps, and explains state-of-the-art application development processes and patterns, and cutting-edge DevOps and ALM practices.

Chapter 2, Getting Started with Microsoft Power Platform, starts by introducing the low-code/no-code development approach, provides an overview of Microsoft Power Platform services, and describes how the platform complies with various governance and compliance standards, making it an enterprise-ready development platform. It shows how to provision a trial environment that can be used to work along with examples provided in the book. It also dives into the tools for managing Power Platform and options for getting started building business applications.

Chapter 3, Exploring ALM and DevOps in Microsoft Power Platform, works on building a connection between ALM and DevOps with Power Platform. It provides a brief introduction to Azure DevOps and GitHub. To help organizations understand how Power Platform can be used against an existing application portfolio, this chapter talks about app modernization options. It closes by connecting the Capability Maturity Model Index (CMMI) and the Power Platform adoption maturity model, to help organizations create a plan to increase maturity across different areas.

Chapter 4, Understanding Power Platform Environments and Solutions, covers the fundamental building blocks of Power Platform: environments and solutions. It also discusses environment strategies, managed environments, and Power Platform pipelines. The chapter ends with a hands-on lab that guides us through building our first continuous-integration and continuous-delivery pipeline with the help of Power Platform pipelines.

Chapter 5, Streamlining Power Platform Development with DevOps Tooling, takes one step forward and unleashes tools beyond Power Platform pipelines. It discusses Git, PAC CLI, and Azure DevOps Services pipelines with Power Platform-specific build tasks and GitHub actions to CI/CD our solutions across environments. Finally, it combines the Power Platform managed pipeline results from the previous chapter with professional DevOps tools and looks at version control integration directly from managed pipelines.

Chapter 6, A Deep Dive into Continuous Integration/Continuous Deployment (CI/CD) Pipelines, describes advanced patterns of DevOps CI/CD processes, such as Git branching strategies, automated testing frameworks for Power Platform, and the Power Platform Catalog for package management. It walks through YAML pipelines in Azure DevOps and GitHub workflows that automatically spin up developer branches and developer environments respectively by using various PAC CLI commands, GitHub actions, and Azure DevOps build tasks. Additionally, it discusses the ALM Accelerator for Power Platform and how this solution uses pipeline templates, branching strategies, and environment management in general as reusable solutions for our projects.

Chapter 7, An Overview of DevSecOps in Power Platform, goes through the theory of DevSecOps in software development projects and then it maps security-related activities to DevOps processes of our Power Platform projects. It delves into GitHub Advanced Security and CodeQL for static application security testing. It introduces a solution checker and showcases how to spin up DevSecOps projects at scale with Entra ID groups, service principals, and other security guardrails in place. It concludes with a surface attack and risk analysis of established processes and recommendations to manage solutions across tenants.

Chapter 8, Demonstrating ALM and DevOps Implementation, takes a deep dive into the practical application of DevOps and ALM principles. This chapter provides hands-on exercises on a real-world example – the Kudos app from the Power Platform enterprise template public repository – from Git branching strategies to CI and CD pipelines through automated testing, backlog management, and monitoring applications in production. Finally, the chapter introduces feature flags to control feature rollouts.

Chapter 9, Implementing the Fusion Development Approach, emphasizes the importance of building fusion teams that help organizations reach their goals. It demonstrates examples of the fusion development approach and talks about the importance of InnerSource practice. Then, it continues with possibilities around integration with Microsoft Azure cloud services. Finally, it concludes by demonstrating a common Azure and Power Platform integration scenario.

Chapter 10, Enabling Pro-Dev Extensibility in Power Platform, continues explaining the possibilities pro-developers have when developing for Power Platform. It covers the power of connectors for integration scenarios and options around decoupling configuration from the application. It goes into reusable components and the power of custom code components. The chapter demonstrates how code components can be developed and how ALM practices can be applied to code components. The chapter ends by exploring application life cycle management for Power Pages.

Chapter 11, Managing the Environment Life Cycle with Design Best Practices, builds on design best practices. It talks about Power Platform Well-Architected and Power Platform Landing Zones, explaining how they can help organizations build application workloads that follow best practices that are deployed in governed and secured environments. The chapter then transitions toward environment life cycle management and talks about automated environment management with different approaches, including infrastructure-as-code and Terraform. Finally, we conclude this chapter by looking into the Power Platform Center of Excellence and how the CoE starter kit can help organizations manage Power Platform tenants.

Chapter 12, Looking Ahead with Copilots, ChatOps, and AI-Infused Applications, is the last chapter of this book and looks at how artificial intelligence can help organizations enrich their applications. It helps understand how various Copilots can be used to improve makers’ productivity and how AI Builder or Azure OpenAI can modernize existing business processes. We close this chapter and the book by talking about Copilot Studio and its ability to create custom copilots that can help organizations automatize DevOps processes using custom-built AI assistants.

To get the most out of this book

You will need to have a basic understanding of the Microsoft Power Platform product family and fundamental knowledge of software development practices and the basics of IT application administration, support, and monitoring. Besides this theoretical knowledge, you will need to install the following software components to be able to execute the provided script snippets locally:

Software covered in the book

OS requirements

Windows Subsystem for Linux

Windows

Bash

Linux

.NET Framework 4.7.2 or later

Windows

Windows PowerShell version 5.x

Windows

Dotnet 6

Windows or Linux

PAC CLI

Windows or Linux

Visual Studio Code

Windows or Linux

Please note that the scripts are created to run in cloud-hosted agents of Azure DevOps or GitHub and local execution is only intended for demonstration purposes.

To get the most out of the book, you will need to have Power Platform developer licenses, an Azure DevOps or GitHub organization (free plans available for public repositories are sufficient), and a Microsoft Azure tenant. A Microsoft Azure subscription is not required because we will use only Microsoft Entra ID features to connect the Power Platform world with our preferred DevOps tool. Of course, if your organization has enterprise tiers of these online services, the experience with the examples will be even more smooth and straightforward.

There are many examples in the book that have been created for both Azure DevOps Services and GitHub. The concepts stated in those chapters are the same beyond these DevOps tools and the scripts can be easily moved between these platforms. We highly recommend creating your workflows in the DevOps tool on your own flavor, so go either with Azure DevOps or GitHub for the samples in the book.

In Chapter 7, it is recommended to have the GitHub Advanced Security add-on for GitHub or Azure DevOps Services. Although the CodeQL commands can be locally executed, the advanced security features of Azure DevOps and GitHub are only available with public projects and, respectively, with public repositories as well.

If you are using the digital version of this book, we advise you to type the code yourself or access and fork the code via the GitHub repository (link available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

You can place the real-world example in Chapter 8 in a separate repository to introduce everything that you will learn over the course of the book in the same solution. With that, you will have an end-to-end, production-ready DevSecOps reference implementation for your organization.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Mastering-DevOps-on-Microsoft-Power-Platform. In case there’s an update to the code, it will be updated in the existing GitHub repository.

We also have other code bundles from our rich catalog of books available at https://github.com/PacktPublishing/. Check them out!

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “We will change the property from SingleLine.Text to a number (Whole.None) by changing the highlighted property.”

A block of code is set as follows:

pac admin help pac admin list help

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

codeql.exe database analyze .\codeql-database-js .\codeql-pack\ javascript\codeql\javascript-queries\0.8.12\codeql-suites\ javascript-code-scanning.qls --format=csv --output=results.csv

Any command-line input or output is written as follows:

pac solution create-settings --solution-zip .\EnvConnRef_1_1_managed.zip

Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: “This time we select New | More | Environment variable.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.

Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Mastering DevOps on Microsoft Power Platform, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/978-1-83588-084-5

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1:Understanding DevOps on Microsoft Power Platform

In this section, we will establish the foundational knowledge required for modern DevOps and software development methodologies, and examine the reasons behind the rise of low-code/no-code frameworks in the past decade. We will delve into Microsoft Power Platform, outlining its extensive feature set and correlating these features with established software development life cycle methodologies. Furthermore, we will study the theory of the CMMI model and its influence on the development of the Power Platform adoption maturity model, underscoring the importance of this model in our practices.

This part has the following chapters:

Chapter 1, Mastering DevOps and ALM for Efficient Software DevelopmentChapter 2, Getting Started with Microsoft Power PlatformChapter 3, Exploring ALM and DevOps in Microsoft Power Platform

1

Mastering DevOps and ALM for Efficient Software Development

Software development practices and methodologies have evolved a lot since the first program was written on punch cards. Nowadays, every business process in every industry vertical runs on software and we cannot even imagine our life without applications, as they are used in almost every interaction with our world. Digital transformation has been accelerated during the pandemic and the demand to create more applications has risen to a level that cannot be fulfilled exclusively by traditional software development tools and frameworks. Today, every organization is a software development company regardless of its industry thanks to the global digital transformation.

In this chapter, we will explore Application Life Cycle Management (ALM) in the context of software development. We begin with an overview of Software Development Life Cycle (SDLC), followed by a discussion of various software development methodologies. We will then delve into the concept of ALM, examining it from the perspective of the SDLC and the journey from requirement engineering through development and testing to production and maintenance. This knowledge is crucial as it equips us with the understanding needed to effectively manage and streamline the process of planning, creating, testing, and deploying an application of any kind. We will also explore the origin of the Lean concept, a philosophy that emphasizes creating value for customers and eliminating waste and that originated in the car manufacturing industry.

We will then introduce the Agile manifesto and the Scrum methodology, which are key frameworks in modern software development practices. We will further learn about DevOps-enabled architecture, including various design patterns and non-functional requirements such as testability and deployability. We will also cover Continuous Integration (CI) and Continuous Deployment (CD), two practices that automate the stages of app production. Finally, we will discuss the concepts of Release Trains and release cycles, which are strategies for managing the release of new features in a coordinated and predictable manner. This knowledge will help us streamline the development processes and improve product quality.

By the end of this chapter, we will have gained familiarity with state-of-the-art application development processes, and patterns, as well as cutting-edge DevOps (bringing dev and ops teams together to continuously deliver value to our customers) and ALM practices.

In this chapter, we’re going to cover the following main topics:

SDLC – what it is all aboutOverview of Software development methodologiesWhat is ALM?Lean principles, the Agile manifesto, and Scrum methodologyDevOps-enabled architecture patternsCI and CD

SDLC – what it is all about

SDLC, which is sometimes also referred to as the software development process, is the systematic methodology used to produce quality software cost-effectively. We can use several methodologies developed in the last few decades to develop or modify computer systems.

Originally, the concept was created in the 1960s. Its main goal was to establish a repeatable, auditable, and, at that time, sequential software development process that covered the steps from the ideation of the application to the delivery of the final solution by targeting corporate mainframes. Since then, many enhancements, innovations, and inventions have been implemented starting with the introduction of object-oriented programming languages through DevOps and DevSecOps practices to cloud-native architectures, which led to newer and newer SDLC methodologies. As a result of the continuous process improvement, most modern software development methodologies follow Agile principles nowadays.

Phases

Regardless of the selected software development methodology, the stages (phases) of the software development process are the same:

Figure 1.1 – The software development phases

Let us discover these phases:

Requirement analysis or requirement engineering is the step in which the development team collects customer requirements and objectives. The development team works closely with customer representatives to identify the key features of the solution. In this phase, requirements are also analyzed, meaning that needs are validated and documented unambiguously. This phase also covers identifying the non-functional requirements of the system, such as performance, resource needs, or availability expectations. It is a crucial step to ensure that the final product meets the customer’s needs and expectations.The planning and design phase is the one in which the development team creates the project plan with cadence and key deliverables. This process usually ends with a Work Breakdown Structure (WBS). The development team then assigns milestones to different parts of the WBS to be able to track the progress at a higher level. A milestone frequently signifies the completion of contractual obligations, leading to financial settlements. In this phase, the team also designs software architecture and User Experience (UX). Wireframes for the UI and prototypes for architecture are frequently used to get more input for effort estimations. Another practice to calculate the effort and complexity of the tasks in WBS is to play so-called planning poker. Team members use cards with numbers to assign values to tasks separately. At the end, poker team members reveal their cards and discuss the results until they reach a consensus.The development phase is essentially the coding part. The team implements the application, writes the unit tests, and debugs the code. Traditional methodologies view the development phase as solely for writing code. In contrast, Agile approaches eliminate this separation and incorporate testing and deployment earlier in the process. They do it so that they can repeat the coding-testing-deployment cycle many times in an iterative way. In addition, these modern approaches foster collaboration between development teams and client representatives by providing access to the working software at the end of every iteration.The test and quality assurance phase is about creating different levels of tests for the application. The development team writes and executes integration tests, system tests, end-to-end tests, performance tests, and other non-functional tests, such as resource usage or chaos tests, to validate the system against the defined requirements. In the past, there were dedicated test teams whose main duty was to provide these tests and to ensure that the software meets the customer’s requirements. When the validation passed, the software was ready to deliver to production.The deployment phase is the step in which the development team deploys the solution into the client’s environment. It involves not just installing the system but also configuring it and migrating data from previous solutions in some cases. Deployment can target on-premises or cloud infrastructure. Nowadays, this process is fully automated. The development team conducts user training if needed and hands over the documentation (user manuals) to the customer, too.The maintenance phase is about monitoring the solution in a production environment. Based on the results and customer feedback, the development team provides updates, upgrades, bug fixes, security patches, and even new features. This phase is sometimes referred to as a support period and customers pay additional fees to get those services from development teams.

Application runtime platform

Low-code/no-code platforms are application runtime platforms that enable professional developer teams to develop applications of any kind. Since this application development is fully identical to any other custom application development, the same SDLC methodologies can be applied to these low-code or no-code applications.

Depending on the software development project, an organization can apply different approaches to their work, from following fixed guidelines to adapting to changing situations. However, in all scenarios, the aforementioned phases are the same. In the next section, we will learn about the most-used methodologies.

Methodologies

As we have seen, the SDLC describes the main phases of the software development process, focusing on the question of why, but it does not define what or how we should implement those phases. The methodologies tell us what we should deliver and how we should work in those phases in detail.

By examining the following two distinct methodologies, we can better understand what each aims to define for software development projects:

The Scrum framework iterates through all the phases of SDLC from requirement analysis, planning, development, testing, and deployment to maintenance every 2-4 weeksThe waterfall methodology only goes through the SDLC phases once in a sequential way and it takes several months or sometimes even years

Some of the major methodologies include the following, in chronological order:

WaterfallV-modelXPIterative and incremental developmentAgile (Scrum)

In the next sections, we will learn more about these frameworks and methodologies, and how they could be applied to low-code/no-code platforms, such as Microsoft Power Platform.

Waterfall

This is the oldest software development process that defines the software development phases sequentially and rigorously.

It is very often criticized for its rigidity and sequential method. As we will see, all upcoming methodologies have tried to improve on this original approach in different ways, but it has also some advantages foremost in software development projects, such as writing kernel drivers or programming mission-critical applications, such as nuclear plant software. The following figure visualizes those development phases in the waterfall model that were discussed earlier in this chapter:

Figure 1.2 – The waterfall model

The phases, requirement analysis, planning and design, development, testing and quality assurance, deployment, and maintenance, are equivalent to the phases described earlier in this chapter. The difference is the sequential execution order of those phases.

The pros of this model are as follows:

It is a preferred methodology for mission- or business-critical projects.It is preferred when repetitive application development is required. This occurs when projects are highly similar, such as developing kiosk applications or writing embedded software. In these cases, the requirements and customer expectations are well understood, and no changes are anticipated.Project milestones and deadlines are clearly defined.

The cons are as follows:

Big upfront design costCustomer expectations cannot be considered after requirement analysisTime-to-market is huge; it is measured in years and can result in outdated deliveriesTesting does not take place until the end of the SDLC

In spite of the aforementioned cons, even in low-code/no-code platforms, we can use this methodology to create our applications using the foundation provided by the platform.

V-model

This model is an enhancement of the previous one to improve the time-to-market Key Performance Indicator (KPI) with high software quality by introducing parallel activities in the process.

The following figure shows the process in detail:

Figure 1.3 – A V-model

Everything starts with the decomposition of the requirements (the domain space) into modules or components that can be implemented separately. The V-model expects modular architecture, but not necessarily loosely coupled architectures in which those components are considered subsystems of the large system design. Low-code/no-code platforms, such as Microsoft Power Platform, provide built-in tools for testing and validation, which can help developers ensure that their applications meet the requirements and function as intended. In a low-code/no-code environment, the V-model can be realized by following a structured development process that includes requirements analysis, design, development, testing, and deployment. Each phase of the process can be completed using the tools and features provided by the low-code/no-code platform, allowing developers to build, test, and deploy their applications in a streamlined and efficient manner.

There is a corresponding V-model definition for US government institutions as part of the US Government Standard. It is more detailed and stricter than the original V-model definition to fulfill the US government’s requirements.

The pros are as follows:

Faster time-to-market with higher overall velocityBuilt-in quality assurance

The cons are as follows:

It is still a rigid processRequirement changes can hardly be managed

Extreme programming

Extreme Programming (XP) as a software development methodology emphasizes the need to accelerate the reaction time of the development team to customers’ changing requirements – which is expected in any software development project – by maintaining high software quality.

This methodology has become famous because of some paradigm shifts, such as introducing pair programming and strict code reviews, as well as thriving bare minimum architecture solutions, which are called Minimum Viable Products (MVPs). Pair programming techniques mean that two developers work together to write the same code. One developer writes the lines, while the other reviews every piece of new code on the fly. The two developers switch between these activities (who writes and who reviews) very often, but eventually, they will work on the same activity in the WBS. The MVP is the bare minimum product, which may have technical debts and architecture violations, that can already demonstrate the features requested by customers or identified by the field. MVPs are used to collect feedback from customers or contractual partners.

The goal of an MVP is to test the product’s core assumptions and to evaluate that it has a market fit, that is, that it is valuable to customers. In XP, it is common practice to keep those MVPs as they are and not to do more than expected. The main principles of XP are as follows:

Customer involvement: XP emphasizes close collaboration between the development team and the customerFrequent releases: XP advocates for releasing working software frequently, even if it’s not feature-completePair programming: XP encourages developers to work in pairs, with one person writing the code and the other reviewing itTest-driven development: XP emphasizes creating tests before implementing business logic to ensure that the code meets the requirementsCI: XP encourages integrating code changes frequently to catch integration issues early

While it is not specifically designed for low-code/no-code platforms, many of the principles of XP can be applied to development on these platforms.

XP and low-code/no-code platforms

Microsoft Power Platform supports some of these principles as the market leader in low-code/no-code platforms. Even pair programming (the co-authoring feature of PowerApps canvas applications with a YAML-based code editor), test-driven development for canvas apps, and CI are fully adapted into PowerApps.

The pros are as follows:

It promotes teamwork and collaboration, which can lead to more effective problem-solving and decision-makingIt emphasizes customer satisfaction, which ensures that the customer gets what they need, that is, that the product exactly meets their expectationsIt allows for flexibility and adaptability, as changes and new requirements can be incorporated into the development process as they ariseIt encourages frequent communication and feedback, which can help identify and address problems early in the development process

The cons are as follows:

Bare minimum architectural solutions increase overall technical debtIt can be challenging to implement in organizations with rigid hierarchies or cultures that do not value teamwork and collaborationIt can be difficult to accurately estimate the time and resources required for each iteration, which can make project planning and management more difficult

Iterative and incremental development

In software development, there are two equally important objectives: velocity and quality. We have already seen how quality is built into the processes in the previous methodologies. However, quality means deceleration because it requires time and effort from development teams that could otherwise be spent on creating new features and requirements. That’s why the software industry has introduced the term velocity. Velocity is defined by the number of features (story points) that a team can deliver in a period. This is one of the major KPIs of almost every SDLC methodology and was one of the main drivers that created the incremental and iterative approaches.

Iterative and incremental development is a software development methodology that emphasizes breaking down the development process into small, manageable chunks and delivering working software in each iteration. This approach allows for flexibility and adaptability, as changes and new requirements can be incorporated into the development process as they arise.

Low-code platforms, such as Microsoft Power Platform, can be used to support iterative and incremental development. These platforms provide building blocks that enable developers to quickly build and deploy applications without the need for extensive coding. This makes it possible to deliver working software quickly and iteratively, allowing for frequent feedback and adaptation. In an iterative and incremental development process using a low-code platform, developers can work on small, manageable chunks of functionality, building and deploying them as they go. This allows for frequent feedback from end users and enables developers to incorporate changes and new requirements into the development process as they arise. The visual development environment provided by low-code platforms makes it easy to make changes and add new functionality, allowing developers to quickly adapt to changing requirements.

The pros areas follows:

It allows for early feedback and validation from end users, which ensures that the product exactly meets their expectationsIt enables developers to incorporate changes and new requirements into the development process as they arise, allowing for greater flexibility and adaptabilityIt reduces the risk of project failure, as problems can be identified and addressed early in the development processIt allows for the delivery of working software quickly and iteratively, providing value to end users and stakeholders early in the development process

The cons are as follows:

It can be challenging to accurately estimate the time and resources required for each iteration, which can make project planning and management more difficultIt requires a high level of collaboration and communication between team membersIt can be difficult to maintain a consistent vision and direction for the project, as changes and new requirements are incorporated into the development process

Rapid application development

Rapid Application Development (RAD) was originally developed as an alternative approach to the waterfall model and, as its name states, it is about striving for speed and velocity in the software development life cycle. It was officially introduced by James Martin in 1991. The RAD approach emphasizes the swift development of applications through iterative releases and continuous client feedback. By applying agile methodologies and rapid prototyping, RAD ensures software usability, responsiveness to user feedback, and timely delivery. The process-driven nature of RAD, with its focus on testing prototypes and making quick adjustments, enables the delivery of the expected product in a shorter timeframe.

Low-code or no-code platforms, such as Microsoft Power Platform, are ideal tools for RAD, since on top of the existing building blocks – such as software components and packages in traditional software development – developers can easily add their customizations and focus on the value creation process.

The pros are as follows:

Shortened development time and higher team velocity: The RAD approach focuses on rapid prototyping and iterative releases, which can significantly reduce the development time.Flexibility and adaptability: The RAD approach allows for changes to be made during the development process, making it more flexible and adaptable to the changing needs of the project.Easier risk management: By breaking down the development process into smaller, manageable chunks, issues can be identified and addressed early in the development process, reducing the likelihood of major setbacks.Less custom code and shorter testing times: The RAD approach relies on the use of pre-built components and code generation tools, which can reduce the amount of manual coding required.Real-time user feedback: The RAD approach allows customers to provide feedback to developers at any time since the development iterations are very fast, and they always produce working software in the end.

The cons are as follows:

It may not be applicable to large, complex projects that require detailed planning and design. RAD relies on the reuse of software components, which can limit the flexibility and customization of the final product.RAD may result in a lower-quality product, as the focus on rapid development may lead to shortcuts being taken and compromises being made in the development process.RAD may not be suitable for projects with strict requirements for security, reliability, and performance, as the rapid development process may not allow for thorough testingand optimization.

These disadvantages are relevant to custom software development projects because the testing prototypes (MVPs) and technical debts are hard-coded into the process. Nowadays, RAD tools provide frameworks and reusable packages in public repositories to support professional developer teams to gain all the benefits of rapid development.

RAD prosperity

Due to the digital transformation demand of enterprises, the world is facing traditional long development timelines and software developer shortages, which means that approximately 4 million developers will be missing from the market by 2025 according to the IDC. Low-code/no-code platforms embrace this opportunity to provide RAD tools for professional developers.

Agile

Agile principles emphasize flexibility, collaboration, and customer satisfaction. “The only constant is the change”, “test and fail fast”, “individuals and collaboration over processes”, and “a customer-first mindset” are the most widely heard phrases on the topic of the agile development process.

RAD versus Agile

Although the RAD and agile methodologies share some similarities, there are key differences in their approach. RAD prioritizes the development of prototypes to gather user feedback, while agile divides the project into smaller features that are delivered incrementally through a series of sprints throughout the development cycle.

In the software development life cycle, agile is an iterative approach that focuses on delivering working software frequently with a high level of adaptability to changing requirements. Agile development teams work closely with customers and stakeholders to prioritize features and requirements. They use techniques such as CI, automated testing, and frequent releases to ensure that the software is always in a working state.

In an agile development process using a low-code platform, developers can work closely with end users to gather feedback and incorporate changes into the development process as they arise. The visual development environment provided by low-code platforms makes it easy to make changes and add new functionality, allowing developers to quickly adapt to changing requirements.

The pros are as follows:

Agile development allows for early feedback and validation from end users, which can help ensure that the final product meets expectations exactlyIt enables developers to incorporate changes and new requirements into the development process as they arise, allowing for greater flexibility and adaptabilityIt reduces the risk of project failure since issues and risks can be recognized and targeted early in the development processIt allows for the delivery of working software quickly and iteratively, providing value to end users and stakeholders early in the development process

The cons are as follows:

It can be challenging to accurately estimate the time and resources required for each iteration, which can make project planning and management more difficultIt requires a high level of collaboration and communication between team members, which can be challenging to achieve in some organizational culturesIt can be difficult to maintain a consistent vision and direction for the project, as changes and new requirements are incorporated into the development process

One way to comprehend the concept of agile is by comparing it to another SDLC methodology, such as the V-model method. In the V-model approach, the scope of the product is predetermined, while time and resources are adjustable. Organizations using the V-method will increase the number of programmers and extend schedules to deliver the product they have planned to release. On the other hand, in the agile approach, the product’s scope is adaptable, while resources and time are fixed. Agile teams pledge to deliver software on time with their current team. The product that they deliver is a flexible combination of what they have discovered the customer wants and what they can create within the given time frame.

Agile, Scrum, and Lean

There have been other concepts, ideas, and perceptions that have significantly influenced the software industry in the last decades. Some of the approaches have been adapted from other industries, such as the Lean management from the Toyota Production System, and others have been created by key members of the software industry. We will discuss these approaches shortly to understand how DevOps and DevSecOps have become the next major step in the software industry.

The Agile manifesto

We have already discussed Agile as an SDLC methodology because this umbrella term can be applied directly to the software development phase as well as mapped to the entire software development organization and beyond.

The Agile manifesto was created in 2001 by a group of software developers who were looking for a better way to develop software. They came up with four core values and twelve principles that have since become the foundation of the Agile movement. The four core values of the Agile Manifesto are as follows:

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

These values and principles have been widely adopted by software development teams and have helped to improve the effectiveness and efficiency of software development processes.

Agile, as an umbrella term, is a broad concept that encompasses a variety of methodologies including Lean, Scrum, Kanban, and others.

Lean management

Lean management, developed by Taiichi Ohno, the creator of the Toyota Production System, is a methodology that focuses on creating value for customers by optimizing resources, reducing waste (muda in Japanese), and continuously improving processes. Ohno’s goal was to reduce the time between car order and car delivery:

“All we are doing is looking at the timeline from the moment a customer gives us an order to the point when we collect the cash. We are reducing that timeline by removing the nonvalue-added wastes” – Taiichi Ohno

The principles of lean management include the following:

Value: Identify what the customer values and concentrate on delivering it to themValue stream: Identify all the steps in the value stream for the product or service and remove any steps that do not create valueFlow: Ensure that the value-creating steps flow smoothly and continuously toward the customerPull: Let customer demand pull the product or service through the value stream rather than pushing it based on forecastsPerfection: Continuously pursue improvements to identify and eliminate waste from the processes (strive for perfection)

Any type of organization can apply these principles and processes to improve efficiency, minimize costs, and improve customer satisfaction. Other industry sectors, such as accounting, have also applied lean principles. It’s no surprise that the software industry has adopted this concept, viewing itself as a software manufacturing factory and applying the analogy accordingly.

Value stream and value stream analysis are the most relevant areas that provide a tool for any organization to understand, visualize, and improve their value creation processes.

The following figure represents a hypothetical software development organization and how it reacts to customer requests. Lead Time (LT) is the time spent between entering the stage and closing the stage, whereas Process Time (PT) is the time spent on real work or activity:

Figure 1.4 – Value stream analysis in practice

Customer requests go through different teams (accounts, business analysis, engineering, and ops) with different LTs and PTs until they reach production. This hypothetical organization can improve its efficiency by reducing the LTs spent on each phase and by accelerating the PTs.

It is obvious that low-code/no-code platforms, such as Microsoft Power Platform, can significantly decrease not just the PT but also the overall LT of any application development project. They can do this by using the pre-baked building blocks, such as front-end visuals, business logic components, and data access layers, to reduce the overall development, testing, and deployment costs of custom applications.

Scrum

Scrum is a framework derived from the general agile principles that are often used in software development. This is one of the most widespread Agile methodologies. As we discussed earlier, Agile is an umbrella term that we can apply to SDLC methodology, project management, and organization in many ways. Scrum is a specific implementation of Agile with its own roles, events, artifacts, and rules.

Scrum is an agile framework that operates on the values of transparency, assessment, and adjustment. It uses an iterative and incremental methodology to enhance predictability and manage risks. Scrum teams deliver functional software in brief, time-bound iterations known as sprints, while constantly evaluating and adjusting their processes to improve both the product and their workflow. The following figure shows the process of incremental planning and delivery:

Figure 1.5 – The scrum process

Autonomous scrum teams decide which backlog items they will work on in the given sprint based on customer priorities and team velocity. Those backlog items will be moved from the product backlog to the spring backlog. A sprint usually takes 2-4 weeks and at the end of every sprint, scrum teams can deliver a potentially shippable product.

The Scrum framework defines three main roles: the product owner, the Scrum master, and the development team. The product owner is responsible for maximizing the value of the product and representing the stakeholders (the customer). The Scrum master is responsible for promoting and supporting Scrum, orchestrating the well-known ceremonies, and encouraging everyone to abide by Scrum rules and values. The development team is a self-organizing and cross-functional team responsible for delivering a potentially shippable product at the end of each sprint.

Scrum has several ceremonies or events that are used to plan, review, and improve the process. These include sprint planning, daily Scrum, sprint review, and sprint retrospective. Sprint planning is used to plan the work for the upcoming sprint. The daily Scrum is a short daily meeting used to synchronize the work of the development team. The sprint review is scheduled at the end of the current sprint to review the backlog items completed and shift the uncompleted ones to the next sprint. The sprint retrospective is organized after the sprint review to discuss questions such as “what went well?”, “what could have been done better?”, and “how could we improve as a team?”. As a result, the team can find potential improvements and plan them for the next sprint.

Scrum framework is easily applicable to low-code/no-code platforms since these provide an ecosystem that guarantees shippable products (applications) at the end of every sprint with the roles and ceremonies defined by the framework.

What is ALM?

There are many books and articles about ALM and, having a look at the definitions, one thing is common in all of them: ALM is broader than the SDLC and covers the entire life cycle of an application from ideation through development to discontinuity.

Per definition, ALM refers to the management of a computer program’s entire life cycle, including governance, development, maintenance, and discontinuity. It involves a wide range of activities, such as requirements management, software architecture, and project management.

The SDLC is a component of ALM that provides a detailed description of the application development phase. ALM can involve multiple iterations of the SDLC during an application’s life cycle, that is, multiple methodologies such as Agile and V-model can be applied in different phases. ALM continues after development and first release until the application is no longer used.

ALM has brought several disciplines and roles together. It includes project management, change management, requirements management, software architecture, CI, development, CD, testing, release management, and maintenance. These disciplines were managed separately in the past and organizations – before establishing ALM – were much more siloed. Internal processes were prioritized over collaboration and communication among different roles and units within the organization.

These days, ALM tools offer a standardized platform for communication and collaboration among software development teams and associated departments, such as project management, business analysis, testing, and IT ops. These tools can also streamline the process of software development and delivery through automation.

Modern integrated ALM tools, such as Azure DevOps Services, GitHub, or GitLab, support the following:

Requirement engineeringProject management – including planning and trackingBug- and issue trackingVersion control systemBuild – CIAutomated testingRelease – CDMonitoring applications in production and learning from usage patterns, telemetry logs, and failures

The following figure shows the main areas of ALM and how these different disciplines work together in a cyclic way:

Figure 1.6 – The main areas of ALM

ALM can easily be applied to low-code/no-code platforms since they are designed to be modern application runtime platforms hosting and executing hundreds or even thousands of applications created by professional developers.

In the next chapters, we will learn how ALM disciplines can be realized in conjunction with Microsoft Power Platform.

CI and CD

CI and CD are widely used processes and tools in modern software development and ALM practices. The CI pipeline (workflow) is for compiling the source code and generating the binaries using build agents, whereas the CD pipeline takes those binaries and deploys them, the entire solution with its configuration to different environments, like dev, test, or production.

CI is sometimes referred to as CI builds because it eventually does the official compilation of source code on dedicated build machines (sometimes they are just Docker containers). During CI builds, unit tests are also executed; those tests require no orchestration of the application and run in the millisecond range. CI is one of the greatest processes to assure software quality and to avoid the regression of our applications. In the case of large development projects, it is also very common to create build farms consisting of hundreds of build machines to generate deliverables or packages on every code change.

There are two CD terms in practice. Continuous delivery means that the application is ready to be delivered all the time, but the deployment is not automated. Typical examples for continuous delivery are to create a Docker image after compiling the code, or to create an installer to the generated binaries. Continuous deployment takes