Bonne journée tout le monde!
Notre société développe des logiciels pour le secteur public et certifie en permanence ses programmes de traitement gouvernemental. des secrets. Et cela impose certaines restrictions et les plus importantes d'entre elles: nous devons fournir tous les codes sources de notre projet et, si demandé, être en mesure d'expliquer ce que fait chaque ligne. Le problème est que si vous utilisez des composants prêts à l'emploi, alors leur code source doit également être fourni et pouvoir tout dire à leur sujet. Par conséquent, nous avons décidé de créer notre propre cadre, car nous saurons tout à son sujet. Nous avons créé un framework et l'avons nommé "Platform". Il continue de se développer et nous réalisons tous nos projets dessus. Le problème est qu'après la sortie du produit et sa livraison, nous devons le figer et ne pouvons pas y apporter de modifications majeures - seulement corriger les bogueset la plupart des bogues se trouvent dans le framework lui-même, et par conséquent, nous sommes obligés d'avoir des versions du framework pour chaque projet soumis (enfin, ou pour un groupe de produits publiés simultanément). En conséquence, nous avons dû créer notre propre ensemble de règles et un schéma de branchement dans GIT pour développer Platform. Le diagramme est présenté ci-dessous avec un exemple de son fonctionnement:
Règles générales pour les projets de branchement:
1. Les concepts suivants ont été introduits:
une. Version majeure du programme - la version du programme dans le cadre d'un certain concept, change avec des changements significatifs dans le concept, notée vm, où m est le numéro de la version majeure;
b. La version mineure du programme est une subversion au sein du même concept, change lorsqu'une nouvelle fonctionnalité est ajoutée ou une fonctionnalité existante est légèrement modifiée, notée vmn, où m est le numéro de la version majeure, n est le numéro de la version mineure version;
c. Version du programme - une version d'une version mineure, le numéro de version change avec des changements mineurs et / ou des corrections de bogues dans la version mineure correspondante du programme, indiquée par rmnp, où m est le numéro de version majeure, n est le numéro de version mineure, p est le numéro du patch;
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.