CICD Jenkins - Undeploy the revision to earlier deployed revision

[ashwithds123]

Hi @Sai Saran Vaidyanathan, @Siddharth Barahalikar, @Mohsin Khan, @williamssean, @Dino, @Kurt Googler Kanaskie

We are setting up a CICD Jenkins pipeline wherein we are using Apigee Maven Deploy Plugin once the deployment of proxy is done successfully we are planning to execute Apickli Gherkin scripts.

Use_Case: If the Apickli scripts get failed then the deployed revision must be un-deployed. However again it must re-deploy the earlier revision. (HOW CAN WE DO THIS?)

Scenario 1: From the below image_1 initially proxy has been deployed to revision 3 after executing maven deploy plugin a new revision 6 is created and gets deployed, now we are running the Apickli scripts as mentioned in the use_case.

Scenario 2: From the below image_2 initially proxy has been deployed to revision 5 after executing maven deploy plugin a new revision 6 is created and gets deployed, now we are running the Apickli scripts as mentioned in the use_case.

Any help would be appreciated thank you in advance.

Regards,

Ashwith

[sidd-harth]

Last year I have written a shell scirpt with Management APIs for a use case similar to your Scenario 2.

You can have a look at it in my repo.

https://github.com/sidd-harth/apigee-cicd/blob/master/undeploy.sh

You need to use this in a try..catch block. The script should be placed in catch block, so that it executes only when Apickli test fails.

[ssvaidyanathan]

@ash gun

Love the fact that you are using the community very effectively.. Keep it going !!!

The response from @Siddharth Barahalikar is a possible solution however not true in all cases. The script redeploys the previous revision number. For example if Rev 15 failed testing, Rev 14 gets deployed. What if Rev 14 is not stable ? and the most stable Rev is 9 ?

What you could is

1) For every build, pass a roll back revision number as a parameter (for safety) and if the build fails, use the script that is shared, tweak it and just deploy the revision using that parameter

or

2) Pass the stable commit id, branch or tag to the build so that it can pick that code and redeploy as a new revision if the build fails

[sidd-harth]

Yeah, I agree with you. I was just subtracting the newly deployed revision with 1 to deploy to the previous revision. This approach is a big NO when working with live APIs.

It was just for a demo so I left it as it is 😄

Thanks for the ideas, I will also update my repo with this 🙂

[ashwithds123]

Thanks, @Sai Saran Vaidyanathan & @Siddharth Barahalikar for the response. Looking forward for your updated repo.

[sidd-harth]

I have updated my repo.

[kurtkanaskie]

I'm with @Sai Saran Vaidyanathan's option 1.

Since my curiosity got the best of me, I implemented using the following sequence of Jenkins plugins and Edge management APIs to get the previously deployed revision and to re-deploy it on failure.

In the Pre Steps section:

Inject environment variables - to set org, env and proxy values.

EdgeOrg=YOUR_ORGNAME
EdgeEnv=YOUR_ENV
EdgeProxy=YOUR_PROXY

Execute shell - to get currently deployed revision (not pretty but it works)

Argh, something's blocking my code block (this is an image)

Inject environment variables - to set the current revision (see screen shot)

Then in the Post Steps section:

Conditional Step (single) - Run? Current build status with "Failed" for both worst and best status.

Execute shell - to get newly deployed revision and if they're different re-deploy the $PreviousRev

Argh, something's blocking my code block (this is an image)

See attached screen shots for additional clarity.