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:
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! Go to Solution.
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.