Контроль Версий Сборка Тестирование

Здесь показаны различия между двумя версиями данной страницы.

--- foxdev_7:контроль_версий_сборка_тестирование [06.11.2017 17:55]
admin ↷ Имя страницы open_carbon_7:сборка_и_тестирование изменено на open_carbon_7:контроль_версий_сборка_тестирование
+++ foxdev_7:контроль_версий_сборка_тестирование [20.05.2019 15:18] (текущий)
@@ Строка 1: / Строка 1: @@
 {{indexmenu_n>40}}
+==== Общий подход ====
+Каждый разработчик имеет свою виртуалку с системой сборки и может выпускать свою именную версию-branch kolko1 и kolko2  и может обновлять на нее виртуалки и клиентов.\\
+Каждый разработчик имеет свою систему тестирования и может тестировать свою именную версию.\\
+В carbon не создается бранч для каждой задачи, есть 2 или более именных branch kolko1 и kolko2 kolko3 для решения текущий задачи, и срочных задач.\\
+Есть центральный сервер сборки и тестирования, на нем выпускаются официальные версии, которые выкладываются на updater.carbonsoft.ru.\\
+Спринт - неделя с обязательной доской и скрамом.
+Версия - 4 спринта = 1 месяц, если спринтов меньше, то версия все равно выходит раз в месяц до 10 числа.
+Версии выпускаются один месяц фичи следующий баги и недоработки, далее снова фичи.(исключения по отдельным задачам возможны)
+Подробности в разделе Agile.
-==== Система сборки ====
-==== Тестирование ====
+==== Система сборки и тестирования - CI сервер ====
+master, devel, hotfix, integra, testing собираются и тестируются на сервере CI полностью автоматически, для каждого бранча отдельная виртуалка сборки.\\
+Автоматически по циклу обнаруживаются новые коммиты и собираются новые версии, там же делаются автомерджи слева направо master->devel-> и т.д.\\
+При изменении простейшего bash файла, пересборка должна занимать не более 15-30 секунд.\\
+При изменении си файла добавляется время компиляции.\\
+Система автоматического функционального тестирования обнаруживает новый билд - обновляется и тестирует.\\
+Каждый разработчик имеет свою виртуалку с системой сборки и может выпускать свою именную версию-branch kolko1 и kolko2  и может обновлять на нее свои тестовые виртуалки и клиентов.\\
+Каждый разработчик имеет свою систему тестирования и может тестировать свою именную версию.\\
+Система сборки умеет выкладывать версию на сервер обновлений - updater.\\
+Также продукт может обновляться напрямую с системы сборки для быстрого тестирования в офисе разработки.\\
+==== Branch ====
+<code>
+                                dima1
+                             /          \
+master→devel→hotfix→integra → kolko1 → testing
+   \                       | \         / |
+    master_hotfix          |   anton1    |
+                            \           /
+                               sergey1
+</code>
+Все изменения автоматически попадают слева направо скриптами системы сборки.\\
+Версия testing включает все изменения и все коммиты продукта, и этот бранч тестируется по кругу, чтобы находить кросбаги заранее.\\
+Изменения справа налево делаются через мердж реквест другому программисту.\\
+Изменения из integra в devel и из devel в master делаются или ментейнером или релиз-менеджером строго по правилам выпуска официальной версии.\\
+Пример:
+  - kolko разрабатывает фичу в ветке kolko1, это может быть много коммитов и несколько git repo.
+  - собирает свою полную версию продукта kolko1 и тестирует ее.
+  - делает мердж реквест в integra на обычного программиста dima.
+  - dima смотрит все ли понятно и нет ли явных проблем в коде, при необходимости общаются через комментарии gitlab в мердж реквесте.
+  - dima принимает изменения из kolko1 в integra.
+  - integra обкатывается на новых клиентах которым нужны новые фичи.
+  - за месяц накапливаются все новые фишки в ветке integra(обычно это 4 недели = 4 спринта).
+  - раз в месяц скрипт сборки или руками делается мердж реквест из integra в devel на ментейнером(или релиз менеджера)
+  - после просмотра кода мердж реквест принимается в devel выпускается новая версия devel
+  - раз в несколько месяцев выпускается master мердж реквестом из devel.
+Если есть критичные изменения они вносятся в hotfix и автоматом попадают в integra и ветки разработчиков.\\
+Утром ментейнер проверяет и вносит hotfix в devel.
+==== Версии ====
+branch - major.minor.release(build)\\
+Пример: devel 8.3.11(312)
+build увеличивается автоматически при сборке.
+minor и release увеличивает или ментейнер или релиз менеджер по строгим правилам.
+  * Master - основная масса клиентов. Все, кто работает в продакшене минимум месяц.
+  * Devel - новые клиенты, не проработавшие 1 месяц, сайте в разделе download и является свежей, отлаженной и протестированной. При выходе следующего master с версией больше этого devel, клиент автоматически переходит на этот master будет иметь те же фичи, но еще более стабильную версию.
+  * Hotfix - срочные исправления от разработчиков для devel. Для master hotfix обычно выходит черипиками или стабильным форком вида master→master_kolko1
+  * Interga - ветка для объединения изменений разработчиков. Накапливает изменения за месяц фичи, тюнинг, вебка, не критикал баги и из нее формируется новая официальная версия Devel.
+  * Testing - это специальная ветка в которую попадают все коммиты разработчиков даже если он не были протестированы. То есть это мердж всех веток всех разработчиков.
+==== Выпуск official devel версий ====
+В конце месяца строго до 10 числа выпускается devel версия и делается новость на сайт и рассылка по клиентам и pr-агентствам.\\
+Выпуск official-версии должен выполняться только утром с понедельника по четверг.\\
+Алгоритм:
+  - Текущие версии master=8.2.7 devel=8.3.1 integra=8.4.0
+  - Выпуск master. Мейнтейнер просматривает мердж реквест из devel в master на предмет подозрительного и мусора. Если все ОК принимает мердж. Мейнтейнер устанавливает руками верcию master равную devel, и release увеличивает на+1. Пример devel=8.3._1_ master=8.3._2_
+  - Выпуск devel. Мейнтейнер просматривает мердж реквест из integra в devel на предмет подозрительного и мусора. Если все ОК принимает мердж. Мейнтейнер устанавливает руками верcию devel равную integra, и release увеличивает на+1. integra=8.4._0_ devel=8.4._1_
+  - Запускаем новую integra 8.5.0
+==== Hotfix devel ====
+  * Исправления для devel разработчики пушат в hotfix и они автоматом попадают в interga и далее другим разработчикам, но не попадают в devel.
+  * Мейнтейнер раз в день просматривает мердж реквест из hotfix в devel на предмет мусора и подозрительных вещей.
+  * Если все ОК принимает мердж и release увеличивает на+1. Пример devel=8.3._2_ master=8.3._3_
+  * Если изменения требуются и для master можно сделать черипик
+==== Hotfix master ====
+  * Разработчик в ветке master_hotfix вносит исправления и тестирует их
+  * Если все ок Мейнтейнер просматривает и вносит master_hotfix в master
+==== Версии с клиентскими доработками. ====
+  * Все доработки под конкретного клиента делаются в ветке integra и проверяются сразу у клиента.
+  * Сложных затянутых ситуациях клиенту выделяется отдельная именная ветка с полным набором CI виртуалок.
+  * Если клиент находится на персональной ветке или на integra, то он считается не до конца интегрированным и обновляется в пределах своей ветки. Переход на devel или master делает тех.поддержка вручную, после слияния веток.
+==== Версия testing ====
+  * testing это специальная ветка в которую попадают все коммиты разработчиков даже если он не были протестированы. То есть это мердж всех веток всех разработчиков.
+  * testing тестируется по кругу в облаке CI, при нахождении ошибок они сообщаются всем разработчикам чьи коммиты появились с последнего удачного тестирования или просто всем.
+  * Все мердж конфликты рулят их создатели сообща и срочно.
+==== Схема обновления. ====
+  * Клиент скачивает с сайта версию devel 8.3._1_
+  * В течение месяца обновляется на свежие релизы devel 8.3._2_ 8.3._3_
+  * Как только в конце месяца выйдет новый master он будет старше, чем devel версия клиента клиента и клиент перейдет на мастер. Клиент переходит на master если версия мастера(8.3.4) старше, чем версия клиента(8.3.3), несмотря на то, что есть версия official devel(8.4.1) старше, чем master.
+  * Обновления должны попадать не сразу всем клиентам, а порциями случайных клиентов в день. (например 4-8-16-32-64и далее). До 25 числа должны все обновиться.
+  * Блокировка обновления разрешена: на 2 часа - для известного бага, на 2 дня - для плавающего, который не удается установить. При просрочке сразу звоним руководителю. В блокировке обязательно указываем почему заблокировано и кто заблокировал и дату.
+==== Прием изменений и codereview через мердж реквест ====
+  * Разработчики разрабатывают все в своих ветка их должно быть ограниченное колво 2-10, но как минимум две ${login}1 ${login}2
+  * Для каждой версии должны быть подняты виртуалки makedistro и autotest на машине разработчика средствами утилиты crab
+  * Все коммиты попадают из версии разработчика в integra через мердж реквест к другому разработчику, который делает codereview.
+==== Выкладывание master новых оф версий ====
+Обычно делается реже чем devel, либо обновления притормаживаются.\\
+Но все зависит от продуктов.\\
+[[foxdev_7:тестирование|Читать далее: Развертывание программ или сервисов]]
+~~OWNERAPPROVE~~
-[[open_carbon_7:команды agile scrume|Читать далее: команды agile scrum]]

Контроль Версий Сборка Тестирование

Различия