Aplicar desenvolvimento baseado em troncos
Com os teus scripts de treino e definições de funções no controlo de versão, o próximo desafio é protegê-los. Dois cientistas de dados que editam o mesmo ficheiro no main branch ao mesmo tempo podem criar conflitos e, mais importante ainda, falhas acidentais no código das quais outros dependem. O desenvolvimento baseado em troncos oferece à sua equipa uma forma estruturada de evoluir o modelo mantendo o código de produção estável.
Mantenha a ramificação partilhada estável
No desenvolvimento baseado em troncos, os contribuintes integram alterações num único ramo partilhado, tipicamente main. As equipas mantêm esta filial saudável para que continue a ser um ponto de partida fiável para novos trabalhos.
No projeto Proseware, a equipa exige que as alterações cheguem a main através de pull requests. Esta política dá aos revisores e verificações automatizadas a oportunidade de avaliar cada alteração antes da integração.
Ramos de funcionalidade de curta duração
Quando um cientista de dados quer experimentar uma nova funcionalidade — por exemplo, adicionar uma variável de IMC ao modelo de diabetes — cria um ramo de curta duração a partir de main. O trabalho acontece lá, isolado do código dos outros. Quando a experiência está pronta para ser revista, o cientista de dados abre um pull request.
Ramos de curta duração reduzem a probabilidade de divergir para longe de main, o que facilita a fusão e reduz os conflitos.
Pedidos de pull, revisões e verificações necessárias
Um pull request faz duas coisas: mostra aos revisores exatamente o que mudou e torna-se o ponto de ativação para verificações automáticas. Os revisores podem colocar questões, pedir alterações ou aprovar o trabalho. A automação decorre em paralelo com a revisão.
Regras de proteção de ramificações ou conjuntos de regras podem aplicar este processo. Dependendo das definições do repositório, uma regra sobre main pode:
- Restringir empurrões diretos
- Exija um número mínimo de aprovações antes da fusão
- Exigir verificações de estado específicas para passar antes da fusão
Os fluxos de trabalho do GitHub Actions podem produzir as verificações que uma regra exige. Exploras estas verificações na unidade seguinte.
Nota
As regras de proteção de branches e os conjuntos de regras são definições de repositório do GitHub, não do GitHub Actions. O fluxo de trabalho define o que é executado. A regra de proteção decide se uma fusão é permitida com base no resultado.
Sugestão
Considere uma mudança de modelo que requer várias semanas de trabalho. Como é que se pode dividir isso em alterações mais pequenas que se fundem em main sem deixar um ramo de longa duração?