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

V2.0 deve ter tido o que nós chamamos de 'ramificação de estado estável' (usamos o Perforce, não o TFS) para uma vez liberada. Quaisquer correções para v2 teriam sido feitas para essa ramificação e, em seguida, propagadas de volta para a ramificação de desenvolvimento 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.

Ter alterações residindo nas máquinas do desenvolvedor por um longo tempo provavelmente resultará em um pesadelo de integração.

Bem, há uma várias formas para lidar com problemas como esse, geralmente cobertos por tag 'branching' , cada um com um conjunto de benefícios e desvantagens.

Mas abordagem escolhida por seus desenvolvedores ... gee vou citá-la verbalmente para ter certeza de que eu não interpretei mal ...

code... will be kept on the developer's local machines until they are done...

... o caminho acima é provavelmente o único que está totalmente, completamente errado!

O que faz fronteira com o criminoso para mim é que, para o TFS, há uma excelente, fácil de entender, Orientação de ramificação do Microsoft Team Foundation Server versão HTML aqui ).

1. Seus desenvolvedores têm um mal-entendido fundamental sobre como usar o controle de versão.
2. Não entre em uma discussão sobre o software de controle de versão "correto". Este não é o problema.
3. Todo ajuste de código está dificultando a correção do problema.
4. QUANDO todos decidem fazer a coisa certa, não é possível continuar com as alterações no código enquanto você conserta as coisas. Você DEVE parar todo o desenvolvimento e colocar o código no controle de versão.
5. Os dev devem estar sentindo a dor suficiente para pelo menos sentar e conversar sobre isso.
6. Todo o software de controle de versão oferece suporte a conceitos básicos:
   • TODO o código vai para o repositório de controle de versão.
   • Todos os arquivos de código possuem números de versão. Esses números são incrementados automaticamente conforme o código é verificado novamente.
   • Uma TAG marca todos os arquivos de código de uma (e em uma) versão específica. Assim, podemos TAG a versão 1 do software, por exemplo.
   • um BRANCH é um "desvio" do tronco principal .
     • Toda e qualquer alteração feita em uma ramificação não afeta o tronco.
     • Você pode, opcionalmente, mesclar alterações de ramificação no tronco principal em algum momento.
     • Assim, podemos experimentar sem medo de bagunçar "as coisas boas".
7. Vocês precisam ter o controle de versão "salto de fé" como eu o chamo. CONFIE que seguir as regras básicas irá manter as coisas em ordem. Inexperiência nos faz pensar de outra forma, 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ões, melhor explicado

editar

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

Você não está agindo como um repositório de equipe de fato. É para gerenciar seu próprio trabalho, refatorar os esforços, etc. e CYAing-se enquanto a equipe continua a FUBAR a base de código.

end edit

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

Este artigo pode lhe dar algumas idéias. Está escrito com git em mente , mas não há motivo para que ele não funcione com mercurial também. Percebo que você não está usando nenhum desses, mas esse também é um problema que você deve considerar corrigir.

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

Todas as correções de bugs precisam ser feitas primeiro nesse ramo e depois testadas e implantadas em outras filiais, para manter o código em sincronia .

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

Em resumo, estar pronto para erros e modificação é a maneira de suportar um aplicativo lançado.

Como o TFS foi mencionado como um 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 do TFS!
• Desenvolvimento de equipe com o guia do TFS
• Configurando um ambiente de desenvolvimento

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

O conceito central para controle de versão é acompanhar a diferença ao longo do tempo, você está PLANEJANDO em registrar algumas diferenças, mas no momento a maioria de suas alterações não são registradas.

Como outros já disseram, você deveria estar usando filiais. Depois de ter essa configuração, você deve verificar todas as alterações funcionais (ou seja, nem todas as teclas pressionadas, mas sempre que corrigir um erro, adicionar um recurso, excluir um recurso ou concluir uma alteração de forma que ele ainda construa e funcione). p>     

Sou um desenvolvedor e recebemos código de ramificação e banco de dados diferentes para correções da versão atual e um diferente para aprimoramentos e para versões posteriores consecutivas.

Uma vez que nossas correções são feitas, elas são mescladas com a produção e são implantadas para que a nova ramificação funcione novamente para melhorias.

Além disso, seguimos uma prática como se eu tivesse 10 correções para a 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 faço isso para cada linha que eu altero ou adiciono para corrigir. E apenas compare e cometa. Da mesma forma, se eles estavam fazendo paralelos 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+F e digite //Start Iteration 2, Fix No-1, Branch No-"ABC" pesquisar em toda a solução ajuda muito a descobrir locais exatos, arquivos onde o código é alterado e usar código novo apenas para que a parte possa ser usada para confirmar.