New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A atualização do brasil.gov.portal não roda todos os upgrades steps: deveríamos deixar de escondê-los e mostrar no painel de controle ou continuar com a atualização deles no upgrade do brasil.gov.portal? #325

Open
hvelarde opened this Issue Nov 24, 2016 · 7 comments

Comments

Projects
None yet
2 participants
@hvelarde
Member

hvelarde commented Nov 24, 2016

Pelo que testamos ao rodar a atualização do brasil.gov.portal os seguintes pacotes ficam sem se atualizar:

  • brasil.gov.barra
  • brasil.gov.portlets

esses podem se atualizar diretamente no painel de controle, mas tem outros que só ficam visíveis no portal_setup:

  • brasil.gov.tiles
  • plone.app.blocks
  • plone.app.tiles
@idgserpro

This comment has been minimized.

Member

idgserpro commented Nov 24, 2016

Estou revendo o issue que fez essa implementação de pacotes de terceiros em #218 e cheguei à conclusão que o correto teria sido adicionar uma documentação sobre como atualizar entre versões no portal_setup e não ter feito a implementação disso em primeiro lugar.

Ao rever "se o brasil.gov.portal decidiu atualizar todas as dependências, ele passa a ter a responsabilidade de garantir a consistência de todas as instalações" é exatamente o que estamos enfrentando agora com esse relato aberto.

A observação de plone.app.blocks ou plone.app.tiles por exemplo a gente tinha previsto em "como agir com dependências de dependências" (onde ficou definido que deixaríamos como está) e sobre ter que ainda acessar o portal_setup nesse contexto também. Tivemos inclusive efeitos colaterais (1 e 2) que nem tínhamos previsto e que, se os upgradeSteps tivessem sido aplicados manualmente, não aconteceriam. Em resumo: não estamos querendo apontar "dedos" nem nada, mas apenas reafirmar que, exatamente por esse tipo de problema não ter uma solução muito "elegante" de se resolver, que éramos contra essa implementação. Achamos que o esforço dispendido pelo benefício fornecido não vale a pena.

Quando esse relato de executar upgrades dos outros foi atendido, o mauritis ainda não tinha efetuado as melhorias no GenericSetup de apenas mostrar os profiles que possuem atualização pendente: com essa melhoria que ele fez achamos ainda mais irrelevante e contraproducente continuarmos seguindo por esse caminho de atualizar produtos de terceiros. Não reclamamos do que foi feito, foi interessante, foi uma prova de conceito que foi útil para definirmos como seguir pra frente.

De qualquer forma, não quer dizer que não temos proposta de solução, nós temos: votamos por melhorar a documentação de atualização entre releases e usar o que está pronto no portal_setup: é o processo tradicional de usar upgradeSteps, a documentação será a mesma para todo novo release, está testado e não tenho o overhead de:

  • para cada novo release, ficar vasculhando qual dependência e qual dependência da dependência tem o upgradeStep (correndo o risco de esquecer alguma);
  • escrever código para atualizar essa dependência (com risco de efeitos colaterais);
  • escrever teste pro código de atualização da dependência;
  • teste manual exploratório da atualização da dependência.

Achamos a intenção de simplificar esse processo louvável, mas o esforço não vale a pena e achamos o direcionamento incorreto. Se há o interesse de tornar mais "intuitivo" qualquer um desses processos (ou "evitar ZMI"), achamos que isso deveria ser feito pelo Plone e não pelo IDG, e é exatamente por esse motivo que questões desse tipo a gente sempre leva pra lá, como por exemplo o fato de ficarmos escondendo profiles.

@hvelarde

This comment has been minimized.

Member

hvelarde commented Nov 25, 2016

eu não estou muito por dentro disso ai, mas continuo acreditando que seria interessante ter uma atualização centralizada e única no IDGB.

a vantagem é que com o tempo isso vai ficar mais estável e fácil de administrar, pois na verdade a ordem em que se rodam os upgrade steps não deveriam afetar na maioria dos casos.

de qualquer jeito, isso pode ser discutido com mais membros da comunidade para chegar em um consenso.

@idgserpro

This comment has been minimized.

Member

idgserpro commented Nov 25, 2016

mas continuo acreditando que seria interessante ter uma atualização centralizada e única no IDGB.

Nós também achamos interessante, só achamos que o esforço pra se fazer não compensa quando basta adicionar uma documentação que será a mesma para todos os release, "entre no portal_setup e os profiles que aparecerem pra atualizar você atualiza" depois da melhoria que o maurits fez.

Se quiser seguir por esse caminho, a gente pode revisar os seus PRs assim como você faz com os nossos. Fico aqui nosso agradecimento aliás. :)

@idgserpro

This comment has been minimized.

Member

idgserpro commented Nov 30, 2016

Se for seguir por esse caminho, não esquecer do relato #239

@idgserpro

This comment has been minimized.

Member

idgserpro commented Jan 11, 2017

Acho que o caminho ideal seria:

  • Parar de esconder pacotes que hoje são escondidos no brasil.gov.portal (se for seguir por esse caminho, #296 pode ser fechado);
  • A documentação de atualização de release simplesmente informar "acesse o Painel de Controle do portal, opção Complementos, e execute a atualização de todos os pacotes que pedirem atualização.";

Dessa forma, continua centralizado, é a tela que o usuário já está acostumado, não precisamos fazer mais código e segue o padrão Plone.

Enquanto isso não é feito, ficamos com a documentação de forma temporária criada em #332.

@idgserpro idgserpro changed the title from A atualização do brasil.gov.portal não roda todos os upgrades steps to A atualização do brasil.gov.portal não roda todos os upgrades steps: deveríamos deixar de escondê-los e mostrar no painel de controle ou continuar com a atualização deles no upgrade do brasil.gov.portal? Jan 11, 2017

@hvelarde

This comment has been minimized.

Member

hvelarde commented Jan 11, 2017

lembrem que Plone, por padrão, também oculta alguns profiles e toma conta da atualização de algumas dependências.

@idgserpro

This comment has been minimized.

Member

idgserpro commented Jan 12, 2017

Sim, mas o próprio Plone toma conta disso na opção de atualizar quando você entra na ZMI.

Se tiver alguma situação, entre releases, do IDG, de uma dependência que não aparece no painel de controle mas tem upgradeStep, precisamos tratar isso em brasil.gov.portal: mas o interesse agora é que isso seja exceção, e não a regra para evitar retrabalho e os erros que tivemos com esse tipo de abordagem.

De qualquer forma, isso precisa ser documentado para que em todo release seja verificado, então criamos o lembrete em plonegovbr/portalpadrao.release#20

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment