Apigeetool + CI/CD: deploy proxy multiple times results in n+1 revision in same organisation

Hi There!

I am trying to set up a CI/CD pipeline for our Apigee API proxies.

Setup is like this:

Our pipeline is triggered on every push to master. I want to 'deploy' 4 times (we have 4 environments). We have two organisations: non-prod (with env1,env2,env3) and prod (with env4).

We automatically deploy into env1. We have an approval stage to move deploy to env2, idem for env3 and env4.

I am using the Apigeetool deployproxy script. I'm setting the org and env for every 'stage'.

So this works and deploys the proxy just fine, but it will always bump the revision number with 1 in the same organisations. So when we run through the whole pipeline, we get a revision structure like this (lets assume there is no exisiting version):

OrganisationEnvironmentRevision
non-prodenv11
non-prodenv22
non-prodenv33
prodenv41

As you can imagine, this is not wanted behaviour, since env1, env2 and env3 are actually running identical versions.

I am aware of the scripts to get a list of revisions and deploy a certain revision number for an existing API, but these script are not pipeline friendly: it's very hard to pipe the output from one as input (because the list of deployed versions is returned as text with a few paragraphs -- not sure if matching with regex is an ideal solution).

What are possible solutions to get this result?

OrganisationEnvironmentRevision
non-prodenv11
non-prodenv21
non-prodenv31
prodenv41

Hope one of you have encountered this issue and were able to overcome it!

Thanks in advance

Thomas

0 18 1,447
18 REPLIES 18

Not applicable

I also faced the same issue. I found deployproxy command creates a revision of proxy present in the local and then deploys. That's the reason even the same content is there, still, it creates a new revision.

If you don't want the new revision and you are sure there is no code change, then better is to deploy the revision using managemnet api call.

Indeed, so how do you make sure you get the 'correct' revision number to deploy? Do you get the list of all revisions and 'user' the highest number available?

As our proxy development is automated with self-service, the proxy revision built and changes are tracked in our application. Developers can see their API build information there.

@Thomas Van Deun, I have faced the same issue too with apigeetool and still living with that.

We are using a workaround to distinguish the revisions by adding a task in the deployment pipeline to update the Proxy description with the build# details to identify that both revisions contain the same version of the code.

Hmm I see. It's good to now that I'm not the only one experiencing this. It's less than desired but yeah.. maybe just deal with it.

Did you have any issues with that setup?

Thanks

I had no issues with the setup. Just that you see a long list of revisions in the edge ui and you will need to make sure that the deployed revision for the environments, all have the same build#

Not applicable

using version control like git may help to resolve the issue. If the build is integrated with git and Jenkins then it will trigger when there is a new code pushed to your git. So, for same code it will not build the proxy again.

@Priyadarshi Ajitav Jena,

Integrating the build with git has no impact on incrementing the revision numbers.

At my organization, azure devops is used to run the CI and CD. the Release pipeline(CD) is tied to a single build artifact and the same build gets deployed to multiple environments.

The issue is with apigeetool - it first retrieves the existing revision number and increments by 1 while deploying the code. So if you have multiple environments in an apigee ORG, the same build deployed to multiple envs will have different revision numbers.

Have you observed a different behaviour with maven deploy plugin?

let me explain what I said. If you integrate git to jenkins for webhook, until there is a new commit new build will not happen. This will help, if the code is not changed then new jenkins build will not happen. So, there won't be another revesion.

It does not work that way. What Thomas and I are talking about is a single build (with the same build#), when you try to deploy it to multiple envs within the same org, the revision # gets incremented.

For eg: build# 1.2 corresponding to commitId ac125345

If the current proxy revision in apigee is 1, when you deploy build#1.2 to dev revision would be 2. You deploy the same build#1.2 to qa, revision would get incremented to 3.

what we are expecting to see is this (since the build# deployed is same)

10141-proxydeployments.png

what we are seeing is this

10143-proxydeployments2.png

The issue seen is because, there is no correlation between the revisions maintained by Apigee and the build#s maintained by the CI/CD. That's the part we are trying to figure out.

@Sai Saran Vaidyanathan any suggestions on this?

You are not able to get what I am saying. I have already fixed this issue. I said to deploy the same revision in another environment of the same organization use the management api call, and make your proxy deployement through git commit with Jenkins auto-build, so that if there is no code change then your proxy build will not happen again. You need not to go for jenkins build.

Sorry, what you said was "let me explain what I said. If you integrate git to jenkins for webhook, until there is a new commit new build will not happen. This will help, if the code is not changed then new jenkins build will not happen. So, there won't be another revesion."

It didnt mention using management API to deploy a specific revision


In your recent comment, you have mentioned "I said to deploy the same revision in another environment of the same organization use the management api call"

How do you correlate between the build# and the Apigee revision #

For eg:

Build#1.4 is deployed to Apigee dev env as revision 23

Build# 1.2 is deployed to Apigee qa env as revision 21.

If the same build 1.2 is to be deployed to uat env, how do you maintain the mapping that build#1.2 corresponds to revision 21?

If you could explain that, it might help as that's the missing piece we are trying to figure out.


I agree with Nagashree. We have a very similar process, and building the API Proxy doest not affect revision number. I'm not sure if the maven plugin works differently, but I assume the NPM is just a wrapper around it anyway...

Thanks

maven deployment doesn't have this issue. I experienced this with only apigeetool.

In the situation you're describing (deploying the proxy into the same org, different environment) apigeetool deployproxy wil always create a new revision, as the proxy is already deployed in that org. https://github.com/apigee/apigeetool-node#deployproxy

You could use apigeetool deployExistingRevision to deploy the same revision to the different environment.

Personally, I don't think it's too much of an issue of having the same proxy deployed as different revisions. Judicious use of source control (eg: using tags when deploying to an environment, or adding a commit id as part of the proxy description) should always allow to trace back the proxy to the source control, independently of its revision

@deboraelkin

Yes that is true Debora that apigeetool always increments the revision. In order to use the deployexistingrevision option, you would need to know the mapping between the build# and the revision# of the proxy which is kind of hard to maintain or derive.

I don't have an issue either - with a different revision being assigned for each deployment. Since the build#s deployed are tracked through our devops pipelines.

It was a little hard to convince our QA and App support teams as it seemed to them that the code versions different since the revision numbers are different since they don't look at the deployment pipelines.

I was mentioning to @Thomas Van Deun here that i used a workaround to distinguish the revisions by adding a task in the deployment pipeline to update the Proxy description with the build#, commit and branch details to identify that both revisions contain the same version of the code.That way our QA and support teams were satisfied; additionally even if the build artifact was lost for some reason, a new build could be triggered with the commit id. Something like the below is working for all our teams right now.

10145-proxydescription.png

Hello @nagashree_b : How did you update the deployment pipeline to update the description tag ?

@pranali , I updated the CI pipeline - added scripts (powershell) to parse the proxy XML file and update the <Description> tag with the values from the build pipeline variables. We use azure devops for CI/CD at my organization and hence I used powershell for the XML manipulation.