VTEX IO: qual o motivo do meu workspace mudar após outro workspace ser promovido para master?

Oi pessoal,
Boa noite.

Alguém já evidenciou o seguinte cenário:

Você cria um Workspace da Master da loja e daí você abre para validar suas alterações dentro deste workspace.

De repente, a loja de Produção começa a puxar a mesma versão do Workspace sem ter sido promovido para master.

Com isso, a versão antiga desaparece e fica ambos os ambientes com a mesma versão de alterações.

O correto seria ficar Master (versão antiga) e Workspace (versão nova) até promovê-lo, correto?

Vocês saberiam dizer o motivo disso acontecer?

PS.: não consegui prints para enviar neste tópico.

Se conseguirem ajudar ou se já viram algo, ficaria grato em saber como foi solucionado.

Abs,
Estevão.

No VTEX IO, workspaces funcionam como branches do git com rebase automático. A ideia é que você sempre esteja trabalhando em relação ao que está disponível em produção (master).

E é isso que provavelmente você está observando como efeito colateral do comando vtex workspace promote. Quando um workspace de produção é promovido, todos demais são atualizados para refletir as mudanças vistas no workspace promovido.

No contexto de temas e componentes de loja, imagine a seguinte situação:

  • Você cria um workspace de produção
  • Altera o título da página inicial
  • Aguarda alguns dias e decide promover o workspace para master

Imagino que no final desse período, você não queira que as mudanças feitas diretamente em master desapareçam. Em outras palavras, você não quer restaurar um backup do workspace master de dias atrás (quando o novo workspace foi criado) e alterar o título da página inicial nesse backup… Você quer que o título da página inicial seja alterado no no estado atual do workspace master.

Essa mesma lógica se aplica a apps. Se durante o ciclo de vida do workspace de produção um apps foi atualizado (nova major) no master, você não quer que uma versão desatualizada seja instalada no lugar ao promover sua simples alteração no título da página inicial.

Existem discussões válidas que podem ser feitas sobre o custo/benefício dessa estratégia de “rebase automático”… Mas essa é a forma que funciona hoje. Por isso, recomendo:

  1. Monitorar atentamente toda vez que um workspace de produção for promovido
  2. Alertar o time de desenvolvimento sobre esse comportamento, para que possam estar cientes dos possíveis impactos
1 Like

Opa @georgebrindeiro de boas?

Só para ver se eu entendi: isso vai acontecer mesmo sem eu ter promovido o Workspace com as alterações atuais? Ou seja, simplesmente por conta desse WS ser de PRD ele vai ter um rebase automático, portanto, sendo um comportamento padrão VTEX?

Só pra descrever um pouco mais este contexto, usamos o Workspace como se fosse um “estacionamento” de possíveis alterações que poderão subir ou não dependo da regra de negócio do cliente e etc, porém tendo origem de Produção por questões de puxar um backend com versões de APIs diferentes do outro ambiente QAS que temos separado aqui.

Em outras palavras: eu quero testar alterações que irão para produção dentro deste ambiente de produção, sem estar em produção de fato. rsrs

Você vê alguma possibilidade de em algum momento o Workspace (mesmo tendo origem da Master) servir como esse contexto de “estacionar alterações” ou isso nunca será possível?

Valeu pelo esclarecimento!

Talvez fique mais claro com um exemplo. Imagina que você tem 4 workspaces idênticos:

  • master: appA@1.x
  • prod1: appA@1.x
  • prod2: appA@1.x
  • prod3: appA@1.x

Impacto da instalação de apps em diferentes workspaces

Se fizer essas ações, em sequência:

  • Instalar appB@0.x em master
  • Instalar appA@2.x em prod1
  • Instalar appC@2.x em prod2
  • Instalar appC@3.x em prod3

Essas serão as apps em cada workspace ao final:

  • 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

Após ser instalado em master, appB@0.x foi automaticamente instalado em todos workspaces de produção. É daí que vem a mensagem da CLI:

warn: Using master workspace. I hope you know what you're doing. 💥

:bulb: Conclusão: Instalar apps em master afeta outros workspaces, levando à instalação imediata desses apps nos demais workspaces de produção. Instalar apps em outros workspaces de produção não tem esse efeito imediato.

Impacto da promoção de um workspace em outros workspaces

Após as ações descritas na seção anterior, caso decida promover prod3 para master, essas serão as apps em cada 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

Após promover prod3, esse workspace virou master e o que estava lá antes desapareceu.

Note ainda que appC@3.x foi instalado em prod1, que ainda não tinha esse app, mas nada aconteceu com prod2, que tinha uma versão anterior instalada.

:bulb: Conclusão: Promover um workspace de produção afeta outros workspaces, levando à instalação de apps presentes no workspace promovido que não estejam presentes nos demais workspaces de produção. Caso um app já esteja presente em um workspace, sua versão é preservada.

1 Like

É possível discutir e evoluir esse critério, mas essa não é uma questão que está sendo tratada no momento.

1 Like

Fala @georgebrindeiro eu até entendi a explicação. Obrigado pelos detalhes e exemplos de cenários.

O que nós estamos achando estranho é que este Workspace do nosso cenário aqui não tinha sido promovido ainda para master.

Com estas informações que você passou e recapitulando com o time, surgiu a seguinte dúvida:

Em qual contexto o Workspace pode afetar a Master se ele ainda não foi promovido, uma vez que apenas o que fizemos foi: instalar uma nova versão do store framework no Workspace de PRD antes de promovê-lo, apenas para validar alterações. Entretanto, (sem motivo claro para nós) ele atualizou o store theme master (ou seja, sem a gente rodar o promote ou qualquer outro comando).

Isso tem explicação?

(me desculpa se você deu a resposta de alguma forma, mas é que ainda ficamos na dúvida aqui por não ter usado o comando para promover o WS).

Obrigado pelo tempo aí!

Não sei dizer com certeza, precisaríamos de um ticket completo para o suporte VTEX, uma forma de reproduzir o mesmo comportamento que vocês observaram para dizer com propriedade o que de fato aconteceu.

Uma coisa que pode afetar todo mundo ao mesmo tempo é mudar a Edition da conta. Esse é um conjunto de apps que vem “pré-instalado” e que não pode ser setado por workspace… É uma propriedade da conta, não do workspace.

Ah sim! Então beleza.

Abrimos aqui #781506 para entendermos essa questão.

Valeu pelo help por enquanto.

Abs,
Estevão.