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

Различия

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

Ссылка на это сравнение

Предыдущая версия справа и слева Предыдущая версия
Следующая версия
Предыдущая версия
foxdev_7:контроль_версий_сборка_тестирование [06.11.2017 19:12]
admin
foxdev_7:контроль_версий_сборка_тестирование [20.05.2019 15:18] (текущий)
Строка 9: Строка 9:
 Версии выпускаются один месяц фичи следующий баги и недоработки,​ далее снова фичи.(исключения по отдельным задачам возможны) Версии выпускаются один месяц фичи следующий баги и недоработки,​ далее снова фичи.(исключения по отдельным задачам возможны)
 Подробности в разделе Agile. Подробности в разделе Agile.
 +
 +
 +==== Система сборки и тестирования - CI сервер ====
 +master, devel, hotfix, integra, testing собираются и тестируются на сервере CI полностью автоматически,​ для каждого бранча отдельная виртуалка сборки.\\
 +Автоматически по циклу обнаруживаются новые коммиты и собираются новые версии,​ там же делаются автомерджи слева направо master->​devel->​ и т.д.\\
 +При изменении простейшего bash файла, пересборка должна занимать не более 15-30 секунд.\\
 +При изменении си файла добавляется время компиляции.\\
 +Система автоматического функционального тестирования обнаруживает новый билд - обновляется и тестирует.\\
 +Каждый разработчик имеет свою виртуалку с системой сборки и может выпускать свою именную версию-branch kolko1 и kolko2 ​ и может обновлять на нее свои тестовые виртуалки и клиентов.\\
 +Каждый разработчик имеет свою систему тестирования и может тестировать свою именную версию.\\
 +Система сборки умеет выкладывать версию на сервер обновлений - updater.\\
 +Также продукт может обновляться напрямую с системы сборки для быстрого тестирования в офисе разработки.\\
  
 ==== Branch ==== ==== Branch ====
Строка 23: Строка 35:
 Все изменения автоматически попадают слева направо скриптами системы сборки.\\ Все изменения автоматически попадают слева направо скриптами системы сборки.\\
 Версия testing включает все изменения и все коммиты продукта,​ и этот бранч тестируется по кругу, чтобы находить кросбаги заранее.\\ Версия testing включает все изменения и все коммиты продукта,​ и этот бранч тестируется по кругу, чтобы находить кросбаги заранее.\\
-Изменения справа налево делаются через мерджреквест другому программисту.\\ +Изменения справа налево делаются через мердж реквест другому программисту.\\ 
-Изменения из integra в devel и из devel в master делаются или тимлидом или релизменеджером строго по правилам выпуска официальной версии.\\+Изменения из integra в devel и из devel в master делаются или ментейнером или релиз-менеджером строго по правилам выпуска официальной версии.\\
  
 Пример: ​ Пример: ​
   - kolko разрабатывает фичу в ветке kolko1, это может быть много коммитов и несколько git repo.   - kolko разрабатывает фичу в ветке kolko1, это может быть много коммитов и несколько git repo.
   - собирает свою полную версию продукта kolko1 и тестирует ее.   - собирает свою полную версию продукта kolko1 и тестирует ее.
-  - делает мерджреквест в integra на обычного программиста dima. +  - делает мердж реквест в integra на обычного программиста dima. 
-  - dima смотрит все ли понятно и нет ли явных проблем в коде, при необходимости общаются через комментарии gitlab в мерджреквесте.+  - dima смотрит все ли понятно и нет ли явных проблем в коде, при необходимости общаются через комментарии gitlab в мердж реквесте.
   - dima принимает изменения из kolko1 в integra.   - dima принимает изменения из kolko1 в integra.
   - integra обкатывается на новых клиентах которым нужны новые фичи.   - integra обкатывается на новых клиентах которым нужны новые фичи.
   - за месяц накапливаются все новые фишки в ветке integra(обычно это 4 недели = 4 спринта).   - за месяц накапливаются все новые фишки в ветке integra(обычно это 4 недели = 4 спринта).
-  - раз в месяц скрипт сборки или руками делается мерджреквест из integra в devel на тимлида(или релиз менеджера) +  - раз в месяц скрипт сборки или руками делается мердж реквест из integra в devel на ментейнером(или релиз менеджера) 
-  - после просмотра кода мерджреквест принимается в devel выпускается новая версия devel +  - после просмотра кода мердж реквест принимается в devel выпускается новая версия devel 
-  - раз в несколько месяцев выпускается master мерджреквестом из devel.+  - раз в несколько месяцев выпускается master мердж реквестом из devel.
 Если есть критичные изменения они вносятся в hotfix и автоматом попадают в integra и ветки разработчиков.\\ Если есть критичные изменения они вносятся в hotfix и автоматом попадают в integra и ветки разработчиков.\\
-Утром ​тимлид ​проверяет и вносит hotfix в devel.+Утром ментейнер ​проверяет и вносит hotfix в devel.
  
 ==== Версии ==== ==== Версии ====
Строка 44: Строка 56:
 Пример:​ devel 8.3.11(312) Пример:​ devel 8.3.11(312)
 build увеличивается автоматически при сборке. build увеличивается автоматически при сборке.
-minor и release увеличивает или тимлид ​или релиз менеджер по строгим правилам.+minor и release увеличивает или ментейнер ​или релиз менеджер по строгим правилам.
  
   * Master - основная масса клиентов. Все, кто работает в продакшене минимум месяц.   * Master - основная масса клиентов. Все, кто работает в продакшене минимум месяц.
Строка 52: Строка 64:
   * Testing - это специальная ветка в которую попадают все коммиты разработчиков даже если он не были протестированы. То есть это мердж всех веток всех разработчиков.   * Testing - это специальная ветка в которую попадают все коммиты разработчиков даже если он не были протестированы. То есть это мердж всех веток всех разработчиков.
  
-Все ​эти версии собираются и тестируются на сервере CI.+==== Выпуск 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:​развертывание|Читать далее: Развертывание программ или сервисов]]+