Roll Back a Deployment using the LifeTime API
Application Type
Traditional Web

We are trying to automate our OS deployments in to a AzureDevOps pipeline using the LifeTime Rest API, following the guide https://success.outsystems.com/Documentation/11/Reference/OutSystems_APIs/LifeTime_API_v2/LifeTime_API_Examples#Deploy_an_Application I think we have the logic understood.

One thing we do need to provide is the ability to roll back to previous versions, I am able to get the keys of previous app versions, using GET /applications/{ApplicationKey}/versions/  however, how do I build a deployment from this, as the API errors if I set the source and target to be the same? 


Hi Rachel,

With Lifetime you cannot deploy from and to the same environment. If you want to perform a rollback (on PRD for example) you must know what the previous versions were of the applications you have deployed (so GET Deployments/{deploymentkey} of the one you want to rollback, then you must create a deployment from the (for example) TEST environment to select the previous application versions and start deploying this one from TEST to PRD. 

The difference in thinking is that your previous version of your application is still available on the TEST server you deployed it from in the first instance.

Hopefully this will answer your question.

Thanks for your feedback, is there an easy way to see what the previous versions were deployed using the API as  I can't seem to see the details of previous deployment plans, I just receive the message:

{

   "Errors": ["There was an error calculating outdated apps for deployment with key '38753e24-02aa-4eb6-8af6-466a7417b171': Invalid status change: trying to change Staging with id  '1242' from 'Finished' to 'Calculating apps to redeploy'."],

   "StatusCode": 500

} 

I only seem to be able to query current running versions, or a list of all versions. In our sub prod environment we may have many versions, so its not as easy to just go back one iteration for example Test may have versions 1,2,3,4 and 5 we only pushed versions 2 and 4 to prod, therefore when 4 failed we wouldn't want to roll back to version 3.

One option might be when we do a deployment, create two deployment plans, and one remains undeployed. For example we want to do a deployment of version 2 from QA to Prod create plan 2a and plan 2b. We only ever execute plan 2a. Next release cycle we deploy version 4 so create plan 4a and 4b, we deploy 4a, and in the event that we have to roll back, we can use deployment plan 2b. The downside being if any other apps had been deployed in between the two deployments of a certain app  that had updated dependencies/shared modules we might have issues.

It feels a bit clunky, currently before we do a deployment we create a solution file of Prod backing everything up, and its that we would roll back to, I guess the other option would be to capture everything that's running pre deployment and store that info, then have to run a comparison to build out a roll back deployment.

I think I have just found half my solution, using /Deployments/?TargetEnvironmentKey=xxxxxxxxxxxx&MINDATE=yyyy-mm-dd1&MAXDATE=yyyy-mm-dd 

It shows me the content of the deployments and the environments from which they came :-)



Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.