SCM and CICD using Azure DevOps using apigee maven deploy/config plugins

sarfernando
Participant II

Hi,

I am building the CICD process for a client using Azure DevOps. Having studied the community content (extremely useful) I am following the API centric branching and merging model using multiple repos (i.e. each api version has its own repo).

The branching strategy most likely will be:

  • master branch -holds the production code
  • develop branch holds the current stable new development code
  • release branches (test, sit, preprod)
  • feature branches will be used for developing specific features that will be merged into the develop branch.

While the Apigee platform is new to the client they plan to use it heavily within their development teams so I would like to ensure the SCM is thought through from the start. With regards to the CICD process, I am using the apigee maven plugins for the build and release pipelines (attached screenshots). The release pipeline pulls the config information from a common repository with the multi config file structure. Since at the beginning most proxy development and config will be done from the UI (not via code) I would like to determine at which point the automation should happen. I'm assuming that whenever code from a feature branch (developer will manually change base path and related config for testing in dev with a renamed proxy) is merged into develop branch, the CI process will kick off and deploy the original proxy to the dev environment with the original base path.

I would really appreciate if you could confirm that the above thought process with regards to the repo/branching model would work, and how the config will be updated when developers make changes to - for e.g. product configuration via the management UI? If a change is mage via the UI then how would a developer update SCM and where the CICD processes kick in for this kind of change?

Thanks

-------------------------------------------------------------------------------------------

Solved Solved
0 10 1,571
1 ACCEPTED SOLUTION

@sarah fernando

We have a similar CI/CD setup and repos setup for the api proxies and the configuration information as outlined by you.

Since there is no SCM plugin integration with Edge UI, the repos and the Edge configuration has to be manually synced.

At the beginning, developers may use Edge UI to develop the API proxies and also configure the environment dependent components. Devs will need to download the proxy code and add that to the repos. Later on, you should lock down edits and deployments through Edge UI to enforce everything is done through CI/CD. Its a preference on convenience whether you want to lockdown for all environments or only for QA and above.

The config information - caches, KVMs, target servers etc need to be added to the common repo.

In my experience, products and devapps creation and updates when done through the repo+maven config plugin, will cause two issues

1. Config reruns may be required - to avoid config deployment error if you try to create/update the product when the api proxy isn't yet deployed

2. Devapp updates will create a new set of keys, which may be undesirable

So I would suggest, any one-time configuration effort should be done manually and not through the config repo. If you have a Apigee config management team, they could build utility scripts for the management API calls to be run for the one-time setup.

View solution in original post

10 REPLIES 10

@sarah fernando

We have a similar CI/CD setup and repos setup for the api proxies and the configuration information as outlined by you.

Since there is no SCM plugin integration with Edge UI, the repos and the Edge configuration has to be manually synced.

At the beginning, developers may use Edge UI to develop the API proxies and also configure the environment dependent components. Devs will need to download the proxy code and add that to the repos. Later on, you should lock down edits and deployments through Edge UI to enforce everything is done through CI/CD. Its a preference on convenience whether you want to lockdown for all environments or only for QA and above.

The config information - caches, KVMs, target servers etc need to be added to the common repo.

In my experience, products and devapps creation and updates when done through the repo+maven config plugin, will cause two issues

1. Config reruns may be required - to avoid config deployment error if you try to create/update the product when the api proxy isn't yet deployed

2. Devapp updates will create a new set of keys, which may be undesirable

So I would suggest, any one-time configuration effort should be done manually and not through the config repo. If you have a Apigee config management team, they could build utility scripts for the management API calls to be run for the one-time setup.

Thanks for the clarification - can I ask you, how do you maintain the shared-pom.xml? If I keep it in the common repo, in the build pipeline I am not able to check it out since it only allows to check out one source repo in DevOps. thanks.

@sarah fernando

I have the shared-pom.xml for the proxies, stored in each repo.Since the shared POM is not going change, you can generate the shared pom by adding its contents in the CI pipeline as a powershell task may be.

Does this mean you are using only the maven-deploy-plugin in your CICD pipelines and not using the config plugin? We can do the initial Edge config of products, apps etc via the Edge UI and export it to a common repo that holds the multi file config jsons.

We are using both. WE have maintained separate repos for the config and the api proxies. The config repo is configured with a CI/CD pipeline to use the maven-config plugin. The api proxies repo is configured to use the maven deploy plugin.

Are you able to share the pipeline for your config repo? Would like to confirm if you are doing an update of the entire edge config whenever a change is made in the repo? thanks!

cud-sharedflows-apigee-cd.txtcud-apigee-config-cd.txt

I exported the pipeline to json, rename the files and check.

How do you coordinate the edge config updates vs proxy deployments? also, assuming that you shouldn't be storing your consumer keys/secrets in the developerApps.json (in config repo) how do you store this info?

Also, our common repo will contain the shared flows as well. Do you treat the shared flow deployment process in a similar manner to the proxies?

Yes the sharedflow deployment process is treated similar to the proxies. We have a single repo containing all the shared flows in multiple folders and a CI/CD associated with it. The CD has scripts to traverse through each of the folder and then deploy then using the maven deploy plugin