Desculpe por este longo post, mas acho que vale a pena.
Acabei de começar com uma pequena loja .NET que funciona de maneira um pouco diferente de outros lugares em que trabalhei. Diferentemente de qualquer uma das minhas posições anteriores, o software escrito aqui é direcionado a vários clientes e nem todo cliente obtém a versão mais recente do software ao mesmo tempo. Como tal, não há "versão de produção atual". Quando um cliente recebe uma atualização, ele também recebe todos os recursos adicionados ao software desde a última atualização, o que pode ser há muito tempo. O software é altamente configurável e os recursos podem ser ativados e desativados: o chamado "recurso alterna". Os ciclos de lançamento são muito restritos aqui, na verdade eles não estão dentro do cronograma: quando um recurso é concluído, o software é implantado no cliente relevante.
A equipe apenas no ano passado mudou do Visual Source Safe para o Team Foundation Server. O problema é que eles ainda usam o TFS como se fosse VSS e impõem bloqueios do Checkout em uma única ramificação de código. Sempre que uma correção de bug é lançada em campo (mesmo para um único cliente), eles simplesmente criam o que estiver no TFS, testam se o bug foi corrigido e implantam no cliente! (Eu mesmo, vindo de uma experiência em software farmacêutico e de dispositivos médicos, é inacreditável!). O resultado é que o código de desenvolvimento meio cozido é colocado em produção sem ser testado. Os bugs estão sempre entrando nas versões de lançamento, mas geralmente um cliente que acaba de obter uma versão não os vê se não usar o recurso em que está o erro. O diretor sabe que isso é um problema, pois a empresa está começando a crescer. de repente, com alguns grandes clientes chegando e outros mais pequenos.
Foi-me pedido que olhasse as opções de controle de origem para eliminar a implantação de códigos com erros ou inacabados, mas para não sacrificar a natureza um tanto assíncrona dos lançamentos das equipes. Eu usei VSS, TFS, SVN e Bazaar em minha carreira, mas o TFS é onde a maior parte da minha experiência foi.
Anteriormente, a maioria das equipes com as quais trabalhei usa uma solução de duas ou três ramificações do Dev-Test-Prod, onde por um mês os desenvolvedores trabalham diretamente no Dev e, em seguida, as alterações são mescladas no Test then Prod, ou promovidas "quando estiver pronto" em vez de no um ciclo fixo. Construções automatizadas foram usadas, usando o Cruise Control ou o Team Build. No meu trabalho anterior, o Bazaar era usado em cima do SVN: os desenvolvedores trabalhavam em suas próprias ramificações de recursos pequenos e depois enviaram suas alterações para o SVN (vinculado ao TeamCity). Isso foi bom, pois era fácil isolar as mudanças e compartilhá-las com os ramos de outras pessoas.
Com os dois modelos, havia um ramo central de desenvolvimento e prod (e às vezes teste), através do qual o código era enviado (e os rótulos eram usados para marcar as compilações no prod a partir do qual os lançamentos eram feitos ... e estes eram transformados em ramos para correções de erros) para lançamentos e mesclados de volta ao dev). No entanto, isso não se adequa à maneira de trabalhar aqui: não há ordem para quando vários recursos serão lançados, eles serão pressionados quando estiverem completos.
Com esse requisito, a abordagem de "integração contínua", como eu a vejo, se decompõe. Para obter um novo recurso com integração contínua, ele deve ser enviado via dev-test-prod e isso capturará qualquer trabalho inacabado no dev.
Estou pensando que, para superar isso, devemos reduzir um modelo fortemente ramificado de recursos sem ramificações de dev-test-prod, mas a fonte deve existir como uma série de ramificações de características que, quando o trabalho de desenvolvimento é concluído, são bloqueadas, testadas, fixas, bloqueadas , testado e liberado. Outras ramificações de recursos podem obter alterações de outras ramificações quando precisam / desejam, portanto, eventualmente, todas as alterações são absorvidas pelos demais usuários. Isso se encaixa muito bem em um modelo de Bazaar puro do que eu experimentei no meu último emprego.
Por mais flexível que isso pareça, parece estranho não ter um tronco de desenvolvimento ou ramo de produção em algum lugar, e estou preocupado com os ramos que não precisam se reintegrar ou com pequenas alterações tardias feitas que nunca são atraídas para outros ramos e desenvolvedores reclamando sobre mesclar desastres ...
Quais são os pensamentos das pessoas sobre isso?
Uma segunda pergunta final: Estou um pouco confuso sobre a definição exata de controle de fonte distribuído: algumas pessoas parecem sugerir que se trata apenas de não ter um repositório central como o TFS ou o SVN, outros dizem que se trata de ser desconectado (o SVN é 90% desconectado e o TFS possui um modo offline perfeitamente funcional) e outros dizem que é sobre a ramificação de recursos e a facilidade de mesclagem entre filiais sem relacionamento pai-filho (o TFS também possui mesclagem sem base!). Talvez esta seja uma segunda pergunta!