Building a CICD pipeline to move APIs across environments in WSO2 API Manager 4
How to build a CICD pipeline to move APIs across Dev, UAT, and Prod
WSO2 API Manager is a complete platform to build, manage and run enterprise-grade APIs within an organization. It supports full API lifecycle management capabilities including API gateway, Developer portal, API security, Rate limiting, Analytics, and many other features. More information on the WSO2 API Manager can be found here.
One of the common requirements in managing WSO2 API Manager in an enterprise ecosystem is to manage multiple deployment environments such as development, testing, UAT, and production for various testing purposes. When we have several environments to manage, moving various artifacts such as APIs, Applications, and API Products (called artifacts) across different environments is an important aspect of the overall software delivery process.
WSO2 API Manager provides a tool called API Controller (apictl) to migrate these different artifacts across environments. This tool exports all the required components for a given artifact (API, Application, or Product) into a single deployable component (zip) and we can use that to import into other environments. The figure below depicts the process of migrating WSO2 API Manager artifacts across environments.
The process of API development starts with either a developer logging into the API publisher portal or by crafting a Swagger/OAS file that describes the API and the related policies such as mediations, security, and rate limiting. Using the API publisher allows the users to perform many operations in a visual manner rather than editing a Swagger/OAS file. Hence using the Publisher is recommended unless there is no specific reason not to use it.
The next step is to export the selected API into a deployable archive using the apictl tool. If you started with the Swagger/OAS file-based approach, it will automatically create this deployable archive. If you started with the publisher, you need to first add the environment to the apictl and then export the relevant API with apictl. This process will generate the “source project” which contains all the components related to an API. Then this needs to be committed to a GitHub repository. If there are environment specific values to be passed to the API during the import process, that can be done using a separate parameters file and that needs to be committed to a different repository within GitHub. Additionally, test scripts can also be committed to a different repository within GitHub.
Once the artifacts are committed to GitHub, the next step is to configure the Jenkins (or any other CI tools) server to checkout the repositories and then execute the apictl tool to import the APIs to the relevant environments. During this process, you can pass the environment-specific, dynamic value through either the deployment file (parameters file) or environment variables set in the deployment server. Additionally, automated tests can also be executed once the API is imported to a given environment. If the testing is passed only, the migration to the next environment will happen.
In the API Manager product, there are several components related to an API that needs to be migrated across environments. Those components are
- APIs
- API Products
- Applications
We can use the API controller tool to manage these components across environments as mentioned in the below links.
Migrating APIs across environments using the API controller
Migrating API Products across environments using the API controller
Migrating Applications across environments using the API controller
There are configuration parameters that may vary across environments. In such a case, you can use the below-mentioned documentation link to migrate configurations across environments.
Configuring environment specific parameters
In addition to these, you can manage the deployed artifacts using the API controller tool as mentioned below.
Managing APIs and API Products using APICTL
As a best practice to deploy artifacts in a continuous manner, you can design and implement a CICD pipeline to manage APIs as mentioned in the below documentation link.
