- Over Transfer
- Werken bij
At this years Next Step OutSystems CEO Paulo Rosado announced an improved version of LifeTime. This improved version is necessary because OutSystems customers are developing at the speed of light and after some time they will have very large portfolios of applications. This results in the staging of applications from one environment to another taking too long. But even with this improved staging optimization, how can you manage all your applications in LifeTime?
Lets first take a few steps back, what is LifeTime?
LifeTime is a unified console with visibility of all the environments on the same OutSystems infrastructure. It manages the deployment of applications, IT Users, and security across all environments
Of course, with this definition you know everything you will need to know… or maybe not? The complete documentation for LifeTime can be found at: OuySystems DOCUMENTATION and should be something that your IT infrastructure or Cloud manager should read!
It’s all about working consistently and accurately!
Let’s focus on the application part of LifeTime and how we can manage this. The problem that many companies that I visit face is that multiple developers use LifeTime and there are no common agreements. The tagging (versions) of applications is random and an application that is already in production has version 0.152 for some reason. Forge components aren’t tagged and are changed without comments to the original code. The result: LifeTime is a mess and the probability of errors is very high. But how can we fix this? Working in LifeTime is all about working consistently and accurately. Rules or common agreements should be agreed upon between all the development teams before the first application goes to the next environment.
Creating these common agreements about how to use LifeTime is very personal and will probably vary from company to company. But let me just point out a few tips from my experience.
Forge components in LifeTime
When installing forge components immediately tag the components in LifeTime with the same version as the installed forge component. After installing forge components the connection between your local version and the version in the forge is broken. So if the developers of the component come up with a new version in the forge you can now easily check if you should upgrade or not.
Tagging in LifeTime
You can tag your applications in the following format: M.m.r (Major.Minor.Revision).
The major position is something that will be different in each project. Usually you use version 1.0.0 when going to production for the first time. When should you go to version 2.0.0? It’s up to you, but normally this is done when you have really new functionality in your application.
OutSystems is usually used in combination with an Agile method like Scrum. Using the iteration or sprint number in the tag is a good way to connect you application version to the sprint. The minor (m) could be your current sprint (like sprint number 14) so before production when you start sprint number 14 your application tag would be 0.14.0
The revision position can be used as an ascending number within your sprint. Probably you want to deploy to test multiple times, or you want to tag your application every time you have finished one particular user story. Example your application is already in production and you are currently in sprint number 11 your tag could be: 1.11.6
Keep it clean
There are a bazillion different other ways to keep your LifeTime clean like:
And you can probably think of many more.
Remember you and your team are the ones that can make a total mess of LifeTime or create nice stress-free environments where we all would be happy. Do you have some other useful tips or tricks that you use to manage your LifeTime, let me know!
 This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated.
8 juli 2019 • Transfer Solutions
19 juni 2019 • Jacob Beeuwkes
11 mei 2019 • Brian van Bruggen
9 maart 2019 • Jurgen Duijster