OutSystems DevOps Model Series: 2-Requirements
If you already used OutSystems in a real-life scenario you know that a standard license normally starts with 3 environments (Dev, QA and Prod) plus Lifetime:
However, is it enough?
Well… if you used OutSystems long enough in a real-life scenario… you may answer no to this question.
Especially when you are supporting mission critical apps that are already in production and still evolving, you most probably must have had issues with hotfixes and new releases trying to co-exist in the same lifecycle.
The problem becomes even worse when you have a large factory with lots of different apps, from different sponsors sharing common Libraries.
And add an extra layer of complexity when you have multiple squads, third party vendors and projects working on the same environment.
With all that being said, how can we still use OutSystems and Lifetime in an organized way in these scenarios?
The good news is: That is possible! And with a little bit of planning this can be implemented right now with the Model we want to propose!
The bad news is: You will need an extra environment on top of your 3 initial ones!
If you already have it… perfect!
Otherwise, this can be something you should consider, because it will make your life a lot easier.
Let’s start with the ‘why’!
Why we need this extra environment?
After that… once we understand it lets jump in the DevOps Model and understand how we keep it organized when using in a large factory, with lots of squads and different apps.
If you are already familiar with this concept you may want to jump straight to the part 3 of this series. Where we will talk about how to setup your environment in the proper way.
Normally when we have 3 environments what we do is:
- Use DEV environment to develop
- Once our development is completed, we use LifeTime to stage the code to the QA environment.
- On QA, the testers will test it and accept the features.
- Then, after the testing we finally use LifeTime again to stage to Prod where the end users will use it.
You can have an idea looking at the follow image:
However, what would happen if:
- My app is already been used in Prod by my end users.
- Some new features are already being tested in QA by my testers.
- And I find a critical issue in Prod that I must handle right away?
I can’t use the normal path (Dev -> QA -> Prod) because if I do it I will release features that were not accepted and tested to Prod.
The only answer would be to fix it directly in Prod!
And ideally, we don’t want to do that! For numerous reasons such as:
- I will not have a proper test because I’m doing it directly in Prod.
- I can delete prod information.
- I can break other features.
- And the list goes on
It is a huge risk to change thing directly on Prod! So, what we can do to solve this?
The answer is… add an extra environment:
Let’s call this new environment ‘Pre-Prod’.
Once we have this environment what we can do is to use QA to test the new features, and keep the Pre-Prod with the same code version as Prod. This way when we find a critical issue, we can fix it on Pre-Prod where we will have time to test and then stage it to Prod.
Now that we understand the main reason and benefit of this extra environment let’s go to the next article of this series where we will talk about Security and Access Control on all these environments.
Next: 3 — Access Control Policy
Previous: 1 — Introduction
OutSystems DevOps Series Articles:
Disclaimer: Most of the material was gotten from OutSystems documents
