Agile Platform’s Lifetime makes application deployments a breeze
Posted July 25, 2012on:
OutSystems recently released Agile Platform 7.0. The really big news in the announcement was a total overhaul of the multi-tenancy system. Another item that flew under the radar is the new Lifetime feature, which is a method of deploying applications and managing the lifecycle (without any relationship to the TV channel).
In Lifetime, you define a number of environments and which direction things get deployed out. The pre-defined environments are Development, Testing, and Production. Lifetime allows you to “tag” a particular set of revisions with a version number, and then push them to the next environment in the chain. It detects if changes have been made in an environment’s version by marking the version number with a plus (for example, 1.8+), which gives you a cue that you may need to backport changes or deploy from downstream servers with caution. This is great for the age-old issue of people patching directly on upstream servers.
Hand-in-hand with the Lifetime feature is improvements to the way you define Applications and the system for maintaining them. There are a lot of minor changes to Applications that add up to an overall improvement. For example, there is a little reason to use an Application over a Solution, but with Lifetime, the Applications get all of the versioning and single-click deployment of a package and dependencies that Solutions have, with additional awareness of things like which eSpace in the application manages users and roles.
Ideally, you make your changes in Development, and when you are ready to test, you tag them with a new version and push to Testing. Once your testing is complete, you deploy to Production. But, what if you have to hot patch in Production? Well, there are no worries. If you take the patched version from Production and deploy it to Testing or Development, it will show the versions as being in sync again. The worst-case scenario is that you have patched Production and have changes in Development to push out. Going to the Development version and doing a merge from Service Studio with the Production version to backport the patch and then deploying the merged version back to Development will mark everything as up-to-date and happy.