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.
Introduction to Apigee Edge
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.
Source Control Management with Azure Repos
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:
- Single repository – contains proxies and configuration in one Git repository.
- Multiple repositories – one repository per proxy:version relationship.
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.
Branching and Merging Strategy
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
API Proxy Code
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.
Common Configuration Code
Code shared across API proxies should be maintained in a centralised manner using a shared repository. These components include:
- Apigee Edge configuration(proxy-common/resources/) – these include API products, Key Value Maps (KVMs), caches, target servers, etc.
- Shared flows(proxy-common/sharedflows/) - reusable components that can be consumed by multiple API proxies.
- Parent pom (proxy-common/shared-pom.xml) - used by the Maven plugins for API proxy deployment.
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 Configuration Code
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.
Shared Flows Code
The build steps and the options available for building and deploying shared flows are the same as an API proxy.
Figure 5. Shared flow folder configuration
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.
Figure 6. Proxy code deployment
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
Apigee Maven Deploy plugin
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:
- apiproxy: Directory containing the Apigee API bundle.
- pom.xml(child POM): Points to the common, shared parent POM; also contains proxy-specific details.
- config.json: Holds rules to perform build-time configuration updates.
Apigee Maven Config plugin
The Apigee Maven Config plugin can be used to:
- Create and manage Edge configuration
- Deploy an API & artefacts
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
Proxy Build Pipeline
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:
- Analyse static code using apigeelint.
- Publish results into a JUnit test report.
- Package proxy code using the Maven 'package' phase.
- Publish an API bundle as an artefact to Azure Pipelines.
Figure 9. Proxy build pipeline configuration
Proxy Release Pipeline
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:
- org- Apigee Edge organisation to which the proxy is being deployed
- env- Name of release pipeline stage
- username/password- Apigee Edge account credentials
- options– Deployment options (see the deploy plugin documentation for more details)
- config.options– Configuration options (see the config plugin documentation for more details)
- config.dir– Location of Edge configuration files in common repository
Figure 11. Release pipeline variables
- The API bundle can be deployed using the Maven plugin’s install phase as seen below
Figure 12. Maven deployment task configuration
Shared Flow Build Pipeline
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
Shared Flow Release Pipeline
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:
- Edge code updates with proxy deployment if available
- Integration tests (Apickli)
- Deployment backout upon test failure
- Performance tests
- Build/release results notifications