app branching strategy
1.0.0
¿Entender el por qué s?
master -> Código más reciente y mejor probado de desarrolloNo hay otros troncos permanentes.
feature/<feature_name>fix/<bug_title>release/v-<version.major>.<version.minor>auto-backmerge/<pr_number> Se usa para elevar los PR a la domina para cada cambio presionado para liberar ramas YYMM.DD.NN
NN ➡️ número de parche
Ej: 2301.25.00 , 2302.01.04
master? on-merge-master.yml En cada fusión para dominar, actualizamos la versión completa. Las versiones principales y menores se modificarán si la versión existente es de una fecha anterior, de lo contrario, solo se aumentará el número de parche.
Ejemplo :
Versión existente: 2301.25.02
Si se presiona una nueva confirmación el 25 de enero de 2023, la versión se convierte en 2301.25.03
Si se empuja un nuevo confirmación el 26 de enero de 2023, la versión se convierte en 2301.26.00
release/**? en la fusión-release.yml
release* En cada confirmación actualizamos el número de parche en las ramas release*
release/** al master ? on-merge-release.yml Cada empuje para release* activará un PR correspondiente a master a través de una rama auto-backmerge/<pr_number> .
El PR se fusionará automáticamente si no hay conflictos
? Prepare-a-release.yml Cree una rama de lanzamiento del último maestro, con la versión correcta en el nombre de la rama.
Comportamiento
? create-tagged-release.yml etiqueta la última confirmación en una rama de lanzamiento con la etiqueta de versión correcta y las notas de versión
Comportamiento
%% {init: {'gitgraph': {'mainbranchname': 'maestro', 'showCommitLabel': true}}} %%
gitgraph
ID de confirmación: "? 2301.25.00"
Rama de la rama/cuadros de cuadros
ID de confirmación: "arreglar la lógica"
ID de confirmación: "Fix UI"
maestro de pago
Característica de rama/DM
ID de confirmación: "Agregar DB"
ID de confirmación: "Agregar socket"
maestro de pago
ID de corrección/marcos de fusiones: "PR: Frames Bug"
ID de confirmación: "? 2301.25.01"
Función de pago/DM
Fusionar Master ID: "Pull Master"
ID de confirmación: "Agregar ui"
maestro de pago
FUNCIONARIO FUNCIONARIO/ID DM: "PR: FIRTACIÓN DM"
ID de confirmación: "? 2301.25.02"
master (accionesmaster y vaya al paso 2 %% {init: {'gitgraph': {'mainbranchname': 'maestro', 'showCommitLabel': true}}} %%
gitgraph
ID de confirmación: "? 2301.25.02"
Liberación de rama/V-2301.25
maestro de pago
ID de confirmación: "PR: nueva función" Tipo: resaltado
ID de confirmación: "? 2301.26.00"
Vuelto a pagar/V-2301.25
Branch Fix/Release-Bug
ID de confirmación: "Se corrigió el error"
Vuelto a pagar/V-2301.25
ID de corrección/liberación de fusiones: "PR: Release Bug"
Vuelto a pagar/V-2301.25
Branch Auto-Backmerge/Release-Bug
Fusionar Master ID: "Actualizar la rama"
Vuelto a pagar/V-2301.25
ID de confirmación: "? 2301.25.03" Etiqueta: "V-2301.25.03"
maestro de pago
Fusionar Auto-Backmerge/Release-Bug ID: "Backmerge"
maestro de pago
ID de confirmación: "? 2301.26.01"
Comportamiento
Una vez que lo somos? En todas las pruebas, haga lo anterior para etiquetar la última confirmación de la rama de la versión y crear una versión de GitHub con notas de versión automatizadas. Y cargar los artefactos en las tiendas de aplicaciones
Arreglar un problema en la construcción de producción actual ( v-2301.16.01 )
v-2301.16.01 > Rama: release/v-2301.16 )El resto es el mismo que el flujo de liberación normal
%% {init: {'gitgraph': {'mainbranchname': 'versión/v-2301.16', 'showCommitLabel': true}}} %%
gitgraph
ID de confirmación: "2301.16.04" Etiqueta: "V-2301.16.04"
rama hotfix/choque
ID de confirmación: "Fix Crash"
Vuelto de pago/V-2301.16
Fusionar Hotfix/Crash ID: "PR Crash"
ID de confirmación: "? 2301.16.05"
rama hotfix/bug
ID de confirmación: "Se corrigió el error"
Vuelto de pago/V-2301.16
Fusionar Hotfix/Bug ID: "PR Bug"
ID de confirmación: "? 2301.16.06" Etiqueta: "V-2301.16.06"
La historia lineal es deseable por varias razones. Todos se reducen a la simplicidad nuevamente.
Solo permitir la fusión de la calabaza con un solo tronco es la forma más simple de lograr la historia lineal. Nadie tiene que pensar, lo correcto sucede automáticamente.
También, en general, las personas tienen una mejor disciplina con respecto a los títulos de relaciones públicas que los mensajes de confirmación, por lo que sus registros de cambio también se ven bien.
A diferencia de las aplicaciones del servidor, los procesos de lanzamiento de aplicaciones móviles tienden a ser largos. Es común tomar 2 o más semanas si incluimos el despliegue gradual a 10%> 20%> 50%> 100% mientras observamos la estabilidad y las métricas en el camino.
Mientras tanto, los contribuyentes no deben tener ambigüedad de si es seguro fusionarse para dominar en este momento.
Una vez que se realiza el lanzamiento y se etiqueta la confirmación, no tienen ningún propósito. Por eso los eliminamos después del lanzamiento.
gantt
Desarrollo y lanzamientos de la aplicación de título
dateFormat yyyy-mm-dd
Tickinterval 3day
Sección Dev 1
Característica 2: A, 2022-01-13, 15d
Fusionarse con el maestro: crítico, hito, después de a, 0d
Sección Dev 2
Característica 1: B, 2022-01-12, 2d
Fusionarse para dominar: hito, después de b, 0d
Actualización de la biblioteca ⬆️: L, 2022-01-16, 1D
Fusionarse con el maestro: crítica, hito, después de l, 0d
Función de arreglos 1 ?: B2, después de R1, 2d
Fusionar para lanzar: Milestone, después de B2, 0D
Actualización del marco ⬆️: F, 2022-01-22, 1D
Fusionarse con el maestro: crítica, hito, después de f, 0d
liberación de sección
Prepare la versión 2201.14: Milestone, después de B, 0d
Función de prueba 1: R1, después de B, 4D
Función de prueba 1: R2, después de B2, 1D
Rollout 2201.14.1 10% - 100%: R3, después de R2, 7d
Prepare la versión 2201.31: Milestone, 2022-01-31, 0D
Fusionando para dominar? es seguro y alentado incluso cuando un lanzamiento está en curso
Es un esquema de versiones basado en la fecha que también es
semver para las cuales la versión es mayor que la otra2301.16.00 > 2212.31.07 )Y lo mejor de todo evita la pregunta: ¿cuándo lanzamos esta versión? para siempre, de cualquiera en todo el equipo
Incluso si responder a la pregunta anterior no es tan importante para su equipo, es igualmente bueno, si no mejor que semver . Que, la mayoría de los equipos usan de forma predeterminada. Versiones semánticas ( semver ) tiene sentido para las bibliotecas. Los consumidores de su biblioteca quieren saber cuándo hay cambios de ruptura y cuándo no. Y los gerentes de paquetes aprovechan esta convención para actualizar de manera segura las dependencias. Los usuarios de aplicaciones móviles / tiendas de aplicaciones no tienen tales expectativas de las versiones de aplicaciones. Apenas les importa.
¡Mis equipos han estado utilizando esquemas de versiones basados en fecha durante más de un año y es genial!
