Deploying a renamed proxy through CI/CD - how to associate the original apikey and product?

[sarfernando]

Hi,

We are in the process of implementing CI/CD pipelines using Azure Devops and the apigee maven plugin for our apigee proxies. Having referred to this article, a new proxy is created with a new basepath and proxy name. However we are using the Verify api-key within the proxy. The original proxy was associated to an API product with an apikey. What is the best practice in this scenario to associate the newly renamed proxy with an apikey to the existing product as we cannot test it otherwise? can we using the maven-config-plugin for this?

thanks.

[deboraelkin · Accepted solution]

You should update the product definition to remove the old proxy and add the new one, and adjust any paths, if changed.

You can do that with the maven config plugin. Use update as config option and apiproducts as goal. Make sure edge.json reflects the right product definition

,

You should modify the product definition to remove the old proxy and add the new proxy. Make sure to also update any paths, if changed.

You should be able to use the maven config plugin using apiProducts as the goal and udpate as the config option. Make sure edge.json reflects the appropriate product definition (proxy name and paths)

[sarfernando]

Could you also please confirm if using CI to deploy feature branch code to the dev environment using these maven plugins is the recommended practice by Apigee? Or should a developer do the deployment (either using these plugins or the UI) manually, and CI should be used only once code is merged to master branch and during promotion to other branches (test, sit, prod etc)?

[deboraelkin]

Apigee is agnostic in terms of how to deploy to the Dev environment. Some customers will give developers a lot of freedom on how to deploy to the Dev environment, especially for small teams, whereas other customers mandate deployment only via CI. Both approaches of course have their pros and cons.