Book Image

Implementing Azure DevOps Solutions

By : Henry Been, Maik van der Gaag
Book Image

Implementing Azure DevOps Solutions

By: Henry Been, Maik van der Gaag

Overview of this book

Implementing Azure DevOps Solutions helps DevOps engineers and administrators to leverage Azure DevOps Services to master practices such as continuous integration and continuous delivery (CI/CD), containerization, and zero downtime deployments. This book starts with the basics of continuous integration, continuous delivery, and automated deployments. You will then learn how to apply configuration management and Infrastructure as Code (IaC) along with managing databases in DevOps scenarios. Next, you will delve into fitting security and compliance with DevOps. As you advance, you will explore how to instrument applications, and gather metrics to understand application usage and user behavior. The latter part of this book will help you implement a container build strategy and manage Azure Kubernetes Services. Lastly, you will understand how to create your own Azure DevOps organization, along with covering quick tips and tricks to confidently apply effective DevOps practices. By the end of this book, you’ll have gained the knowledge you need to ensure seamless application deployments and business continuity.
Table of Contents (21 chapters)
1
Section 1: Getting to Continuous Delivery
6
Section 2: Expanding your DevOps Pipeline
12
Section 3: Closing the Loop
15
Section 4: Advanced Topics

Working with dependencies

Next to the security risks that the application code developed in-house pose, there is also a risk associated with components that are reused. Between 50% and 80% of modern application code is not developed in-house, but is taken from other parties in the form of packages or dependencies. Some of these might be open source, but this is not necessarily the case. There can also be components that are bought from other development companies or binaries taken from galleries such as NuGet.

Dependencies not only pose security risks, but also licensing risks. What happens if a team starts using a component that is published under the GPL license for a closed source component? If anyone ever finds out, they can be forced to open source their product, or at least suffer public shame for not using the work of others according to the license.

To mitigate these risks...