Ciclo de liberação mais curto com DVCS

A escolha de usar um DVCS em vez de um CVCS realmente gera ciclos de liberação mais curtos? Nesse caso, o que torna os ciclos de lançamento de software mais curtos e quais são os argumentos para isso?

1. Relacionado a solicitação de recebimento? O envio mais fácil de patches desempenha um papel aqui?
2. Relacionado ao fator pessoas? As equipes de projeto que usam o CVCS são mais conservadoras com os cronogramas de lançamento?
3. Algum outro fator?

O que torna o ciclo de lançamento de software mais curto com o DVCS, em comparação com o CVCS?

Eu não acho que exista necessariamente uma diferença entre DVCS e CVCS aqui, mas uma diferença no modelo de ramificação que as pessoas aderem.

Pelo que reuni aqui e pela minha experiência, as pessoas que usam o DVCS tendem a usar mais filiais do que as que usam o CVCS. E se você desenvolver cada recurso em uma ramificação própria, será mais fácil começar a preparar um lançamento com o novo recurso X, mas não o recurso Y, cujo desenvolvimento foi iniciado, mas que ainda não está pronto para o lançamento.

Todos aqui parecem concordar que os projetos que usam DVCS têm ciclos de liberação mais curtos, mas ainda não é certo que a adoção de um DVCS cause os ciclos mais curtos: Correlação não é causalidade!

VCS distribuídos e ciclos de liberação curta são tecnologias relativamente novas. Os projetos que adotam um provavelmente abraçam o outro, enquanto os grupos que preferem o testado e o verdadeiro, ou que possuem um fluxo de trabalho estabelecido há muito tempo, serão mais conservadores e seguirão o CVCS e lançamentos menos frequentes.

Uma pergunta melhor a ser feita seria: "De que maneiras o uso de um DVCS facilita o modelo de ciclo de liberação curta?" É isso que a maioria das respostas está abordando, na verdade. O uso de um DVCS não impede que alguém tenha longos ciclos de lançamento; adotar os curtos é uma escolha, e envolve metodologias de desenvolvimento, modelos de ramificação, revisões de código etc. - não apenas o VCS.

Boa pergunta!

O CVCS acredita no princípio primário de que tudo deve continuar se mesclando / sincronizando de volta ao 'tronco'. Além disso, esperamos que, à medida que evoluamos, o tronco deve ser o ponto mais estável antes do lançamento. Assim, as pessoas colocam seu trabalho na cópia de trabalho, fazem a atualização e o teste antes do check-in. Ou, como alternativa, você trabalha em ramificações particulares / de recursos e mescla outras alterações de tronco, teste antes de reintegrar.

O padrão DVCS pode ser significativamente diferente. Você continua se ramificando e se bifurcando. Você pode experimentar e, finalmente, mesclar galhos que façam sentido. Ocasionalmente, você já ouviu falar de alguma correção de segurança que deve ser lançada imediatamente; portanto, você deseja que esse patch também esteja no seu ramo, mas não deseja muitas outras coisas do tronco! Então, por padrão, você continua trabalhando em seu espaço, continua pegando e integrando coisas - e chega a hora do lançamento. Todos vocês sentam e decidem o que levar o que deixar cair.

Veja isto: http://nvie.com/posts/a-successful-git-branching-model/

Portanto, a diferença essencial é a seguinte: o CVCS pergunta o que a mãe diz aos filhos pequenos - não vá muito além de um ponto em que eu possa encontrar você - continue sincronizando com o tronco. O DVCS funciona assumindo que todo o trabalho é projetado para ser independente, a menos que haja necessidade explícita de mesclar (por exemplo, criar uma liberação).

Agora, vamos à sua pergunta -

A explicação acima realmente soa mais contrária ao que você observou / perguntou. O verdadeiro desafio é definir o que é estável! quando o número de usuários é muito grande e as pessoas continuam delta - cada uma delas pode ter uma contra-ruptura em relação a outras alterações paralelas até que todos estejam de acordo com seu melhor indivíduo, assim como toda a integração e dependências. Portanto, quando você está tentando fazer o lançamento, é preciso realmente agitar as coisas, impedir que as pessoas usem novos recursos - identifique quaisquer problemas de integração quando as coisas se fundem e assim por diante. Tudo isso implica que o CVCS sempre pede que você faça 'intervalos de liberação' entre o desenvolvimento!

Quando o número de colaboradores se torna grande, chegar a esse ponto de 'interrupções de liberação' se torna difícil e menor; e, portanto, o CVCS realmente o forçará a fazer 'festivais de criação de lançamentos' depois de um muito significativo.

No DVCS - você continua trabalhando, testando, testando em seu próprio espaço. A criação e integração de versões é uma atividade paralela e também pode dar ao luxo de tentar e errar ao ver quais conjuntos de patches funcionam juntos e o que não funciona (portanto, serão retirados ou descartados dos releases). No DVCS - você pode dissociar o desenvolvimento individual e, de vez em quando, apenas esgueirar-se em uma versão, se isso fizer sentido.

O que torna o ciclo de lançamento de software mais curto com o DVCS, em comparação com o CVCS?

Concordo com Bart que o principal motivo é o modelo de ramificação usado, mas o tipo de sistema de controle de versão afeta diretamente quais modelos de ramificação são viáveis. Portanto, temos duas sub-perguntas. Qual modelo de ramificação os sistemas distribuídos suportam melhor e por que torna o ciclo de lançamento mais rápido?

A diferença fundamental entre o controle de versão centralizado e distribuído é que, sem a autoridade central, você não pode impor uma linha do tempo linear. Portanto, para tornar possível o controle de versão distribuído, esses sistemas precisavam necessariamente definir o histórico como gráfico acíclico direcionado, em que cada revisão simplesmente possui identificador exclusivo, uma ou mais revisões pai e pode ter muitas revisões filho arbitrárias das quais você talvez nem saiba, porque você não sincronizou com o sistema em que eles foram criados ainda.

Acontece que essa abordagem se presta muito bem à ramificação. Você não precisa fazer nada para obter um ramo, você simplesmente sempre tem um. Assim, você pode ir direto ao trabalho e sair decidindo quando e onde mesclá-lo ou até onde mantê-lo e com o nome até saber se está realmente indo do jeito que você precisa.

Por outro lado, todos os sistemas centralizados mantêm o histórico como um conjunto de ramificações com sequência linear de revisões. Portanto, você deve decidir com antecedência se precisará de um ramo, nomeie-o e crie-o explicitamente. Isso é um grande problema quando você ainda não sabe o que vale a ideia e muitas vezes simplesmente não sabe disso antes de começar a programar. Complicado pelo fato de que na maioria dos sistemas centralizados os nomes das filiais são globais, significativos, geralmente persistentes e não são facilmente alterados, enquanto em todos os principais sistemas distribuídos são apenas identificadores locais que podem ser alterados por capricho e reciclados livremente. E pelo fato de que todas as operações de ramificação e fusão são geralmente um pouco mais lentas no CVCS.

Assim, o DVCS facilita as filiais e, portanto, as equipes que usam filiais DVCS o tempo todo, enquanto as equipes que usam o CVCS as evitam na maioria das vezes.

Agora, por que o uso de ramificações permite lançamentos mais frequentes? Bem, toda equipe subestima uma tarefa de vez em quando, geralmente quando um bug difícil de rastrear aparece. As equipes que usam sistemas centralizados geralmente fazem toda a depuração e o maior desenvolvimento no tronco, porque as ramificações são inconvenientes. Portanto, eles não podem liberar até liberarem a maioria dos bugs e precisam intercalar as fases de desenvolvimento e depuração.

Ao contrário dos sistemas distribuídos, onde todo o trabalho é feito nas filiais, eles podem ser mesclados para teste, teste, correção de bugs e apenas o trabalho que passa nos testes é mesclado separadamente ao tronco. Resultando em tronco com muito poucos bugs e, portanto, pode ser liberado com mais frequência, geralmente sempre que um recurso importante chega.

Também ajuda que, sempre que houver uma mudança de prioridades, o trabalho em andamento possa ser arquivado de maneira trivial com a abordagem de ramificação usada em sistemas distribuídos. Na maioria dos projetos reais, as mudanças nas prioridades acontecem o tempo todo.