Azure DevOps provides a powerful toolset to enable Continuous Integration and Continuous Deployment (CI/CD) capabilities.
The Apigee Edge API Management platform provides API management capabilities to backend services such as security, rate limiting, quotas and analytics. There are also different deployment options available for the proxy code. This article focuses on the use of the Apigee Maven deploy and config plugins to aid the CI/CD process by incorporating them in the build and release pipelines, using Azure Repos and Azure Pipelines.
Apigee Edge (an API proxy) provides API management capabilities to an organisation's backend services that are exposed via APIs. In turn, this provides security and exposing the APIs to developers through secure mechanisms.
The main components of the Apigee Edge platform are shown below.
Figure 1. Overview of the Apigee Edge Platform components
Apigee Edge consists of the API Runtime, Developer Services and Analytics, which provide functionality for the API lifecycle. An API proxy needs to be deployed to an Apigee environment before it can be invoked. An environment represents a runtime execution context for an API proxy, mapped to a stage in the software development life cycle (SDLC). The number of environments can be configured to reflect the organisation's SDLC.
Three types of artefacts need to be version controlled in Apigee Edge. These are API proxies, Edge configuration, and API documentation. The following sections discuss the repository strategies for these different artefacts and how they can be used during the CI/CD process.
Where API proxy development is concerned, two repository strategies can be used:
The second approach is recommended as it allows an API and version to be an independent, single, develop/deploy/test unit with its own branching structure.
Apart from the proxy code, there is Edge configuration code common across the Apigee platform. This information can be maintained in a common repository that is shared between API proxies.
As the diagram below indicates, Azure pipelines can be used to manage code branching and deployment methods compatible with many Git branching strategies.
Figure 2. Branching and merging strategy
In Apigee Edge, an API proxy is essentially a set of XML files arranged within the following file structure.
Figure 3. API proxy code folder configuration
The folders that contain the proxy related information are grouped within the apiproxy folder, which deploys the proxy code to Apigee Edge environments.
Code shared across API proxies should be maintained in a centralised manner using a shared repository. These components include:
Figure 4. Common configuration code
As this is a shared repository, it can be added as a Git submodule in each API proxy repository. The Apigee Maven Config plugin dictates the folder structure and behaviour of the deployment process.
Apigee Edge does not maintain backups of the environment configuration. Therefore it is essential that configuration is kept in source control and applied automatically through the CI process to avoid losing configuration information.
The build steps and the options available for building and deploying shared flows are the same as an API proxy.
The shared flows are managed as a multi-module project and are built from an aggregator POM (proxy-common/sharedflows/multi-module-pom.xml) that manages the group of submodules. The submodules can be built separately or through the aggregator POM. The POM compiles shared flow bundles in the common repository that need to be built during deployment.
A POST API call is used to deploy the zipped proxy code to an Edge environment.
The full deployment process also involves the deployment of the Edge configuration if any updates occurred as part of development.
Figure 7. Full deployment of all Edge components
The Apigee Maven Deploy plugin provides additional configuration to change elements based on where it is deployed.
Each repository will require a plugin-compatible directory structure:
The Apigee Maven Config plugin can be used to:
This allows configuration to be coupled with the API in version control. This plugin is referred to and used in the parent POM.
The following sections describe how the Azure build and release pipelines utilise the Apigee Maven plugins for the build and deployment processes.
Figure 8. Build and deploy using Azure DevOps tools
For each API proxy, a build pipeline needs to be created based on the corresponding Git repository's master branch (ensure that Checkout submodules is selected under Get Sources). The pipeline will perform the following:
Figure 9. Proxy build pipeline configuration
The published artefact is deployed through progressive environments towards Production. The following image shows the release pipeline created for a proxy deployed to an Apigee trial account (which comes with two default environments, test and prod; a manual trigger is used to deploy to the prod environment). It is also possible to automate the process with Integration testing and approval gates using pre-deployment conditions that can be configured for each stage.
Figure 10. Proxy release pipeline configuration
The following pipeline variables are required:
Figure 11. Release pipeline variables
Figure 12. Maven deployment task configuration
The build pipeline is configured to be triggered whenever a change is made to the master branch, with the Path filter set to /sharedflows. The variables are set as per proxy build pipelines.
Figure 13. Shared flow build pipeline configuration
Use the published build artefact of the shared flow to deploy the shared flow to an Apigee environment, starting with dev and then promoting to other environments progressively until deployed to Production.
The intent of this article was to describe the process involved in deploying Apigee proxies to the Apigee Edge platform utilising Azure DevOps capabilities. While this is not an exhaustive description of the process, it should give a good idea of how to get started with CI/CD using Azure DevOps for Apigee deployments.
The build pipelines can be further improved to include:
The release pipelines can also be further improved to include: