How to deploy a Sharedflow or Proxy to multiple Environments using apigee-deploy-maven-plugin

Former Community Member
Not applicable

I am using Apigee deploy maven plugin to deploy sharedflows and proxies via CICD.

I have two environments in an org. If I want to deploy a SF or proxy to two environments at the same time, is that possible with the tool?

This is what is happening:

When I "override" a SF to env1, it is being created and deployed with revision x.

When I "override" the same SF to env2, it is being created and deployed, but with revision x+1.

This is what I want:

Because it is the same SF, I would like to deploy the same revision to both the environments. As I am deploying separately, it is incrementing the revision.

@Sai Saran Vaidyanathan, @Siddharth Barahalikar

Thanks for help!

0 3 152
3 REPLIES 3

@maneesh m

It is recommended to use override. Reason is - when you make change to an existing revision (say using the UI), the change gets pushed to all the environments that is using that revision. All your changes should be tracked using your code repo. The maven plugin takes a code base, packages it and then deploys it. I think you are following recommended practice to deploy to higher environment. In this case, you just need to call the maven command twice pointing to two different Maven profiles.

However when you are in the dev environment, you can use the "update" option in the maven profile so it deploys the code in the existing revision but do that only for the dev environment as you dont want the revision numbers to creep on. But for higher environments, keep it as override so that its easy for you to manage, rollback, etc

Former Community Member
Not applicable

Hi @Sai Saran Vaidyanathan, that is good suggestion for an org with two environments that are at different levels. for example test, prod.

In the case my org, both the environments are at the same level but for two different testing purposes. So I want to keep the same revision of the SF or Proxy in both the environments.

Is that possible?

With two different testing purpose, shouldnt it still be two different revisions ?? For example if the first test in env 1 found an issue and they are fixing it, applying that fix to that revision will push the change to the other environment as well which could cause issues or impact the other testing. I would still recommend two different revisions even though the source code is the same