Sou desenvolvedor de software em uma equipe ágil bastante grande (temos oito desenvolvedores ativamente fazendo alterações em um único repositório de código). A cada duas semanas, lançamos uma nova versão do nosso software para produção. Aqui está o nosso fluxo de trabalho atual:
- Ao iniciar uma nova tarefa, os desenvolvedores criam um "ramo de recurso" fora do ramo de desenvolvimento principal (usamos git ) e resolvemos esse novo ramo
- Depois que um desenvolvedor termina o trabalho em sua tarefa, ele mescla sua ramificação de recursos novamente na ramificação de desenvolvimento
- O desenvolvedor mescla a ramificação de desenvolvimento na ramificação de controle de qualidade.
- Uma construção é acionada fora da ramificação do controle de qualidade. A saída dessa compilação é implantada em nosso ambiente de controle de qualidade para permitir que os testadores iniciem seus testes.
É bastante comum que nossos testadores encontrem problemas com esses novos recursos que foram mesclados ao ramo de controle de qualidade. Isso significa que, a qualquer momento, o ambiente de controle de qualidade provavelmente contém vários novos recursos - alguns testados, livres de erros e outros quebrados. Isso dificulta a liberação porque é raro que a construção do controle de qualidade esteja pronta para produção.
Para atenuar isso, tentamos iniciar um "congelamento do controle de qualidade", o que significa que os desenvolvedores não mesclam nosso ramo de desenvolvimento ao ramo de controle de qualidade alguns dias antes do lançamento. As correções de bugs no ambiente de controle de qualidade são feitas diretamente na filial de controle de qualidade e mescladas na filial de desenvolvimento. Teoricamente, isso mantém os recursos novos e quebrados fora do controle de qualidade, enquanto ainda nos permite corrigir problemas que já estão no controle de qualidade.
Embora esse conceito de "congelamento do controle de qualidade" tenha sido parcialmente bem-sucedido, é difícil coordenar e as pessoas geralmente ficam confusas sobre a possibilidade de mesclar-se ao controle de qualidade. Também tem sido difícil definir um prazo de "congelamento do controle de qualidade" - todo mundo gosta da ideia de um espaço para respirar entre o congelamento e o lançamento, mas, na prática, eles preferem ter seu recurso no próximo lançamento a respeitar o prazo.
Existe uma maneira melhor de garantir que tenhamos uma compilação limpa para nossos lançamentos a cada duas semanas?
fonte
Respostas:
Existem alguns problemas que estão causando problemas que estão ocorrendo.
O primeiro é o ramo de controle de qualidade de longa duração. Ter uma ramificação de longa duração que seja paralela à linha principal de desenvolvimento pode ser uma fonte de confusão, pois há esforços diferentes que precisam ser replicados na filial de QA e na linha principal. Isso significa que você está fazendo check-in de correções na filial do controle de qualidade que precisam ser mescladas com a linha principal (nada mal) ou está fazendo check-in na linha principal que é mesclada na filial do controle de qualidade (uma fonte de possíveis erros) .
O outro problema com a ramificação paralela de longa execução é que é possível que os arquivos fiquem perpetuamente fora de sincronia. Uma correção de código que nunca é mesclada novamente ou uma configuração necessária para compilações de produção que nunca é testada e faz parte da linha principal de desenvolvimento.
Em seguida, você tem papéis que estão sendo afetados. Isso significa que a função de empacotamento (mais sobre isso posteriormente) não está ficando suficientemente isolada.
No modelo git-flow , o ramo de liberação é ramificado do desenvolvimento ( não o desenvolvimento mesclado ao QA) e todas as correções são verificadas no ramo de liberação e depois mescladas de volta ao ramo de desenvolvimento.
Parte da filosofia da ramificação pode ser encontrada em Estratégias avançadas de ramificação do SCM (considero uma excelente leitura). Isso se concentra nos papéis que cada filial pode assumir. A ramificação de liberação assume a função de compactação.
Deve-se considerar seriamente aplicar a totalidade do fluxo git no local. Isso não está muito longe do que está sendo feito atualmente e coloca alguma disciplina e consistência no que cada ramo significa e como cada ramo interage com os outros.
fonte
O problema parece ser que você tem uma única ramificação de controle de qualidade.
Para cada versão, faça uma ramificação de controle de qualidade separada do tronco / mestre de desenvolvimento primário. Em seguida, mesclar apenas correções de bugs para recursos nesse ramo - nunca novos recursos. Faça o controle de qualidade desse ramo.
Dessa forma, o "congelamento" é bastante evidente - está no nome do ramo. Você poderia usar algo como, eu não sei
release/26/10/2015
. Então é óbvio que ninguém deve se unir a novos recursos depois disso.É especialmente útil se você nem bifurcar o galho até o congelamento. As pessoas podem se unir para dominar a qualquer momento, apenas não fará parte desta versão se não for feito a tempo de ser testado.
Não tem um único ramo de controle de qualidade de longa duração, isso está apenas implorando por problemas. Bifurque-se do ramo de desenvolvimento principal de cada release e controle de qualidade desse ramo.
fonte
Você está um pouco mapeado para o modelo de ramificação Development-MAIN-Production, visto abaixo. Diz-se que a área acima de MAIN é a área de desenvolvimento. A área abaixo de PRINCIPAL é a área de produção.
Destaques deste modelo que considero relevantes para você:
Eu suspeito que você tenha problemas porque:
fonte
Pelo que entendi a pergunta, você tem dois problemas. (a) recursos quebrados estão sendo mesclados com os bons recursos que você deseja liberar; (b) você deseja liberar os bons recursos enquanto retém os quebrados. Como restrição para possíveis soluções, presumo que você deseja que seu teste de controle de qualidade final / oficial ocorra em uma ramificação integrada que contenha todos os recursos previstos para a próxima versão.
Independentemente do seu modelo de ramificação SCM, sugiro que você tente um ou ambos dos seguintes procedimentos:
fonte
Uma solução muito simples que eu já vi trabalhar em uma equipe um pouco maior que a sua é fazer com que todos trabalhem e implantem em uma única ramificação.
Você diz que a equipe é ágil, mas não está claro se você está trabalhando em sprints (por exemplo, Scrum) ou em uma abordagem de fluxo mais contínuo (por exemplo, Kanban). Supondo que você esteja fazendo sprints, o objetivo da equipe é liberar o código no final de cada sprint, para sua liberação quinzenal. Não há confusão quanto à possibilidade de um recurso quebrar outro, pois todos foram desenvolvidos juntos. Os testadores podem ter acesso aos recursos em pedaços menores, pois a sobrecarga dos desenvolvedores para entregar a eles é menor. E você realmente não precisa de um QA-Freeze; todo mundo sabe quando o final do sprint está e não deve continuar o trabalho que não pode terminar ou sair em um estado implementável (ou seja, desativado).
Obviamente, existem prós e contras em qualquer abordagem. Apresento isso como uma opção, não necessariamente o 'melhor caminho'.
fonte
A razão pela qual você está enfrentando esses problemas é porque seu código liberado para o controle de qualidade não é de qualidade suficiente (e é alguém?), Então você precisa começar a obter um release melhor para o controle de qualidade, para que eles não precisem receber bigfixes com tanta frequência. a maneira mais simples de fazer isso é introduzir um ramo intermediário para o qual você libera (vamos chamá-lo de teste). Isso ainda está sob a missão de desenvolvimento, mas permite que os desenvolvedores avancem para continuar trabalhando, além de ter uma ramificação integrada que deve ter qualidade suficiente para ser enviada ao controle de qualidade.
O teste de integração pode ser realizado neste ramo, a fim de encontrar os bugs que o controle de qualidade está encontrando no momento, os erros podem ser corrigidos no ramo original e depois mesclados novamente, e novamente até que seja certo ou que os erros possam ser corrigidos diretamente nesse ramo (eu recomendo antigo). Depois de passar por uma carga de testes básicos, ele pode ser enviado ao controle de qualidade para os 'dedos pegajosos do usuário e o que eles fizeram o quê?' teste.
Portanto, essa abordagem foi projetada para proteger a ramificação do controle de qualidade de recursos de desenvolvimento interrompidos - seja porque o recurso não foi codificado o suficiente ou se houve problemas inesperados de integração, não importa. Somente ramificações de desenvolvimento que passam no teste de integração são promovidas ao controle de qualidade.
fonte