Qual é a melhor técnica para gerenciar erros e novos recursos com controle de versão no CVS / SVN para uma equipe de 6 a 9 pessoas?

5

Em uma empresa que trabalha em um projeto de software de longo prazo, existem 6 a 9 desenvolvedores trabalhando no mesmo escritório.

A equipe de desenvolvimento usa o JIRA para rastreamento de bugs e CVS (e alguns SVN) para controle de versão de diferentes Java Web Apps relacionados ao aplicativo.

A equipe usa o REST para se comunicar entre os aplicativos da Web em diferentes servidores. O ambiente consiste no Amazon EC2 e no Google App Engine Apps, todos escritos em Java, HTML, CSS e JavaScript.

A equipe de desenvolvimento confirma o código todos os dias. Usando essa estratégia, as implantações acontecem a cada 20 a 25 dias, mas elas preferem segmentar uma vez por semana ou uma vez a cada duas semanas.

Quando o código passa por testes, os testadores encontram e relatam bugs, mas quando a equipe de desenvolvimento corrige os bugs e implanta o software, o software às vezes tem mais bugs porque os desenvolvedores que estão trabalhando em novos recursos ainda estão confirmando o código. o repositório.

Às vezes, a equipe de vendas ou os clientes encontram bugs também nos sistemas de produção. Nosso pensamento é que poderíamos verificar uma cópia do código que é estável e fazer alterações lá.

Eu suspeito que isso seja um problema com a forma como o controle de versão é usado, mas poderia ser outra coisa no processo. Como essa equipe de desenvolvimento ágil de 6 a 9 pessoas deve certificar-se de que os lançamentos sejam frequentes, uma vez por semana ou uma vez a cada duas semanas, e que as implantações sejam de alta qualidade sem erros de regressão?

    
por jmort253 12.10.2011 / 22:48
fonte

4 respostas

1

Por minha experiência, a abordagem mais produtiva para lidar com questões como essa foi rastrear e refletir o processo de desenvolvimento em uma espécie de OODA loop. Os principais truques são isolar quando necessário, ter pontos de verificação claros para dev e QA se comunicarem ("releases internos" se você desejar) e, bem, não se preocupar com o que não é realmente importante.

  • oh e melhor se livrar do CVS. Dois sistemas de controle de versão parecem ser demais para o caso como o seu.

Agora, vamos dar uma olhada em alguns dos problemas que você mencionou ...

When the code goes through testing, the testers find and report bugs, but when the development team fix the bugs and deploy the software, the software sometimes then has more bugs in it because developers working on new features are still committing code to the repository.

A única forma produtiva que eu conheço para estabilizar a qualidade do software a ser implantado (release candidate) é isolá-lo do repositório principal (leia-se: branch dedicado, com seu próprio Feature Freeze e Code Freeze mini-milestones).

  • Observe minha experiência ao fazer o inverso, isto é, com o repositório principal "congelando" enquanto o teste para o código do candidato a lançamento era um desastre total.

Sometimes the sales team or customers find bugs as well on production systems. Our thought is that we could check out a copy of the code that is stable and make changes there.

Não necessariamente assim. Desculpe por ser vago, mas duvido que seja possível apresentar uma receita tecnicamente precisa aqui. Esse tipo de coisa é melhor para se comunicar com as partes interessadas do produto. Uma coisa que as equipes de desenvolvimento e controle de qualidade podem (devem) trazer para a mesa de discussão é a estimativa comparativa dos esforços envolvidos na correção da versão mais antiga versus a implantação da versão mais recente.

    
por 13.10.2011 / 00:34
fonte
2

Em vez de "verificar uma cópia do código que é estável e fazer alterações lá." use ramificação para cada recurso.

Configure um servidor de integração contínua. Quando você verifica o código na ramificação principal "dev", ele é compilado automaticamente para o seu servidor de desenvolvimento.

Quando você tem uma nova tarefa / recurso / etc, você ramifica o código dev em uma ramificação de recurso. Desenvolva, depois mescle de volta no dev.

Você também mantém um ramo de controle de qualidade / teste, mais uma vez, ele cria automaticamente a configuração para implantar em seu servidor de controle de qualidade / teste.

Cada recurso pode ser implantado independentemente para dev a QA.

O acesso para fazer check-in na filial do controle de qualidade precisa ser controlado. De modo que, se o controle de qualidade iniciar o teste, nenhum outro poderá ser movido para lá até que eles sejam assinados e mesclado a ramificação do controle de qualidade na produção (ou uma etapa de estágio intermediária)

Dessa forma, os desenvolvedores não chocam o que o controle de qualidade está tentando testar. E só vai para o Prod quando o QA terminar. Então, quando eles se desconectarem e forem implantados para produção, você libera outro lote de recursos que estão prontos para o departamento de controle de qualidade para eles, para o controle de qualidade.

Ensine, enxague, repita.

    
por 12.10.2011 / 23:18
fonte
1

Tudo o que posso sugerir é um feedback mais apertado, via

    teste de unidade ou integração
  • - inicialmente destinado a defeitos e pontos de dor de integração.
  • uma construção contínua que será acionada em todas as verificações nessa unidade de execução e testes de integração
  • uma cultura de 'consertar a compilação' na equipe - "sempre se esforçando para obter a luz verde "
  • sem silos de código - tanto quanto possível, todos os desenvolvedores devem poder trabalhe em qualquer problema ou construa falhas.
  • implantar frequentemente em uma versão demo do (s) aplicativo (s) que desenvolvedores / BA pode usar para agitar novos recursos antes que eles atinjam o equipe de teste.
  • um novo defeito, além de ser corrigido, também recebe um teste que se concentra sobre esse problema.

Acho que você verá que fazer essas coisas permitirá reduzir o número de bugs que atingem os testadores.

    
por 12.10.2011 / 23:11
fonte
1

Você deve ler algum material sobre como trabalhar com filiais. Eu manteria ramificações separadas para versões antigas, atuais e futuras, e forçaria todo o desenvolvimento em ramificações de recursos; nenhum de seus ramos "estáveis" deve ser quebrado.

Suponho que o ferramental é uma grande parte do que falta para vocês. Ramificação e fusão é um problema com o SVN e o CVS. Eu pressionaria por uma mudança para o Git.

    
por 12.10.2011 / 23:15
fonte