Bom dia a todos!
Nossa empresa desenvolve softwares para o setor público e certifica constantemente seus programas de processamento governamental. segredos. E isso impõe certas restrições e a mais importante delas: devemos fornecer todos os códigos-fonte do nosso projeto e, se solicitado, saber explicar o que cada linha faz. O problema é que, se você usar componentes prontos, seu código-fonte também deve ser fornecido e ser capaz de dizer tudo sobre eles. Portanto, decidimos fazer nosso próprio framework, pois saberemos tudo sobre ele. Fizemos um framework e o chamamos de "Plataforma". Ele continua a se desenvolver e fazemos todos os nossos projetos nele. O problema é que, após o lançamento do produto e sua entrega, temos que congelá-lo e não podemos fazer grandes alterações nele - apenas corrigir bugs,e a maioria dos bugs são encontrados no próprio framework e, como resultado, somos forçados a ter versões do framework para cada projeto enviado (bem, ou para um grupo de produtos lançados simultaneamente). Como resultado, tivemos que criar nosso próprio conjunto de regras e um esquema de ramificação no GIT para o desenvolvimento da plataforma. O diagrama é mostrado abaixo junto com um exemplo de como funciona:
Regras gerais para projetos de ramificação:
1. Os seguintes conceitos foram introduzidos:
uma. Versão principal do programa - a versão do programa dentro da estrutura de um determinado conceito, muda com mudanças significativas no conceito, denotado por vm, onde m é o número da versão principal;
b. A versão secundária do programa é uma subversão dentro do mesmo conceito, muda quando uma nova funcionalidade é adicionada ou uma existente é ligeiramente alterada, denotada por vmn, onde m é o número da versão principal, n é o número da versão secundária versão;
c. Lançamento do programa - uma versão de uma versão secundária, o número de lançamento muda com pequenas alterações e / ou correções de bugs na versão secundária correspondente do programa, denotada por rmnp, onde m é o número da versão principal, n é o número da versão secundária, p é o número do 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.