|
|
|
|
|
by potamic
496 days ago
|
|
I'm not sure that's completely what they are saying. Under the use cases section, they do acknowledge that workspaces can be used for test environments. I think what they are saying is to align workspaces to your architecture and team structure. If you have the same team managing their components across environments, workspaces could be a fine way of doing it. The problem with manually composing your environments is that you can lose parity across them. Over time it can be hard to point to what is the source of truth for your architecture. Like, this environment invokes these modules, but this other environment does not! Which is the correct one? But when systems cross team boundaries then they will diverge by design, using workspaces for such cases may not be a good idea. |
|