¡Buen día a todos!
Nuestra empresa desarrolla software para el sector público y certifica constantemente sus programas de procesamiento de gobierno. misterios. Y esto impone ciertas restricciones y la más importante de ellas: debemos proporcionar todos los códigos fuente de nuestro proyecto y, si se nos solicita, poder explicar qué hace cada línea. El problema es que si utiliza componentes prefabricados, entonces también debe proporcionar su código fuente y poder contar todo sobre ellos. Por eso, decidimos hacer nuestro propio framework, porque lo sabremos todo al respecto. Creamos un marco y lo llamamos "Plataforma". Sigue desarrollándose y realizamos todos nuestros proyectos en él. El problema es que, después del lanzamiento del producto y su entrega, tenemos que congelarlo y no podemos realizar cambios importantes en él, solo corregir errores,y la mayoría de los errores se encuentran en el marco mismo y, como resultado, nos vemos obligados a tener versiones del marco para cada proyecto enviado (bueno, o para un grupo de productos lanzados simultáneamente). Como resultado, tuvimos que idear nuestro propio conjunto de reglas y un esquema de ramificación en GIT para desarrollar Platform. El diagrama se muestra a continuación junto con un ejemplo de cómo funciona:
Reglas generales para proyectos de ramificación:
1. Se han introducido los siguientes conceptos:
a. Versión principal del programa: la versión del programa dentro del marco de un cierto concepto, cambia con cambios significativos en el concepto, indicado por vm, donde m es el número de la versión principal;
segundo. La versión menor del programa es una subversión dentro del mismo concepto, cambia cuando se agrega una nueva funcionalidad o se altera levemente una existente, denotado por vmn, donde m es el número de la versión mayor, n es el número de la menor versión;
C. Lanzamiento del programa: una versión menor, el número de lanzamiento cambia con cambios menores y / o correcciones de errores en la versión menor correspondiente del programa, denotado por rmnp, donde m es el número de versión principal, n es el número de versión menor, p es el número de parche;
2. master. master , merge-request. merge-request (code review).
3. ( ). master, : dev-v-m, m – . master. dev-v-m project_name_dev_v_m. .
4. – , . . :
a. t-xxxxx, (xxxxx – )
b. b-xxxxx, (xxxxx – ).
5. , , .
6. , , , v-1-1 ( , ). master, . master , () .
7. ( ) . – . v-m-n, m – , n – . . , . r-m-n-p, m – , n – , p – ( ). . , . , .
8. , .
9. , .
10. , , .. . master . , , , ( ). , .
11. , .
12. : t-#####-taskname b-#####-bugname.
, . :
01.01.17 C1 master. master . , ( ) . , 1 2 . C1 (t-####) t-1 t-2. (, t-1 t-1-C1 t-1-C2). , , . merge request , .. , , . code review ( ). , merge request , . code review, merge request C2 3. master . , , , .
08.01.17 1-0 v-1-0. v-1-0 . v-1-0 . . b-1 b-3 merge request’ v-1-0. , merge request v-1-0 v-1-0-C1, v-1-0-C2 v-1-0-C3. , , .
master , v-1-1. master .1 , , . , C4, b-2 merge-request master v-1-0, .. .
01.02.17 v-1-0, , . r-1-0-1. . v-1-0 , .. , master.
-1-0-1 b-3 v-1-0 08.02.17 - r-1-0-2. , v-1-1 v-1-1. master v-2-0. v-1-0, v-1-1. b-4, v-1-0 master, .. , , .
04.03.17 r-1-1-1. 1 2. v-1 , (dev-v-1) ( ). dev-v-1 master, v-1. v-1-0, , .. v-1-1.
15.03.17 v-2-0 v-2-0.
18.03.17 v-1 v-1-2.
01.04.17 v-1 (r-1-2-1) v-2 (r-2-0-1). v-1-1, .. v-1-2.