Há algo errado com o modo como estamos fazendo o controle de versão?

Eu trabalho com uma equipe de programadores como analista de negócios. Acabamos de lançar a versão 2.0 do nosso produto e estamos trabalhando na próxima versão a ser lançada em 3 meses (é um produto de software interno). Infelizmente, a versão 2.0 tem alguns problemas que eles tiveram que corrigir e vamos implantá-las em algumas semanas. O problema é que também não queremos implantar as alterações que ainda estão sendo trabalhadas e que não serão lançadas por mais três meses.

Os programadores decidiram que a maneira de gerenciar isso era que apenas o código dos defeitos seria verificado e o código dos novos aprimoramentos será mantido nas máquinas locais do desenvolvedor até que sejam concluídos. Terei que fazer as compilações locais de suas máquinas para testar, porque se eles fizerem o check-in do código e precisarmos enviar outro patch para corrigir defeitos, ainda não queremos incluir esses aprimoramentos. Também existe o problema em que o mesmo arquivo de código contém correções e aprimoramentos de defeitos, portanto, eles precisam copiar o arquivo de código localmente e, em seguida, fazer uma alteração para corrigir um bug e verificar esse erro, retomando o trabalho nos aprimoramentos, usando o comando cópia local que eles fizeram.

Parece bastante complicado - existe uma maneira melhor de lidar com esse tipo de cenário? Estamos usando o Team Foundation Server e o Visual Studio 2010.

A V2.0 deveria ter o que chamamos de 'ramificação de estado estacionário' (usamos o Perforce, não o TFS) para ele depois que ele foi lançado. Quaisquer correções para a v2 teriam sido feitas nessa ramificação e depois propagadas de volta para a ramificação de desenvolvimento da v3 enquanto os recursos da v3 também estavam sendo trabalhados, ou seja, um defeito na v2 resultaria em um defeito também na v3.

A existência de alterações nas máquinas do desenvolvedor por um longo tempo provavelmente resultará em um pesadelo de integração.

Bem, existem várias maneiras de lidar com questões como essa, geralmente cobertas pela tag 'ramificação' , cada uma com seu próprio conjunto de benefícios e desvantagens.

Mas a abordagem escolhida pelos seus desenvolvedores ... gee, vou citá-la verbalmente para garantir que não tenha interpretado mal ...

O código ... será mantido nas máquinas locais do desenvolvedor até que sejam concluídas ...

... da maneira como acima é provavelmente o único que está totalmente errado!

O que a torna criminosa para mim é que, para o TFS, existe um Guia de Ramificação para Microsoft Team Foundation Server excelente e fácil de entender - documento enorme e detalhado com recomendações de estratégias de ramificação cuidadosamente adaptadas e explicadas para todos os tipos de projetos diferentes ( versão HTML aqui ).

1. Seus desenvolvedores têm um mal-entendido fundamental de como usar o controle de versão.
2. Não entre em discussões sobre o software de controle de versão "correto". Este não é o problema.
3. Cada ajuste de código está dificultando a correção do problema.
4. Quando você decide fazer a coisa certa, você não pode continuar as alterações de código enquanto corrige as coisas. Você DEVE interromper todo o desenvolvimento e colocar o código no controle de versão.
5. Os desenvolvedores devem estar sentindo a dor o suficiente para pelo menos sentar e conversar sobre isso.
6. Todo software de controle de versão suporta conceitos básicos:
   • Todo o código entra no repositório de controle de versão.
   • Todos os arquivos de código têm números de versão. Esses números aumentam automaticamente à medida que o código é registrado novamente.
   • Um TAG marca todos os arquivos de código de uma (e em) uma versão específica. Assim, podemos etiquetar a versão 1 do software, por exemplo.
   • uma FILIAL é um "desvio" do tronco principal .
     • Toda e qualquer alteração feita em uma ramificação não afeta o tronco.
     • Opcionalmente, você pode mesclar as alterações de ramificação novamente no tronco principal em algum momento.
     • Assim, podemos experimentar sem medo de estragar "as coisas boas".
7. Vocês devem obter o controle de versão "salto de fé", como eu o chamo. CONFIE que seguir as regras básicas manterá as coisas em ordem. Inexperiência nos faz pensar o contrário, confie em mim.
8. Aqui está um tutorial decente. É geral e completo o suficiente para que você não precise vasculhar muitas outras fontes
   • Controle de versão, melhor explicado

editar

• Coloque o controle de versão no seu computador de trabalho.
  • Você pode fazer isso agora sem a coordenação da equipe
  • Mesmo com o controle de versão da equipe, eu recomendo isso
  • Se sua equipe usa Git ou Mercurial, você está usando um repositório local independente. É assim que o controle de versão distribuído funciona.
  • Você pode usar diferentes softwares de VC da sua equipe. Nossa equipe usa o Subversion, eu uso o Mercurial localmente. Os metarquivos do software VC (".svn", ".mg", pastas ocultas) não entram em conflito.

Você não está atuando como um repositório de equipe de fato. É para gerenciar seu próprio trabalho, refatorar esforços, etc.

finalizar edição

O que você está descrevendo é uma maneira terrível de usar o controle de versão. Deveria ter havido uma ramificação feita para a liberação 2.0, uma etiqueta ou algum identificador. Dessa forma, as modificações nessa versão podem ser contidas e mais desenvolvimento pode continuar a acontecer.

Este artigo pode lhe dar algumas idéias. Está escrito tendo gitem mente, mas não há razão para que não funcione mercurialtambém. Percebo que você não está usando nenhum deles, mas também é um problema que você deve consertar.

Resposta rápida: A equipe de desenvolvimento deve ter um ramo de produção separado para manter a base de código V2.0 implantada separada do tronco principal .

Todas as correções precisam ser feitas primeiro nesse ramo e depois testadas e implantadas em outros ramos, para manter o código sincronizado .

Seu projeto também deve ter vários ambientes, for health developmentcomo Prod, Staging, QA e Dev (às vezes UAT). Esses ambientes devem ser configurados antes de ir para o release de produção.

Em suma, estar pronto para erros e modificações é a maneira de oferecer suporte a um aplicativo lançado.

Como o TFS foi mencionado como controle de versão, também compilei uma lista de artigos que serão úteis para definir o (s) ambiente (s) de desenvolvimento de saúde:

• Implementando o Team Foundation Server com uma pequena equipe de desenvolvimento
• Bem-vindo à plataforma de integração TFS!
• Guia de desenvolvimento de equipe com TFS
• Configurando um ambiente de desenvolvimento

Não, porque enquanto você estiver usando um VCS, você não está fazendo o controle de versão.

O conceito central do controle de versão é rastrear as diferenças ao longo do tempo; você planeja registrar algumas diferenças, mas no momento a maioria das alterações não é registrada.

Como outros já disseram, você deve usar ramos. Depois de definir essa configuração, você deverá verificar todas as alterações funcionais (ou seja, nem todas as teclas, mas sempre que você corrigir um bug, adicionar um recurso, excluir um recurso ou concluir uma alteração de forma que ela ainda crie e funcione).

Sou desenvolvedor e recebemos código de ramificação e db diferentes para correções da versão atual e diferentes para aprimoramentos e para a versão consecutiva posterior.

Depois que nossas correções são concluídas, elas são mescladas com a produção e implantadas, obtemos uma nova ramificação para trabalhar novamente nas melhorias.

Além disso, seguimos uma prática como se eu tivesse 10 correções para minha versão atual

Eu escrevo como

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

Da mesma forma, para outras correções, eu apenas faço isso para todas as linhas que altero ou adiciono para correção. E basta comparar e confirmar. Da mesma forma, se eles estavam fazendo paralelo no mesmo ramo, eles podem usar

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+FO comando e o tipo //Start Iteration 2, Fix No-1, Branch No-"ABC" de pesquisa em toda a solução ajudam muito a descobrir os locais exatos, os arquivos nos quais o código é alterado e o código novo, apenas essa parte pode ser usada para confirmação.