-
Notifications
You must be signed in to change notification settings - Fork 5
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
♻ Time de QA & codeowners ! #9
Comments
@Canato esses |
@rodrigondec Mas tentando explicar: Cada parte do código pode ter seus owners. E isso faz com que se a gente tem uma área sensível do aplicativo as pessoas não pode sair adicionando. Hoje por exemplo, como nosso repositório não está configurado com essas proteções, se alguém quiser vir aqui abrir um PR e criar uma conta pra mãe dele ela aceitar ele vai inserir código. Com o CODEOWNER nós podemos falar quem são as pessoas que precisam aceitar. Se tiver uma área sensível (em alguns apps pagamento) por exemplo cadastro. que meche com dados pessoas das pessoas. Não queremos que alguém insira algum tipo de receptor e consigo mudar nossa API/Url ou que possa de alguma forma extrair os dados. Por isso temos pessoas que são responsáveis (normalmente quem montou essa parte) para ter certeza do tipo de código que está sendo adicionado. No caso dos QAs, nós não queremos que ninguém insira código que possa quebrar nossa aplicação ou que possa trazer vários bugs. Então nós vamos testar esse código. Mas alguém poderia dar merge no código antes de alguém testar, pra isso adicionamos a necessidade dos testers de dar um approval no código. Assim temos certeza que alguém do time de teste testou e se responsabiliza pela qualidade do código |
Responderei aos trechos separadamente.
Estava falando apenas do contexto do github mesmo.
Não, temos proteção em todas as branchs e repositórios de permissões. PR's só podem ser mergeados com aprovação na revisão de pessoas com o role
Sim, justamente essa configuração que fizemos na proteção das branchs. Vou mandar aqui uma prints para poder ilustar. As pessoas que podem aceitar os PR's podem ser vistas nos membros da organização que possuam o role
Sim, concordo. Para isso teremos os responsáveis e tech leads de cada tecnologia/setor/time. O approval deles será o filtro de qualidade (além dos requisitos formulados no issue #2, no idvogados/idvogados-api#2). Posteriormente se for o caso podemos criar uma equipe específica para QA. |
Perfeito, então já temos isso. Importante então seguirmos o nível de qualidade. Esperarei então o time ser criado. Obrigado! |
@Canato , vc sabe se existem mais QAs a par do projeto? |
@pictos there is some in the QA channel |
Time de QA
CodeOwner
CODEOWNERS
Opção 1:
Caso o time seja criado, o arquivo terá a descrição:
Opção 2:
Caso o time não seja criado ( talvez precise pagar?), o arquivo terá a descrição:
The text was updated successfully, but these errors were encountered: