Overview

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.

Pre-requisites

• Apigee Edge account
• Azure DevOps account

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.

Repository Strategy

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. 

API 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.

Azure Pipelines

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

Pipeline Configuration

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. 

Summary

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: 

• Unit tests on any custom code (mocha)
• Code coverage checks (Istanbul)

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