The Azure container registry is Microsoft’s own hosting platform for Docker images. It is a private registry where you can store and manage private docker container images and other related artifacts. These images can then be pulled and run locally or used for container-based deployments to hosting platforms. In this tutorial, you will learn how to create a custom docker image and continuously deploy it to an Azure container registry.

DevOps, DevSecOps and CI/CD are synonymous with one word - automation. Automating their workflows gives developers the ability to deliver consistency, time savings, and useful insights into their software development life cycle (SDLC). But automation is only as efficient as your weakest link or most cumbersome bottleneck, which can sometimes be security testing. Security testing has traditionally been carried out either manually or quite late in the process.

For the past two and a half years as a Solutions Engineer at CircleCI, I’ve had the distinct pleasure of working with some of CircleCI’s largest customers to help them instill healthy CI/CD practices into their development processes. Leading-edge organizations are trying to make sure that their applications are scalable, reliable, and secure. Shipping products to users quickly and reliably is imperative to gaining a competitive edge.

Software delivery on a team of 2 people is vastly different from software delivery on a team of 200. Over the growth of a startup, processes and tool choices will evolve naturally - but either optimizing too early or letting them evolve without a picture of where you’re headed can cost you in time and agility later. That’s why I want to talk to you about how to evolve your delivery process with purpose.

When we talk about metrics in software delivery, a lot of developers think of execution metrics — things like throughput, delivery and number of deploys. But in reality, those metrics don’t motivate anyone — at least not without connecting them to a bigger picture. I’ve worked in software for 23 years. I’m a three-time founder and four-time CTO, responsible for leading a 200+ member distributed engineering organization.

Testing is vital because it helps you discover bugs before you release software, enabling you to deliver a high-quality product to your customers. Sometimes, though, tests are flaky and unreliable. Tests may be unreliable because of newly-written code or external factors. These flaky tests, also known as flappers, fail to produce accurate and consistent results. If your tests are flaky, they cannot help you find (and fix) all your bugs, which negatively impacts user experience.

With CircleCI, there are many different CI/CD flows that can be automated. One such flow is the use of Infrastructure-as-Code (IaC) to build cloud environments. For example, you can use CircleCI to automate the process of building Terraform plans and applying them, in order to create massive production setups in AWS, Azure, GCP, and other cloud environments.

In a single, monolithic repository, also known as a monorepo, you keep all your application and microservice code in the same source code repository (usually Git). Typically, teams split the code of various app components into subfolders and use Git workflow for new features or bug fixes. This approach is natural for most applications or systems developed using a monolithic architecture. Code in such a monorepo typically has a single build pipeline that produces the application executable.

This article will take you through setting up CI/CD integration for building, testing, and publishing libraries to Maven Central using Gradle. With jCenter shutting down, Maven Central is once again the primary destination for all Android and Java libraries. Library publishers will need to port their libraries over to Maven Central to keep their libraries available after jCenter shuts down. This article focuses on CI/CD integration.

Serverless computing, a model in which the provider manages the server, lets developers focus on writing dedicated pieces of application logic. Serverless computing has been adopted by many development teams because it auto-scales. Auto-scaling relieves developers of allocation management tasks, so they do not need to worry about the allocation of server resources or being charged for resources they are not consuming.