On VTEX IO, workspaces function similarly to Git branches with automatic rebase. Your work in development and production workspaces is always based on what's in the master workspace.
Below is an example to illustrate the behavior of apps when performing operations on workspaces.
Imagine there is a VTEX account with four identical workspaces:
master:appA@1.xprod1:appA@1.xprod2:appA@1.xdev1:appA@1.x
The following sections present scenarios based on this example. Check what happens when you:
Install an app on development or production
Installing an app on a development or production workspace does not affect other workspaces.
Considering the given example, imagine the following actions:
- Installing
appA@2.xonprod1 - Installing
appC@2.xonprod2 - Installing
appC@3.xondev1
This would be the result:
master:appA@1.xprod1:appA@2.xprod2:appA@1.x,appC@2.xdev1:appA@1.x,appC@3.x
Install an app on master
When you install an app on the master workspace, it is installed on every workspace that does not have this app installed. If a workspace has the same app installed with another major version, the app version on this workspace is unchanged.
Considering the given example, imagine the following action:
- Installing
appB@0.xonmaster
This would be the result:
master:appA@1.x,appB@0.xprod1:appA@2.x,appB@0.xprod2:appA@1.x,appB@0.x,appC@2.xdev1:appA@1.x,appB@0.x,appC@3.x
Promote a workspace
When a production workspace is promoted to master, all the other workspaces are updated to reflect the changes seen in the promoted workspace.
Considering the given example, after promoting prod2 to master, this is the result:
master:appA@1.x,appB@0.x,appC@2.xprod1:appA@2.x,appB@0.x,appC@2.xdev1:appA@1.x,appB@0.x,appC@3.x
After promoting a workspace, the name of the promoted workspace will not appear in the list of workspaces, since it became the new master workspace.