In VTEX IO, workspaces work like git branches with automatic rebase. The idea is that you’re always working relative to what’s available in production (master).
And that’s probably what you’re observing as a side effect of the vtex workspace promote command. When a production workspace is promoted, all others are updated to reflect the changes seen in the promoted workspace.
In the context of store themes and components, imagine the following scenario:
You create a production workspace
You change the title of the home page
You wait a few days and decide to promote the workspace to master
I imagine that at the end of that period, you wouldn’t want changes made directly in master to disappear. In other words, you don’t want to restore a backup of the master workspace from days ago (when the new workspace was created) and change the home page title in that backup… You want the home page title to be changed in the current state of the master workspace.
The same logic applies to apps. If during the lifecycle of the production workspace an app was updated (new major) in master, you don’t want an outdated version to be installed in its place when you promote your simple home page title change.
There are valid discussions to be had about the cost/benefit of this “automatic rebase” strategy… But this is how it works today. For that reason, I recommend:
Closely monitoring every time a production workspace is promoted
Alerting the development team about this behavior, so they can be aware of the possible impacts
Just to make sure I understood: is this going to happen even without me having promoted the Workspace with the current changes? In other words, simply because this WS is from PRD, it will have an automatic rebase — making it a standard VTEX behavior?
Just to give a bit more context: we use the Workspace as a kind of “parking lot” for possible changes that may or may not go live depending on the client’s business rules, etc. — but originating from Production, due to the need to pull a backend with different API versions from the other QAS environment we have set up separately.
In other words: I want to test changes that will eventually go to production, within this production environment, without actually being in production. lol
Do you see any possibility that at some point the Workspace (even when originating from Master) could serve as this “parking lot” context, or will that never be possible?
Maybe it will be clearer with an example. Imagine you have 4 identical workspaces:
master: appA@1.x
prod1: appA@1.x
prod2: appA@1.x
prod3: appA@1.x
Impact of installing apps in different workspaces
If you perform these actions, in sequence:
Install appB@0.x in master
Install appA@2.x in prod1
Install appC@2.x in prod2
Install appC@3.x in prod3
These will be the apps in each workspace at the end:
master: appA@1.x, appB@0.x
prod1: appA@2.x, appB@0.x
prod2: appA@1.x, appB@0.x, appC@2.x
prod3: appA@1.x, appB@0.x, appC@3.x
After being installed in master, appB@0.x was automatically installed in all production workspaces. That’s where the CLI message comes from:
warn: Using master workspace. I hope you know what you're doing. đź’Ą
Conclusion: Installing apps in master affects other workspaces, leading to the immediate installation of those apps in all other production workspaces. Installing apps in other production workspaces does not have this immediate effect.
Impact of promoting a workspace on other workspaces
After the actions described in the previous section, if you decide to promote prod3 to master, these will be the apps in each workspace:
master: appA@1.x, appB@0.x, appC@3.x
prod1: appA@2.x, appB@0.x, appC@3.x
prod2: appA@1.x, appB@0.x, appC@2.x
After promoting prod3, that workspace became master and what was there before is gone.
Also note that appC@3.x was installed in prod1, which didn’t have that app yet, but nothing happened to prod2, which had an earlier version installed.
Conclusion: Promoting a production workspace affects other workspaces, leading to the installation of apps present in the promoted workspace that are not present in the other production workspaces. If an app is already present in a workspace, its version is preserved.
Hey @georgebrindeiro, I actually understood the explanation. Thanks for the details and scenario examples.
What we’re finding strange is that this Workspace in our scenario here had not been promoted to master yet.
With the information you provided and after recapping with the team, the following question came up:
In what context can a Workspace affect Master if it hasn’t been promoted yet, given that all we did was: install a new version of the store framework in the PRD Workspace before promoting it, just to validate changes. However, (for no clear reason to us) it updated the master store theme (i.e., without us running the promote command or any other command).
Is there an explanation for that?
(Sorry if you answered this in some way already, but we’re still confused here because we never used the command to promote the WS.)
I can’t say for certain — we’d need a complete ticket for VTEX support, a way to reproduce the same behavior you observed, in order to properly say what actually happened.
One thing that can affect everyone at the same time is changing the account’s Edition. This is a set of apps that comes “pre-installed” and cannot be set per workspace — it’s a property of the account, not of the workspace.
Conclusion: Installing apps in