Non Sequential Revisions

[daniel_biales]

We have a non prod and prod installation of apigee on-prem. We are using a CI pipeline to promote proxies from dev to test to prod.

The issue we have run into is with revision numbering between our non prod and prod installations.

Here is the scenario:

In non prod - dev we created and deployed revisions 1-5. Now through the pipeline we deploy revision 5 to test. That works fine because revisions 1-5 exist in the Nonprod installation. Next we want to deploy to prod. We want to keep it as revision 5 for traceability but the proxy does not exist in prod and revisions 1-4 do not exist in prod so the deploy fails with a 404. We are using the Apigee Maven Plugin.

Is there anyway around this error?

[madhans]

It is preferred to use tagging or some other form of release numbering in source control system as a tracking mechanism. This tag can be added to "description" element in the parent xml file to help in tracking back from Edge UI.

The maven plugin's default behaviour is to deploy a new revision in any environment. Apigee does not support non-sequential revisions so you need to create the same number of revisions to match revision numbers.

[daniel_biales]

Can you expand upon tagging? is that a maven specific thing or is there a way to do it in apigee?

[#4]

@daniel.biales tagging is offered at source code control system you are using for your code repo. When the code is moved between dev to qa to prod, it is recommended that you create tags at each stage so that if you need to recreate a certain version, you can do it from the tag or label (as it is called sometimes). You can also provide this info in the package so that you can check which version/tag is deployed.

Using apigee revision number for releases in different env is not recommended or is not best practice.

Hope this helps.

[daniel_biales]

We are using build numbers as a form of tagging but we want the Edge UIs to line up as well

[#6]

You could do that if you really wanted it, but it is going to be a maintenance nightmare to match up the revision numbers in different env. Typically, the revision numbers in dev will be many more than in QA and PROD.

[daniel_biales]

@pdani This is how we did it https://community.apigee.com/comments/30180/view.html

[daniel_biales · Accepted solution]

Actually I found out that you can create a revision and then delete it and by that means we could get to revision 5 in Prod with no revisions 1-4

[ssvaidyanathan]

Hi @daniel.biales

Just curious, can you explain how you are using your Source control and connecting that with your CI/CD process ? When you use the maven deploy plugin, it creates a revision and deploys to the environment you pass in the -P argument. But the same revision can be pushed to production using the UI or Mgmt API if you know the revision that needs to be deployed. You can run a simple curl to do the same which can also be done using CI tools like Jenkins.

The process that @Madhan Sadasivam mentioned is more to do with the code repo tagging standards so that you can maintain the release versions, hotfix revisions, etc which is easy to maintain within a CI/CD pipeline. In this approach, a new branch for PROD will be created (merged from different branches if needed) and this will be used to deploy using the maven plugin. In this case, it will be revision 6

Not sure what you mean by creating 5 revisions and then deleting 1-4. If you delete the revisions, then you cant deploy on the other environment. You will need to re-deploy which will be the 6th revision as the last revision deployed is 5.

Would be nice if you can describe the current process and we could probably see if there is another approach to your requirement rather than creating revisions and deleting them just for having the same revision number

[daniel_biales]

Our current approach is to have 2 separate installations of Apigee Edge (non-prod & prod). In non-prod there are 2 environments dev and test.

The developer creates the proxy and can deploy it to dev. Then to deploy to test they need to go through the pipeline. The build plan downloads the proxy from non-prod and downloads a git repo that includes pom.xml and config.json. It then packages this up with Maven and stores it in an artifact repository.

The non-prod deployment plan downloads the artifact. It uses the maven plugin to configure and UPLOAD the proxy (which overrides the proxy revision that was developed in non-prod). Then we use a script to undeploy any revision that is deployed in test and then deploy the proxy to test.

The prod deployment plan downloads the artifact. It uses the maven plugin to configure and DEPLOY the proxy (which creates a new revision). Then a script checks to see if the revision is the same as the revision deployed in non-Prod. If it isn't it deploys(through the API) the proxy repeatedly until the revision numbers are equal. Then it UPLOADS the proxy through the maven plugin (which overrides the revision) and deploys it(through API). Finally it deletes all the extra revisions that were created( If revision 5 was deployed in test and 1 was deployed in prod it would create revisions 2,3,4,5 and then delete 2,3,4)