OutSystems recently released Agile Platform 7.0. The really big news in the announcement was a total overhaul of the multi-tenancy system (I’ve used it, and it is great). 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). A few weeks ago I had the opportunity to work with Lifetime on a customer’s project, and I came away quite impressed.

In Lifetime, you define a number of environments and which direction things get deployed out. The pre-defined environments are Development, Testing, and Production (Figure A). 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.
Figure A

An initially empty Lifetime configuration (Click the image to enlarge.)

Hand-in-hand with the Lifetime feature are 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. Previously, I saw 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. From my in-a-clutch testing, I found that 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.

For a while, most of my Agile Platform work was with smaller customers who only had a Production environment, and I developed and tested locally on my own systems. In that scenario, using Lifetime did not make much sense — I would just bundle it all into a Solution and cut a new version of the Solution to deliver to the customer. Now that my clients have gotten a bit bigger, and they have more robust environments, Lifetime has already become an important part of the deployment process for me.


Keep your engineering skills up to date by signing up for TechRepublic’s free Software Engineer newsletter, delivered each Tuesday.