Azure Pipelines is the Continuous Integration and Continuous Delivery (CI/CD) solution for any language, application, or platform. Independent Software Vendors can use it for both enhanced CI/CD functionality, and as a dedicated CI/CD service to use in their DevOps toolchains.
A continuous integration (CI) and continuous deployment (CD) pipeline has become an important aspect of API development. It allows organisations like ISVs, to automate deployment of changes without manual steps, detect issues earlier, and ultimately deliver value to end users faster.
Azure DevOps provides the CI/CD pipeline, starting with a Git repository for managing your application source code and infrastructure code (Azure Resource Manager templates), a Built system for producing packages and other built artefacts, and a Release Management system for setting up a pipeline to deploy your changes through dev, test and production environments.
Application Programming Interfaces have become the default case for connecting apps, data, and services. APIs are driving digital transformation for many ISVs.
A REST API is an application programming interface that conforms to specific architectural constraints. Representational State Transfer (REST) APIs are service endpoints that support sets of HTTP operations (methods), which provide create, retrieve, update, or delete access to the service’s resources.
ISVs often have multiple deployment environments (e.g., Development, Testing, Production) and use separate API Management instances for each environment. Some of these instances are shared across different teams, who are responsible for different APIs.
As a result, they often face a number of challenges:
The proposed approach is illustrated in the above picture. In this example, there are two deployment environments: Development and Production. Each has its own API Management instance. The Production instance is managed by a designated team, called API publishers. API developers only have access to the Development instance.
The key in this proposed approach is to keep all configurations in Azure Resource Manager templates. These templates should be kept in a source control system. We will use Git as an example. As illustrated in the picture, there is a Publisher repository that contains all configurations of the Production API Management instance in a collection of templates:
API developers will fork and clone the Publisher repository. In most cases, they will focus on API templates for their APIs and should not change the shared or service templates.
Once developers have finished developing and testing an API, and have generated the API template, they will submit a pull request to the Publisher repository. API publishers can validate the pull request and make sure the changes are compliant. Most of the validations can be automated as part of the CI/CD pipeline. When the changes are approved and merged successfully, API publishers will deploy them to the Production instance. The deployment can also be easily automated with Azure Pipelines.
With this approach, the deployment of API changes into API Management instances can be automated. It also reduces the chances of interference between different teams if different API development teams work on different templates.
Ask Amy a Question!
Amy is the Go to Market Manager for our ISV Solution and has worked with our community of ISVs across a number of projects. She is well placed to answer any query you might have
