A tendência do ramo “desenvolver” desaparecendo

Ultimamente, notei algo olhando alguns projetos populares no GitHub, que não há developramificação. E, de fato, o guia GitHub Flow também não o menciona. Pelo meu entendimento, mastersempre deve ser totalmente estável e refletir a produção. Se os desenvolvedores estiverem trabalhando em ramificações de recursos e depois mesclando-os masterquando terminar, isso significa que há um período em que os recursos / correções estão sendo mesclados mastere a masterramificação é realmente mais recente que a produção.

Não faria mais sentido que a equipe crie ramificações de recursos / correções develop, junte -se a elas e, quando a próxima versão estiver totalmente pronta para o lançamento, developfor mesclada mastere uma tag for criada? Imagine se as pessoas estão se unindo diretamente mastere um bug é relatado na produção que se torna difícil de corrigir porque a masterbase de código do ramo mudou significativamente. Em seguida, os desenvolvedores precisam dizer ao usuário que aguarde até a próxima versão para ver o problema resolvido.

Edição: Esta pergunta é diferente de "para ramificar ou não ramificar". Ele aborda especificamente as pessoas que deixam de usar o ramo de desenvolvimento e as razões que o cercam, uma vez que isso foi apontado como uma prática recomendada por um longo tempo.

Vem da mentalidade do IC, onde há integração várias vezes ao dia.

Existem prós e contras de ambos.

Em nossa equipe, também abandonamos o ramo de desenvolvimento, pois sentimos que ele não oferecia nenhum benefício adicional, mas algumas desvantagens. Configuramos nosso software de CI (Teamcity) para compensar os inconvenientes:

1. Habilite a implantação de uma confirmação específica. Em outras palavras: não implantamos uma filial. Implementamos uma confirmação.
2. Podemos implantar mestre ou ramificações, começando com um hotfix / prefixo.

O motivo disso funcionar é porque todas as solicitações pull contêm código potencialmente liberável, mas isso não significa que implantaremos todas as confirmações no mestre.

A principal razão pela qual abandonamos o ramo de desenvolvimento é porque ele tendia a ficar muito grande e consumir muito tempo para ver o que realmente continha. Se implantamos algo um pouco prematuramente, apenas ramificamos um ramo de hotfix e o implantamos diretamente.

Uma ramificação de desenvolvimento é mais importante se o seu processo de lançamento for complexo e você precisar de candidatos a lançamento sérios.

Por exemplo, imagine que você está escrevendo um software que é firmware para carros. Isso é ... não-trivial de corrigir e é provável que qualquer versão tenha um conjunto abrangente de testes que não sejam de CI / integração executados em hardware real.

Nesse caso, pode fazer mais sentido isolar um "candidato à liberação" em uma ramificação não principal (como "desenvolver"). Isso permite que sua equipe que executa esses testes tenha uma ramificação na qual mesclar recursos.

Webapps ou outro software facilmente atualizado não tem essa restrição.

No entanto, observe que:

• Muitos projetos (a maioria?) No github não têm esse tipo de restrição
• Um "mestre" principal serve ao mesmo propósito
• Um fluxo de trabalho de "criar um PR versus mestre" é muito mais universal do que "criar um PR em um ramo que você não conhece imediatamente neste repositório"

Existem duas filosofias que eu já vi em projetos, e acho que a escolha é apenas uma questão de gosto:

1. Designe 'mestre' como o release de produção e desenvolva em um ramo 'desenvolva'.

2. Desenvolva em 'master' e tenha uma ramificação de nome diferente para lançamentos de produção estáveis. Isso faz ainda mais sentido se o seu projeto tiver várias ramificações de versão por vez (por exemplo, a atual preferida é a Versão 1.8, mas você também ainda mantém a Versão 1.7).

Ambas são abordagens comuns e têm seus prós e contras.

As liberações para produção podem ser marcadas, para que a situação lançada sempre possa ser reproduzida sem dedicar um ramo inteiro para essa finalidade.

Se um bug crítico for encontrado na produção no momento em que o mestre não puder ser liberado, será fácil verificar a tag e iniciar um novo ramo "hotfixes-for-release-1.2.0" a partir daí. Mas isso deve ser bastante raro.

Na maioria das vezes, em nossos aplicativos da Web, o master mudou desde a última versão, mas não de maneira muito significativa, para que possamos simplesmente fazer uma nova versão do master que tenha a correção. Ajuda a fazer lançamentos muito frequentes de qualquer maneira.

Se os desenvolvedores estiverem trabalhando em ramificações de recursos e depois mesclando-os no master quando terminar, isso significa que há um período em que os recursos / correções estão sendo mesclados mastere a masterramificação é realmente mais recente que a produção.

...

Imagine se as pessoas estão se unindo diretamente ao mestre e é relatado um erro na produção que se torna difícil de corrigir porque a base de código do ramo principal mudou significativamente.

Esse não é o Github Flow.

Este é o processo de implantação / mesclagem do Github Flow, de acordo com o seu link:

Implantar

Depois que sua solicitação de recebimento for revisada e a ramificação passar em seus testes, você poderá implantar suas alterações para verificá-las em produção. Se sua ramificação causar problemas, você poderá recuperá-la implantando o mestre existente na produção.

Mesclar

Agora que suas alterações foram verificadas na produção, é hora de mesclar seu código na ramificação principal.

(Ênfase minha)

Em outras palavras, masternunca estará à frente da produção. Da mesma forma, mastersempre estará em um estado estável e liberável (além de bugs não descobertos), pois tudo é revisado, testado e implementado na produção antes de ser mesclado master.

O problema que vejo é que a implantação / mesclagem de fluxo do Git / Hub assume que um recurso está sendo desenvolvido / testado / mesclado / implantado por vez - e, na minha experiência, esse não é o caso. Se mesclamos um recurso de cada vez, há uma chance maior de problemas de regressão - encontrados somente depois que os recursos são mesclados para mestre e possivelmente em produção.

É preciso haver uma maneira de testar vários recursos, mesclar vários recursos e implantar o mesmo. Estou usando um 'ramo de bundle' (um ramo criado a partir do mestre com os ramos de recursos prontos para teste mesclados a ele) que é implantado no qa / uat. As correções durante o uat acontecem apenas na ramificação do recurso, e essas são mescladas novamente à ramificação do pacote. Após a aprovação de uma subseção da ramificação do pacote configurável, somente os recursos aprovados no pacote configurável são solicitados por solicitação de masterização - e o ciclo é contínuo.

Eu uso isso com o Gitflow, mas pensando em usá-lo para o fluxo do GitHub. O recurso QA / UAT muitos de cada vez parece significativo. Outro problema no fluxo do GitHub é que ele assume todos os desenvolvedores sr, e esse nem sempre é o caso.

Prefiro usar o fluxo do GitHub devido à sua simplificação. Com um pacote como recurso, acho que estaria melhor preparado. É possível que o pacote seja semelhante ao lançamento; no entanto, ainda estou pensando nisso.

Outro problema é o processo de solicitação de recebimento que ocorre no final antes da mesclagem com o mestre; no entanto, às vezes você deseja codificar a revisão antes do teste de qa comercial - portanto, muito antes da mesclagem