Como podemos incluir apenas recursos prontos para serem lançados em nossos lançamentos de produção a cada duas semanas?

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?

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.

A função de empacotamento geralmente é confundida com as funções de acumulação ou, mais comumente, de linha principal. Uma vez que o desenvolvimento e a manutenção pretendidos tenham sido realizados e qualquer acumulação tenha sido feita, é hora de preparar o código para liberação. Esse esforço pode não ser trivial, exigindo uma equipe de engenheiros de versão e correções adicionais além daquelas já executadas. A política em uma filial de embalagem é significativamente diferente daquela em uma filial de manutenção, como sugere a função de embalagem, apenas as alterações necessárias para tornar o produto liberável devem ser abordadas.

• Ramificação do ponto de desenvolvimento até a ramificação de lançamento. O ramo de lançamento do qual o QA cria obtém um ramo e não é mesclado no desenvolvimento.
  • Se você quiser seguir esse caminho, com nomes e ganchos consistentes, é possível impedir que uma mesclagem seja feita em uma ramificação de liberação.
• Corrija tudo o que precisa ser corrigido no ramo de lançamento e mescle essas alterações de volta à linha principal.
• No final do esforço de lançamento, mescle o ramo de lançamento no ramo "releases go here" e marque-o como tal.
  • Alguns sites não têm uma ramificação "releases go here" e apenas deixam o final da ramificação de liberação pendurado com uma tag.

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.

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.

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ê:

• Seus desenvolvedores precisam encaminhar a integração (FI) (FI = mesclar para longe do MAIN) frequentemente (2-3 vezes por semana) em suas ramificações de DEV para garantir que as alterações mais recentes sempre considerem os desenvolvimentos gerais mais recentes.
• Seus desenvolvedores precisam reverter a integração (RI) (RI = mesclar para MAIN) na ramificação TEST somente quando atingirem um marco de conclusão de recurso que desejam expor ao controle de qualidade e para o qual estão prontos para fornecer correções rápidas em resposta ao feedback do controle de qualidade. As correções serão executadas na ramificação TEST e imediatamente FI em sua ramificação DEV.
• Nunca RI de qualquer filial DEV para MAIN
• Sempre RI de TEST ramifica para PRINCIPAL, exclusivamente quando seu controle de qualidade considera a qualidade do TESTE OK. Mantenha um limite de alta qualidade para mesclar com MAIN. No mínimo, seu gerente de produto deve poder sempre demonstrar uma versão funcional do seu produto a partir da confirmação mais recente em MAIN.
• Crie ramificações na área de produção apenas conforme necessário. Seu servidor de construção sempre deve marcar todas as ramificações, incluindo as da área de desenvolvimento, e a origem de qualquer construção / release deve ser identificável o tempo todo, independentemente da ramificação da qual ela veio.
• Faça lançamentos para produção somente na MAIN ou na área de produção. Se mais tarde você precisar fornecer uma correção para uma versão exata lançada (por exemplo, você não pode simplesmente fornecer a versão mais recente do MAIN), crie uma ramificação na área de produção a partir da tag MAIN da versão defeituosa, quando a correção for necessária. Sempre corrija o problema na ramificação HotFix e, em seguida, entre imediatamente em MAIN e FI em TEST.

Eu suspeito que você tenha problemas porque:

• Seu RI de desenvolvedores no código TEST que não está completo
• Seus desenvolvedores RI no TEST sem obter a luz verde do controle de qualidade (ou seja, o controle de qualidade não controla o que é injetado no TEST)
• Quando o controle de qualidade relata um bug no TEST, seus desenvolvedores o corrigem na ramificação DEV e depois no RI no TEST. Essa é uma grande prática ruim, porque a mesclagem sempre trará outras porcarias de desenvolvimento incompletas. Eles sempre devem corrigi-lo no TEST e depois FI em sua ramificação DEV. Se não for corrigível no TEST, eles forneceram porcaria total em primeiro lugar e você terá problemas maiores.
• Seus desenvolvedores não fazem FI com frequência suficiente a partir de TEST e, portanto, desestabilizam TEST sempre que entregam lá. É uma arte equilibrando a frequência com que o FI é convertido em DEV. Adie demais e será extremamente caro e arriscado logo antes da entrega, o que você nunca deseja. Faça isso com muita frequência e você não realizará nenhum trabalho de desenvolvimento real se sobrepuser muito ao trabalho entregue por outras pessoas no TEST nesse meio tempo.

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:

1. Atribua um recurso de controle de qualidade a cada equipe de recursos. Peça que eles façam alguns testes de recursos nas compilações a partir do ramo do recurso e dê a eles autoridade para decidir quando um recurso é bom o suficiente para mesclar. Idealmente, peça que eles trabalhem em colaboração com (o restante) da equipe de recursos, para que as coisas sejam testadas logo após serem gravadas. (Observe que isso não significa que eles mesmos tenham que fazer todos os testes.)
2. Use as alternâncias de recurso, em vez de ramificações de recurso ou além delas. Feito corretamente, as alternâncias de recursos permitem que você desative um recurso quebrado sem tentar descompactá-lo do código, para que você possa testar e liberar os outros recursos. O tipo de alternância de que estou falando não é acessível pelos clientes; você não deseja que um número exponencialmente crescente de combinações seja testado. Você define as alternâncias na ramificação do controle de qualidade para corresponder aos recursos que planeja liberar e, se o plano mudar porque um recurso não está pronto, você as altera.

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'.

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.