It has always been complicated for me, as a project leader of an Odoo implementation and in a certain way also as a final client, to be certain that I am testing functionality as it will be used by the client in production once it is approved by the client. It sounds strange, but it is SUPER complicated to conjugate in the same environment: the actual updated data of the client, the configurations agreed upon at the moment and the latest changes in the code, especially if we take into account that in the same day it can happen (and several times!) that:

• The client loads or updates data: products, clients, accounts, etc.

• I, as project leader, change the discussed configurations with the client: new price lists, a new permit, etc.

• The developers improve or update functionalities via code as the Merge Proposals are approved.

The problem is old and known, but we at Vauxoo managed to find something that would have improved this scenario for everyone in general: the project leader, the consultants/developers, the final client, the  sysadmin  and others who need context that is truly READY.

I'm going to explain how I understood the essence of DeployV's, operation, I do not know if it's the best way to explain it, but for me at least it was the best way to understand it.

First of all, the best way to understand something is to ask yourself the key question whose solution is what you end up learning; something like start programming the test before the functionality. In this case, my question was:

Where # &% * $ "! is the instance with all the updates we did today?

(Code, data, configurations)

The answer is not simple, but as Jack the Ripper would say, we go by parts. This image is the main visual for the understanding of this.

 we have four environments or instances:

• Updates

• Production

• Test

• Develop 

The Instance of Updates a pre-production is an instance that is updated every time it is approved. One Merge in any of the repositories that compose and not yet passed production. If for example in the addons- vauxoo repository in the main branch 11.0 the merge request #de2ad24 is approved we can see the Update instance with the following information:

What does this mean? It means that now the changes in that commit can be tested in that instance if you want.
But what happened with the settings you had in that instance? They are lost.
And when do I see Changes in Production? From Updates, you ask for the pass to Production in the Schedule button. Configurations that you have made are not passed, they only pass changes at the code level.

What if I want to test the changes before going into production? The essence of Updates is really that. If we want to test the code changes in the closest way to a possible Production instance then we do a Regenerate to the instance in such a way to load a newer database (the most recent production backup) without changing the commits. This way we are surer of knowing if something broke functionally.

 The Test instance will not necessarily have the latest changes made to the code. The Test instance will contain a copy of the Production instance each time you regenerate it. This copy will have the database of the last support made of Production.

Do you remember that I said that in Updates you have to expressly request the pass to Production? Well, that means that in Test you will have the latest version of the code only if you passed to Production what exists in Updates. In a drawing it would be:

What happens with the configurations that I had made in Test after regenerating the instance? They get lost, The Test instance is a copy of what you had in Production.

What is the test instance for? You can use it to test configurations, server actions, etc., that after being fruitful you must do in Production.

What configuration will I have in Test when regenerating the instance? You are going to have the last support made of Production. If you require something more current, you expressly request that a backup is made at that time to Sysadmin.

And what is the difference between "regenerate" and "update"? 

The Regenerate builds the instance again and loads a recent database. If the image is built direct from gitlab it only pulls it. The Update only pulls the repos (there is no rebuilding process) or puts the commits that you specify and updates the database (-u all, it does not load a new database). It is rather to test changes quickly before Regenerate.

cons in the lists of instancess

In the list of instances generated, for the case of Updates, two types of icons appear. The rocket icon refers to the fact that this instance was passed to production at some point. The check mark icon means that this instance is already perfectly displayed in Update but has not passed (or never happened) to production.

LThe Production instance is the central axis of all the work in the implementation. Everything that you agree with the client and that you have verified that it works, you go to Production and configure it. And immediately that you have an instance of Production with new configurations you have to make sure that you take it to Test to always try things and to experiment on the last thing that you agreed with the client: Alpha and Omega.

And when the Sysadmin generates a new instance of Production what happens? Sysadmin not touch the configuration, it only displays the changes at the code level or executes scripts. Once Production is ready and a backup is generated with that configuration, you will have the possibility to generate a copy in Test or Updates and be able to follow your tests with the last thing that was agreed.

Practical example:

• Load an initial inventory in Production:

• • I DO NOT validate it, first I generate a Test instance.

  • Then I validate the inventory adjustment and review the accounting in Test.

  • If there are disagreements, I correct it in Test until everything is OK.

  • Then I go to Production and apply the necessary corrections agreed in Test.

  • Finally, the inventory adjustment in Production was validated.

  
  

But now I want to test what is in Updates in Test, what do I do? You have two options:

1. You can try Updates in the same instance, but you will not have the settings that you have made in Production. You would only try the most recent changes approved in the code.

2. You ask for a pass to Production of what is in Updates, and then you generate an instance of Test. With that, you will have the latest version of the code with the settings you had in Production.

f you are a developer and you came to this part of reading safe and sound, this is for you. The instance of Develop is the only one that a person with a developer profile manipulates, in the case that the project team is composed of a leader plus the developer (s). 

Develop is the only one of the four deities that can be created at the discretion and is removed only if the developer wishes. In other words, the developer can create an instance that will be a copy of Production, Updates or Test even with Branch not yet approved for  Merge.

The instances of Develop are not suitable for the Project Leader to try something with the client. It is more for internal use and discussion among the project team.