API Proxies deployment revisions in test and prod environments

Not applicable

Hi, We have deployed few proxies in test and prod on May 14th. So, It was created Revision 1 which should be fine in test and prod. Yesterday we have deployed new and enhanced proxies into Test environment, it was created Revision version 2 which is fine. We have n't deployed anything into prod environment yesterday but revision version 3 was created in Prod. Not sure why revision version was created in Prod. Can anyone please advice? Thanks!

Solved Solved
2 14 2,402
2 ACCEPTED SOLUTIONS

Not applicable

@Swapna , Use the below API to get the audit information on your APiproxy with expand = true.

http://apigee.com/docs/management/apis/get/audits/organizations/%7Borg_name%7D/apis/%7Bapi_name%7D

It will tell you if that was deployed to prod accidentally from the UI or using the deploy API.

View solution in original post

Hi @Swapna,

It's possible that someone else deployed a new revision to the prod environment. To check this, please visit the option under Project >> API Proxy History.

519-screenshot-api-proxy-history.png

Once you click on that, you can view that history of change actions (such as deployment) taken on the proxy.

520-screenshot-api-proxy-history-actions.png

In the above example, Revision 2 of the Weather API was deployed to the 'test' environment at 4:42 pm 06/02/2015 by user vidya@apigee.com.

Hope this helps!

View solution in original post

14 REPLIES 14

Not applicable

@Swapna , Use the below API to get the audit information on your APiproxy with expand = true.

http://apigee.com/docs/management/apis/get/audits/organizations/%7Borg_name%7D/apis/%7Bapi_name%7D

It will tell you if that was deployed to prod accidentally from the UI or using the deploy API.

Hi @Swapna,

It's possible that someone else deployed a new revision to the prod environment. To check this, please visit the option under Project >> API Proxy History.

519-screenshot-api-proxy-history.png

Once you click on that, you can view that history of change actions (such as deployment) taken on the proxy.

520-screenshot-api-proxy-history-actions.png

In the above example, Revision 2 of the Weather API was deployed to the 'test' environment at 4:42 pm 06/02/2015 by user vidya@apigee.com.

Hope this helps!

Thank you Vidya and Maruti Chand. It's very clear. But I have one more question. I have weather proxy with revision 5 as shown in below example. I have deployed this proxy thru shell script in test and it's created revision 5 which is fine. Again I have deployed the same into pro thru shell script. It's created revision 6 in prod. Why it is created revision 6? It has to create revision 5 only right in prod also.

Is APIGEE would create revisions automatically if I'm deploying to script in prod env? or how it will work?

Example:

<APIProxy revision="5" name="weather">

</APIProxy>

@Swapna ,

Once you have 5 on test , you can deploy the same on prod env and you don't need to import it again .

Can you copy your script ? Want to check the sequence of APIs that you are calling .

Not applicable

@Maruti Chand. We are deploying the same revision 5 into prod by changing only the below environment variable in script. It is only automatically, creating new revision in prod i.e revision 6.

Ex: [ -z "${ENVIRONMENT}" ] && ENVIRONMENT=test

We are also using override_delay option in our pom.xml.

Ex: <apigee.override.delay>10</apigee.override.delay>

Why it is creating revision 6? I know, how to deploy from enterprise.apigee.com UI from test to prod. But don't know thru script. Do you have any sample script to deploy from test to prod? Attached my sample script.

Just now I have created one proxy with revision 5 and deployed thru script in Test env. It's deployed successfully but it's showing revision 1 instead of 5. I'm really very confused then how the revisions are working in APIGEE. So, it won't consider the revision attribute which we are defining?

Ex:<APIProxy revision="5" name="test_v1">

One more thing, If I have deployed same proxy twice or thrice then it has to create the revisions right? It is not creating revisions. It's just updating the current revision. I have a requirement to generate a new revision for every deployment. How can we achieve this?

Attached the sample proxy. Can anyone please explain me how revisions are creating in deployment?

adas
Participant V

@Swapna The script that you have, deploys the testproxy.zip in 2 steps. Step 1, it imports the proxy to your org and Step 2, deploys it to an environment.

When you import an apiproxy, with a name that already exists Apigee Edge treats that as a new revision and that's the reason you see Revision 6 getting deployed once you run the script. Whereas when you import a zip (any revision of a n apiproxy) into a new apiproxy, it always creates revision 1 because no other revision exists for that apiproxy. I hope this is clear. If you tell me, what exactly is that you want to achieve, I might be able to suggest you some suitable alternatives.

Not applicable

@arghya das

Thank you. I got your point. I have tried by removing step 1 in my script. But then also it's creating new revision in prod. Why it is creating new revision?

Ex: I have the highest revision 3 in test environment proxy and I have deployed the same proxy into prod by script by removing Step 1, it is creating revision 4 in prod. But it should create revision 3 in prod as we have revision 3 as highest revision in test.

One more thing, We are defining revision in APIProxy xml file for proxies. So there is no need of defining revision attribute externally right, as Apigee Edge is creating the revisions based on deployment. Please advice.

Ex:

<APIProxy revision="4" name="weather">

</APIProxy>

Just now I have removed Step 1 from the script and tried to deploy one proxy in test, it's deployed successfully and created revision 1 in test. Not sure then how the deploy is happen if we don't have step 1 also. Again tried to ran the same script in prod, it's created revision 2 in prod. As per you, it has to create the revision 1 only right in prod?

So I believe, maven install is creating package and installing it. So, no use of Step 1. What is the script to only install the same proxy in prod with the same highest revision number in test?

I also tried removing Step 2 and run the script in test, it showed me build success in logs but actually, api proxy bundle is not deployed in my org so script is not working as expected.

Is there any sample maven script available for deploy and install?

Not applicable

Hi @Swapna . In order to deploy your API Proxy without importing a new revision, you need to make sure that your script applies a few steps in the right order to the right resources, which I'm going to explain with Apigee Grunt working in two modes: UPDATE_CURRENT_REVISION and IMPORT_DEPLOY_BUMP_REVISION.

1) UPDATE_CURRENT_REVISION Target executes tasks sequentially. So, in this mode the API Proxy gets undeployed first (undeployApiRevision), then updated with the same revision with a new bundle (updateApiRevision), and then deployed (deployApiRevisionAlias). To update the current revision in this way, you'll need to make sure that your scripts are executed in the same sequence. The key task to update the same API revision is updateApiRevision, which POST /revisions/1 the API proxy bundle (zip file) to the revision resource. Conversely, you'll find that with IMPORT_DEPLOY_BUMP_REVISION mode makes a request against the apis resource. POST /apis?action=import&name=apigee-deploy-grunt-plugin-test, which bumps the revision id to next available one.

Please observe the cURL command to spot any differences between each mode, so you can either leverage a build tool or implement your own.

//update revision keeping same id
grunt.registerTask('UPDATE_CURRENT_REVISION', 
[ 'buildApiBundle', 'getDeployedApiRevisions', 'undeployApiRevision',
    'updateApiRevision', 'installNpmRevisionAlias', 'deployApiRevisionAlias', 'executeTests', 'notify:ApiDeployed']);


$ grunt UPDATE_CURRENT_REVISION --env=test --username=$ae_username --password=$ae_password --upload-modules=true --debug --curl


Running "getDeployedApiRevisions" task
[D] Task source: grunt/tasks/getDeployedApiRevisions.js
curl -X GET https://api.enterprise.apigee.com/v1/o/testmyapi/environments/test/apis/apigee-deploy-grunt-plugin-t...
[D] 200
[D] {"access-control-allow-methods":"GET, POST, PUT, DELETE","access-control-allow-origin":"*","content-type":"application/json","date":"Thu, 04 Jun 2015 14:30:33 GMT","content-length":"1380","connection":"Close"}
...
Running "undeployApiRevision" task
[D] Task source: grunt/tasks/undeployApiRevision.js
curl -X POST https://api.enterprise.apigee.com/v1/o/testmyapi/apis/apigee-deploy-grunt-plugin-test/revisions/1/de... -d '{}'
[D] 200
[D] {
  "aPIProxy" : "apigee-deploy-grunt-plugin-test",
...}


Running "updateApiRevision" task
[D] Task source: grunt/tasks/updateApiRevision.js
curl -X POST https://api.enterprise.apigee.com/v1/o/testmyapi/apis/apigee-deploy-grunt-plugin-test/revisions/1?va... -d '{}'
[D] 200


Running "installNpmRevisionAlias" task
[D] Task source: grunt/tasks/installNpmRevisionAlias.js


Running "installNpmRevision:1" (installNpmRevision) task
[D] Task source: grunt/tasks/installNpmRevision.js
[D] skipped installNpmRevision due to upload-modules option


Running "deployApiRevisionAlias" task
[D] Task source: grunt/tasks/deployApiRevisionAlias.js
[D] Task source: grunt/tasks/deployApiRevision.js
curl -X POST https://api.enterprise.apigee.com/v1/o/testmyapi/e/test/apis/apigee-deploy-grunt-plugin-test/revisio... -d '{}'
[D] 200
[D] {
  "aPIProxy" : "apigee-deploy-grunt-plugin-test",
...}


Running "executeTests" task
[D] Task source: grunt/tasks/executeTests.js


Done, without errors.
Total 16.7s

2) IMPORT_DEPLOY_BUMP_REVISION Target is Equivalent to the behaviour that you're currently observing, which bumps the revision id. Please note that this target executes apigee_import_api_bundle, so, in this case, a new bundle gets imported and then deployed.

grunt.registerTask('IMPORT_DEPLOY_BUMP_REVISION', [ 'buildApiBundle', 'getDeployedApiRevisions', 'undeployApiRevision',
    'apigee_import_api_bundle', 'installNpmRevisionAlias', 'deployApiRevisionAlias', 'executeTests', /*'shell:run_jmeter_tests',*/ 'notify:ApiDeployed']);


Running "apigee_import_api_bundle" task

curl -X POST https://api.enterprise.apigee.com/v1/organizations/testmyapi/apis?action=import&name=apigee-deploy-g... -d '{}'

As you can observe Gruntfile.js is fully configurable, so you can manage the tasks and the order in which you want to execute them.

I'd encourage you to try these tools and supported modes. Please also be aware that seamless deployment requires the current and the new revision, so for a production environment, it is advisable to keep the revision history to avoid any traffic disruption.

adas
Participant V

@Swapna There you go, @dzuluaga just covered all that you need to know, to be able to deploy the same revision without importing a new revision.

Not applicable

@dzuluag Thanks a lot for the explanation. Will try with the Apigee Grunt script.

Is it possible to achieve the same thing in shell script (and maven)?

Is there no use of defining revision attribute explicitly right? Because Apigee edge is generating revisions at the time of defining revisions. Please confirm.

Ex:

<APIProxy revision="4" name="weather">

</APIProxy>

adas
Participant V

@Swapna Yes, setting the revision attribute wouldn't have a bearing, if you are importing the proxy everytime. Edge would update the revision id based on the internal revision count.

Not applicable

@arghya das Thank you.

Can someone suggest me can we achieve the without importing a new revision for api proxy in shell script using maven? As per @dzuluaga it is been achieved by using Apigee Grunt. Please confirm.

Thanks in advance.

The profile options from the shared pom.xml file can be configured to override the revision. Please take a look at the Advanced Configuration Options section.

adas
Participant V

@Swapna In the current script when you are importing the zip you might be passing something like this:

/v1/o/{orgid}/apis?action=import&name={name}

Like I said, this would always import as a new revision.

If you want to import into the save revision, you can try this:

/v1/o/{orgid}/apis/{name}/revisions/{revision-id}?action=import

So you can get the currently deployed revision for the apiproxy through a GET call and then use that in the above call. But I would NOT recomment that for any apiproxies which are deployed to production because of few potential issues:

- you cannot use zero downtime deployment because you are importing to the save revision that is currently deployed

- if the imported zip has any issues like bad policies, incorrect/corrupted zip etc. the deploy would fail, this means the existing deployment would get impacted and your clients would see downtime while calling the api

- by importing into the same revision, you would not be able to keep the existing proxy definition so you would not be able to fallback to the previous version.

These are the reasons why Apigee Edge follows the concept of revisions, and the maven deployment plugin always imports as a new revision and then deploys as a new revision so that there's zero downtime.