scieloorg / scielo.org

Website institucional da Rede SciELO
MIT License
1 stars 7 forks source link

Paratiuid tk prevencao erros blog #99

Closed paratiuid closed 5 years ago

paratiuid commented 5 years ago

O que esse PR faz?

Atualizao o arquivo contants.php

Onde a revisão poderia começar?

Esse pull request é uma continuação do pull request: https://github.com/scieloorg/scielo.org/pull/91

Como este poderia ser testado manualmente?

@joffilyfe mencionou que não estava conseguindo rodar o sistema. Acredito que com essa atualização o sistema rode corretamente.

Algum cenário de contexto que queira dar?

Como trabalhamos com ambiente local diferente do ambiente de produção, acabei não subindo este arquivo. Acredito que agora, com essa atualização, o sistema rodará corretamente.

Screenshots

não aplicável

Quais são tickets relevantes?

ticket:

90

e pull request: https://github.com/scieloorg/scielo.org/pull/91

Referências

Apenas comparei meu arquivo constants.php local com o que estava no servidor, e vi que havia essa diferença. Adicionei as novas constantes.

paratiuid commented 5 years ago

@joffilyfe

Especificamente esse ticket, foi recuperado do tempo de desenvolvimento. Onde o sistema ainda não havia sido publicado. Não haviam tickets para os pedidos.

O que ocorreu foi que por uma falha nossa, misturamos duas atividades na mesma branch.

Quando trouxemos essa branch para o novo repositório, a rotina de teste passou, e pensamos que a parte do open access citada já havia sido incorporada ao sistema.

A gente vem tentando melhorar o nosso fluxo, como ja falamos na semana passada. Ainda esta nebuloso para nos, o ciclo de publicacao.

Aqui trabalhamos com GitFlow, ou seja com as branchs develop, master, features, releases e hotfixes. Estamos desenhando um fluxo que e mais ou menos assim, porem precisamos de uma sincronia legal com vocês.

1) Para cada ticket aberto, é gerado uma "feature" (que é derivada a partir da develop). 2) Concluído o desenvolvimento do tk, solicitamos a PR a partir da feature (sem fechá-la, pois isso faria com ela tivesse o merge com a develop). 3) Aprovada a PR, fechamos a feature e ela é incorporada na develop. 4) Quando houver a próxima publicação do lado de vocês (após o ciclo de homolog), geramos aqui uma release em que fazemos um pull da master de vocês (ou seja, a release é gerada a partir da nossa develop e vai incorporar as alterações da master de vocês - que eventualmente vocês tenham feito). Feita a sincronia a release é fechada. O que significa que ela faz um merge com a nossa master - que deve refletir a produção de vocês - e também com a develop que servirá de base para as novas features.

Tudo bem assim? Se sim, é importantíssimo sabermos quando um ticket ou quando vocês publicam a homolog em prod.

Sugiro que na próxima reunião falemos sobre o assunto.

joffilyfe commented 5 years ago

@paratiuid você poderia me passar as instruções para testar este PR? Eu preciso saber como reproduzir o bug reportado pelo @alexxxmendonca e como o código enviado ataca o problema.

joffilyfe commented 5 years ago

@paratiuid você poderia me passar as instruções para testar este PR? Eu preciso saber como reproduzir o bug reportado pelo @alexxxmendonca e como o código enviado ataca o problema.

ping @paratiuid

paratiuid commented 5 years ago

O cenário de teste que utilizamos foi alterar o valor de entrada do arquivo constants.php para ocasionar o erro.

Você pode alterar os valores das linhas para simular:

jamilatta commented 5 years ago

Em conversa com a @paratiuid decidimos que iremos fechar esse PR e a @paratiuid enviará outro contendo alterações mais atômicas.