Stanford executa uma instância da base de código OpenEdX que uma equipe de engenheiros desenvolve ativamente. Mantemos nosso próprio garfo em github.com/Stanford-Online/edx-platform e tentamos manter nosso fork próximo ao edX master mesclando mensalmente do repositório principal da plataforma edx do edX (github.com/edx/edx-platform). Preferimos enviar o código por meio de solicitações pull (PRs) para o repositório principal do edX, mas às vezes isso não é possível, pois criamos periodicamente recursos personalizados específicos de Stanford. Por meio da iteração, adotamos um processo de lançamento claramente definido que acomoda fluxos de trabalho para mesclar do repositório edX principal e manter nosso próprio repositório separado dominar ramo. Como estamos executando um site com um grande número de usuários, achamos que a estabilidade dos lançamentos é fundamental. Isso significa que nos esforçamos muito para manter o código ruim fora do liberar branch, e o processo de liberação facilita isso.

À medida que enviamos PRs para o edX e para nós mesmos, precisamos ter acesso aos repositórios do edX de nossos ambientes de desenvolvimento, então a maioria dos desenvolvedores de Stanford executa ambientes git com pelo menos dois controles remotos (ou às vezes mais com controles remotos pessoais e os de colegas): origem, o repositório de código de Stanford; e rio acima, o repositório de código edX, do qual podemos verificar o branch master para fazer PRs para edX. Também usamos isso rio acima remote para mesclar alterações de código do edX durante nosso processo de lançamento.

Foi aqui que vi a necessidade de um diagrama que explicasse o processo de liberação. Eu sou uma pessoa visual, e desenhar algo é como eu entendo as coisas. Aqui está meu diagrama para ajudar a descrever nosso fluxo de trabalho de desenvolvimento e lançamento:

É especialmente útil porque nossos desenvolvedores se revezam na responsabilidade pelos lançamentos em nosso sistema rotativo “Release Master”. O diagrama mantém nosso ciclo de lançamento consistente entre os lançamentos e minimiza os erros.

Aqui está um plano de lançamento usando o diagrama como guia:

1. Primeiro criamos um rc ramificar do nosso branch master, pegando qualquer desenvolvimento que tenha sido mesclado em dominar desde o último lançamento.

1a. Se quisermos fundir o rio acima liberar ramificar para o rc filial, fazemos isso aqui.

Neste ponto, temos um candidato a lançamento que podemos testar e, quando estivermos confiantes de que não quebrará nada, instalaremos em nossas máquinas de produção.

2. Agora mesclamos a ramificação rc no ramo liberar (este deve ser um simples avanço rápido; se não for, a versão anterior teve um problema!).

3. Agora o liberar branch (e o mesclado rio acima código) pode ser mesclado de volta ao dominar branch para manter ambas as ramificações sincronizadas uma com a outra.

Observe que as ramificações de recursos são criadas a partir de dominar e mesclados novamente para serem lançados no ciclo de lançamento regular. Os hotfixes, por outro lado, são ramificados de liberar, fundiu-se novamente em liberar, imediatamente enviado para produção e, em seguida, mesclado de volta para dominar para manter a sincronicidade. Observe também que liberar mudanças e rio acima fusões não fazem isso em dominar a menos que sejam considerados seguros após o teste, o que isola dominar de bugs também.

E é isso! Usamos esse modelo de ramificação para cada repositório bifurcado que mantemos, o que mantém tudo consistente e previsível.

 558 visualizações totais