Сложна стратегия за разклоняване и внедряване с гит

Целта на този документ е да определи общите минимално изисквани политики и действия на организацията за КОМПЛЕКСНАТА стратегия за разклоняване и процеса на внедряване, които трябва да се извършват по време на жизнения цикъл на приложеният.

Стандартната структура за внедряване на приложения използва следните среди:

локална среда за разработка (lde)
разработка (dev)
тестова (stg)
продукция (prd)
master

Това се превежда като стандартен набор от три клона във всички хранилища на приложения:

Клон	Среда
`master`	Политически по-важен от `prd`, това означава, че не само работи в продукция за ЕДИН клиент, но също така това е публичното издание за всяка инстанция на кода.
`prod`	съдържа в момента работещия код в продукционната среда
`release`	съдържа текущия общ код, който ще бъде пуснат в продукционната среда при следващото издание
`staging`	съдържа общия код, който работи в `тестова` (stg) среда
`stg`	съдържа общия код, който ще бъде внедрен в `тестова` (stg) среда
`develop`	съдържа общия код, който в момента работи в `разработващата` (dev) среда
`<<ticket-id>>-<<feature-name>>`	съдържа изходния код, който се разработва от разработчиците в техните собствени локални среди за разработка (локална), както и в някои случаи код в `разработващата` (dev) среда

Следните оперативни насоки трябва да се спазват:

Всички клонове се възстановяват отгоре надолу от таблицата по-горе ^^^ – това означава например, че корекциите в продукция ТРЯБВА да се прилагат към всички клонове под нея в следния ред – develop, stg, staging, production към всеки функционален клон, който е в процес на разработка в момента на приложението
Когато се разработва нова функционалност, разработчикът ще създаде нов функционален клон от последната версия на develop клона. Функционалният клон трябва да следва develop, тоест rebase.
Функции, които добавят сложност, но не предоставят тестове с CI внедряване на тези тестови сложности НЕ ТРЯБВА да се добавят към никакви от общите клонове (проверете конкретните стъпки, които трябва да се следват)
Когато новоразработената функционалност е готова за включване, разработчикът създава pull заявка, като иска да обедини своя функционален клон с клона develop.
Pull заявката се преглежда от поне още един член на екипа и се обединява в клона develop АКО преглеждащият одобри заявката и всички променени компоненти на микросервиса са тествани.
Внедряването в stg средата се извършва от клона stg, за да бъде достъпно за тестване от нетехнически потребители.
Ако внедряването на клона stg има проблеми или ако нетехническите потребители не одобряват последното внедряване в средата staging, се извършва връщане (rollback).
Когато клонът staging бъде тестван от нетехнически потребители в stg средата и се счита за готов за продукция, отговорният за внедряването на функционалността слива функционалността в клона release (с флаговете -X theirs и --allow-unrelated-histories) и го маркира с нова версия, за да позволи идентификацията на състоянието на кода с извикването на git push --tags.
Внедряването в продукционната среда се извършва от клона release.
АКО бизнес представителите намерят грешка в продукцията, която може да бъде отстранена за по-малко от 4 часа, се създава клон hotfix от клона release и бързо се внедрява първо в stg средата, и ако всички тестове преминат бързо и там, се внедрява в продукцията с нов етикет. Ако отстраняването на грешката отнема повече от 4 часа, трябва да се създаде приоритетен-1 бъг и да се следва процесът за внедряване без горещи поправки (non-hotfix).
След като бизнес представителите одобрят новата версия в продукционната среда, съществуващият клон prod се възстановява (rebase) с клона release – издаденият етикет на git става новият „източник на истина“ – тоест каква е текущата версия на софтуера, работеща в продукционната среда.
АКО бизнес представителите не одобрят новата версия, се извършва връщане (rollback) към предишния продукционен commit.
След изданието ВСИЧКИ общи (develop и release) клонове се възстановяват (rebase) от клона develop от лицето, което извършва изданието. Всички останали разработчици ТРЯБВА също да възстановят своите функционални / корекционни клонове от клона develop – всеки разработчик трябва да се увери, че разликата (diff) между общия клон develop и текущия функционален / корекционен клон, върху който работи, съдържа САМО промените, свързани с текущата грешка/функционалност, върху която той/тя работи.

ЗАБЕЛЕЖКА: Внедряванията в живите среди трябва винаги да се извършват чрез автоматизирани CI/CD процеси, никога ръчно. В описания по-горе процес всички премествания между средите се извършват чрез системата за контрол на изходния код в GitLab.

Всяко внедряване в различни среди трябва да бъде податливо на ръчно стартиране чрез потребителския интерфейс на системата за управление на изходния код и нейният DevOps интерфейс.