app branching strategy

Estratégia de ramificação para aplicativos móveis

Entender o porquê?

Configurações do repositório

• Só permite a squash mescla
• ✅ Exclua os galhos da cabeça depois que a solicitação de tração for mesclada
• Configurações> Ações> Permissões de fluxo de trabalho
  • Leia e escreva permissões
  • Permita que as ações do GitHub criem e aprovem as solicitações de tração

Trunks permanentes? ️

• master -> Código testado mais recente e mais recente

Nenhum outro tronco permanente.

Outros ramos que vêm e vêm ⏳

• feature/<feature_name>
• fix/<bug_title>
• release/v-<version.major>.<version.minor>
  • Ramo temporário que vive enquanto um lançamento está sendo preparado
  • Nenhum número de patch no nome da filial porque o número do patch está sujeito a alterações à medida que as correções são mescladas após o teste
• auto-backmerge/<pr_number> usado para aumentar os PRs para dominar para cada mudança empurrada para liberar ramos

Esquema de versão? Iqu

YYMM.DD.NN

NN ➡️ Número do patch

Ex: 2301.25.00 , 2302.01.04

Fluxos de trabalho automatizados?

Na fusão de relações públicas para master

? ON-MERGE-MASTER.YML Em todas as mescladas para dominar, atualizamos a versão completa. As versões maiores e menores serão modificadas se a versão existente for de uma data anterior, caso contrário, apenas o número do patch será aumentado.

Exemplo :
Versão existente: 2301.25.02
Se um novo compromisso for pressionado em 25 de janeiro de 2023, a versão se tornará 2301.25.03
Se um novo compromisso for pressionado em 26 de janeiro de 2023, a versão se tornará 2301.26.00

Na fusão de relações públicas para release/**

? On-Merge-Relase.yml

Atualizar o número do patch na release*

Em cada compromisso, atualizamos o número do patch na release* ramificações

Backmerge entra em release/** para master

? On-Merge-Relase.yml Todo impulso para release* acionará um PR correspondente ao master por meio de uma auto-backmerge/<pr_number> .

O PR será mesclado automaticamente se não houver conflitos

Fluxos de trabalho acionados manualmente?

Prepare um novo lançamento

? Prepare-a-Relase.yml Crie uma filial de liberação a partir do último mestre, com a versão correta no nome da ramificação.

Ações ▶ ️ > Prepare um lançamento> Run Workflow

Liberação de tags

? tag de criação de criação de traseiro.

Ações ▶ ️ > Criar versão marcada> Run Workflow (selecione a filial de liberação)

Desenvolvimento de recursos e correção de bugs?

 %% {init: {'gitgraph': {'mainbranchname': 'master', 'showCommitlabel': true}}} %%

Gitgraph
	ID de comprometimento: "? 2301.25.00"
	Fix do ramo/quadros-bug
	ID de compromisso: "Fix Logic"
	ID de comprometimento: "Fix UI"
	checkout mestre
	Recurso da filial/dm
	ID de compromisso: "Adicionar db"
	ID de compromisso: "Adicionar soquete"
	checkout mestre
	Merge Fix/Frames-Bug ID: "PR: Frames Bug"
	ID de comprometimento: "? 2301.25.01"
	Recurso de checkout/dm
	Mesclar ID Master: "Pull Master"
	ID de compromisso: "Adicionar interface"
	checkout mestre
	Mesclar recurso/DM ID: "PR: Recurso DM"
	ID de comprometimento: "? 2301.25.02"

Liberações ⛳

Preparação ⚒️

1. Corte o ramo de liberação do último master (ações ▶ ️ > Prepare um lançamento> Run Workflow)
2. Gerar artefato (APK / IPA) e teste de dev
3. Distribua artefato para teste
4. Corrija bugs na filial de liberação, filial master e vá para a etapa 2

 %% {init: {'gitgraph': {'mainbranchname': 'master', 'showCommitlabel': true}}} %%

Gitgraph
	ID de comprometimento: "? 2301.25.02"
	Liberação da filial/V-2301.25
	checkout mestre
	ID de confirmação: "PR: New Recurso" Tipo: Destaque
	ID de compromisso: "? 2301.26.00"
	Release/V-2301.25 de checkout
	Fix do ramo/liberação
	ID de comprometimento: "Corrija o bug"
	Release/V-2301.25 de checkout
	Merge Fix/Release-Bug ID: "PR: Bug de liberação"
	Release/V-2301.25 de checkout
	Branch Auto-Backmerge/Release-Bug
	Mesclar ID Master: "Atualizar ramo"
	Release/V-2301.25 de checkout
	ID de confirmação: "? 2301.25.03" Tag: "V-2301.25.03"
	checkout mestre
	Merge ID de Merge Auto-Backmerge/Release-Bug: "Backmerge"
	checkout mestre
	ID de comprometimento: "? 2301.26.01"

Fazendo o lançamento? ️

Ações ▶ ️ > Criar versão marcada> Run Workflow (Selecione o ramo de liberação)

Uma vez que somos? Em todos os testes, faça o acima para marcar a última confirmação da ramificação de liberação e criar uma versão do GitHub com notas de liberação automatizadas. E envie os artefatos para as lojas de aplicativos

Hotfix?

Corrigindo um problema na construção de produção atual ( v-2301.16.01 )

1. Crie uma filial a partir da tag de liberação (tag: v-2301.16.01 > ramo: release/v-2301.16 )

O resto é o mesmo que o fluxo de liberação normal

 %% {init: {'gitgraph': {'mainbranchname': 'release/v-2301.16', 'showCommitlabel': true}}} %%

Gitgraph
	ID de confirmação: "2301.16.04" Tag: "V-2301.16.04"
	Branch Hotfix/Crash
	ID de compromisso: "Fix Crash"
	Release/V-2301.16 de checkout
	Merge Hotfix/Crash ID: "Crash PR"
	ID de comprometimento: "? 2301.16.05"
	Branch Hotfix/Bug
	ID de comprometimento: "Corrija o bug"
	Release/V-2301.16 de checkout
	Merge Hotfix/Bug ID: "PR Bug"
	ID de comprometimento: "? 2301.16.06" Tag: "V-2301.16.06"

O porquê?

Por que apenas a fusão de abóbora?

A história linear é desejável por várias razões. Tudo se resume à simplicidade novamente.

Permitir que a abóbora se falhe com um único tronco é a maneira mais simples de alcançar a história linear. Ninguém tem que pensar, a coisa certa acontece automaticamente.

Também em geral, as pessoas têm melhor disciplina em relação aos títulos de RP do que mensagens, para que seus logs de mudança também pareçam bons.

Por que as filiais de lançamento?

Ao contrário dos aplicativos do servidor, os processos de liberação de aplicativos móveis tendem a ser longos. É comum levar 2 ou mais semanas se incluirmos o lançamento gradual para 10%> 20%> 50%> 100% enquanto observa a estabilidade e as métricas ao longo do caminho.

Enquanto isso, os colaboradores não devem ter ambiguidade se é seguro se fundir para dominar agora.

Depois que a versão é feita e a confirmação é marcada, eles não têm nenhum propósito. É por isso que os excluímos após o lançamento.

 Gantt
	Desenvolvimento de aplicativos de título e lançamentos
	DateFormat Aaaaa-mm-dd
	TickInterval 3Days

	Seção Dev 1
	Recurso 2: A, 2022-01-13, 15d
	Fundir para mestre: crit, marco, após a, 0d

	Seção Dev 2
	Recurso 1: B, 2022-01-12, 2d
	Mesclar para Mestre: Milestone, após B, 0d
	Atualização da biblioteca ⬆️: l, 2022-01-16, 1d
	Merge para Mestre: Crit, Milestone, depois de L, 0d
	Correção Recurso 1 ?: B2, após R1, 2d
	Mesclar para liberar: Milestone, após B2, 0d
	Atualização da estrutura ⬆️: f, 2022-01-22, 1d
	Fundir para mestre: crit, marco, depois de f, 0d

	liberação da seção
	Prepare a versão 2201.14: Milestone, após B, 0d
	Recurso de teste 1: R1, após B, 4d
	Recurso de teste 1: R2, após B2, 1D
	ROLAMENTO 2201.14.1 10% - 100%: R3, após R2, 7d
	Prepare a versão 2201.31: Milestone, 2022-01-31, 0d
	

Se fundindo para dominar? é seguro e encorajado, mesmo quando um lançamento está em andamento

Por que usar um esquema de versão baseado em data?

É um esquema de versão baseado em data que também é

• compatível com comparações semver para as quais a versão é maior que a outra
• Comparações de ordem alfabética compatíveis com string ( 2301.16.00 > 2212.31.07 )

E o melhor de tudo evita a pergunta - quando lançamos esta versão? para sempre, de alguém em toda a equipe

Mesmo que responder à pergunta acima não seja tão importante para sua equipe, é igualmente bom, se não melhor que semver . Que, a maioria das equipes usa por padrão. O versão semântica ( semver ) faz sentido para as bibliotecas. Os consumidores da sua biblioteca querem saber quando há mudanças quebradas e quando não houver. E os gerentes de pacotes aproveitam esta convenção para atualizar com segurança as dependências. Os usuários de aplicativos móveis / lojas de aplicativos não possuem essas expectativas nas versões do aplicativo. Eles mal se importam.

Minhas equipes usam esquemas de versão baseados em data há mais de um ano e é ótimo!