Gateway Developer Plugin
2
gateway94
2
Overview
The Gateway Developer Plugin is an Open Source tool developed by CA is designed to help policy development teams manage the full cycle of policy development. It is offered as an alternative to the existing Gateway Migration Utility (GMU) tool and is designed to optimize a Continuous Integration and Continuous Development (CI/CD) workflow. Where the GMU tool relies on a script-based mapping workflow with documented limitations of what can and can't be migrated with the tool alone, the Plugin is designed to simplify this process in several ways:
- All Gateway configuration shall be stored in a Version Control System (VCS), allowing multiple policy developers to collaborate and revise, push and pull policy artifacts (including configurations) like code.
- Enables policy developers to create build packages with all the required configurations to run a solution in the Gateway.
- Ensures that configurations can be applied across different environments (e.g., development, testing or production) so that the Gateway solution can behave consistently regardless of environment.
As described, the Plugin is not just an alternative to the GMU, but is an important component to running the Container Gateway in ephemeral mode.
CI/CD Workflow with the Gateway Developer Plugin
The following diagram illustrates how the Gateway Developer Plugin can contribute to a CI/CD workflow for policy or services development with the Gateway. Sample Gradle plugin tasks (i.e.,
import-bundle
, export
, build
, build-full-bundle
, etc.) are highlighted in bold to show how and where they fit in the overall workflow. 
Both
import-bundle
and build-full-bundle
are examples of tasks that can be controlled and monitored by a CI/CD pipeline automation system such as Jenkins. For example, Jenkins can monitor the Nexus repository for changes and then pull the updated bundle when available and call the Restman endpoint to install the updated bundle into a Gateway. Also, Jenkins can also monitor changes at the VCS level (e.g., merging of changes to branches in GitHub) and then run the build-full-bundle
task along with the import-bundle
task to deploy those changes to an existing GW cluster or new Gateway instance. Contents of the Plugin
In addition to the Gateway Developer Plugin, there are three other plugins that are part of the project build and deploy process. When applied, each plugin executes a unique set of coordinated tasks, such as building bundles, generating files, or removing unnecessary fields from a file. The following table summarizes those tasks for each of the plugins.
Plugin | Description | Plugin Tasks | Learn More |
gateway-developer-plugin | Reads configuration files, converts them to the Gateway Restman bundle format and builds the GW7 package. | build-bundle package-gw7 build-environment-bundle build-full-bundle | |
gateway-export-plugin | Exports current configurations from an existing Gateway, converts them into the plugin format, and stores it in the local directory structure, allowing for pushing to a VCS system. | export-raw sanitize-export export clean-export | |
gateway-import-plugin | Imports and installs generated solutions to an existing running Gateway. Used primarily for transitioning Gateways from an appliance to a container form factor. |
| |
environment-creator application | Part of the the GW7 package and used for deployment, this tool collects all environment properties that are relevant to the container and applies their values to the bundles. It is run before Container Gateway startup. | N/A |
Getting Started
Your Gateway project should be structured like a typical Gradle project (see GitHub repository example here), which requires two configuration files -
build.gradle
and settings.gradle
. The plugins are Gradle-based and can be found in the Gradle site here. As such, the structure of your Gateway project should resemble that of a Gradle project.
Per Gradle build logic, there are two steps needed to make full use of the plugins. First, Gradle will
resolve
the plugin, meaning that it will find the correct version of the plugin. In the build.gradle file, that means it will look at the plugins listed in the dependencies block. Each plugin should be given a script classpath. Once a plugin is resolved from the specified path, its API is used in a build script. Secondly, Gradle will then apply
the plugin to the target Gateway project About
build.gradle
The
build.gradle
file should define the following project-related configurations, via Groovy script:- Repositories
- Dependencies
- Plugins
- Properties/values/custom objects
- Publishing configurations
- Gradle wrapper version
The following is an example of a
build.gradle
file for a Gateway project with comments. // the buildscript block defines how the Gateway project is built and where are the plugins located buildscript { // the repositories block is where you declare project repositories repositories { mavenLocal() // search first on local maven maven { url "https://plugins.gradle.org/m2/" // second in gradle public plugins repository } } // adds the plugins as dependencies dependencies { // "+" will always pull the latest available plugin classpath "com.ca.apim.gateway:gateway-developer-plugin:0.6.+" classpath "com.ca.apim.gateway:gateway-export-plugin:0.6.+" classpath "com.ca.apim.gateway:gateway-import-plugin:0.6.+" }} // configuration for subprojects, if applicablesubprojects { // apply plugin is required to set gradle to use the plugin during build apply plugin: 'com.ca.apim.gateway.gateway-developer-plugin' if (!project.name.equals('deployment')) { apply plugin: 'com.ca.apim.gateway.gateway-export-plugin' GatewayConnection { url = 'https://localhost:8443/restman' } } else { apply plugin: 'com.ca.apim.gateway.gateway-import-plugin' } group 'com.ca.apim.gateway' version = '0.6.0' // this repositories config refers specifically to the dependencies in the project repositories { mavenLocal() flatDir { dirs new File(project.parent.rootDir, "lib") } jcenter() }} wrapper { gradleVersion = '4.10.2'}
About
settings.gradle
Similar to the
build.gradle
file, the settings.gradle
file is written in Groovy script. It is executed before the build.gradle
file and is evaluated against the Settings
object. With this object, you can manage submodules, configure versioning and project names – use this file if your settings are build-related and not necessarily project-related. View the Plugin in GitHub