4. Merge Requests
Обзор правил
4.1. Если задача небольшая или не предусматривает обязательное тестирование, то Merge Request оформляется в ветку master
4.2. Если задача объемная или предусматривает обязательное тестирование, то Merge Request оформляется в ветку develop
4.3. В начале заголовка у Merge Request указывается номер задачи
4.4. Заголовок Merge Request должен вкратце описывать проделанную работу, которая зафиксированна в коммитах
4.5. В качестве проверяющего (Assignee) выбирается Release Manager
4.6. Если Merge Request оформлен, но задача еще находится в разработке (не доделана), то Merge Request необходимо отметить статусом WIP
4.7. Если работа над задачей закончена, то необходимо снять статус WIP с Merge Request, заполнить отчет в planfix и перевести задачу на статус Code Review
Введение
Каждый разработчик пишет код в отдельной feature ветке. Чтобы код из feature ветки попал в главную (master) и оказался на боевом сайте их нужно объединить или, по другому, слить (merge).
master и develop ветки являются защищенными, в них не получится просто так взять и через git push отправить изменения. Поэтому, для слияния веток используются специальные запросы - Merge Request-ы.
4.1. Если задача небольшая или не предусматривает обязательное тестирование, то Merge Request оформляется в ветку master
masterЕсли задача сложная, то прежде чем она попадет на боевой сайт, её лучше протестировать на development версии сайта. Но бóльшая часть задач на битриксе не требует написания сложного алгоритмического кода, очень многое решается стандартными компонентами. Поэтому:
По умолчанию будем считать, что задача не требует обязательного тестирования на dev версии сайта, если про неё не сказано иное.
Если задача не требует обязательного тестирования — запрос на слияние оформляется в ветку master. Но это не значит, что такая задача не должна быть проверена прежде чем MR будет одобрен и слит с веткой master. Разработчик должен сам убедиться в корректности работы его кода, а так же пройти Code Review.
4.2. Если задача объемная или предусматривает обязательное тестирование, то Merge Request оформляется в ветку develop
developЕсли поступившая задача, перед тем, как попасть в основную ветку проекта, должна быть обязательно протестирована — то это будет сказано в самой задаче. Merge Request в таком случае необходимо оформлять в ветку develop.
Задачи с обязательным тестированием встечаются не так часто, но все же встречаются. В их числе могут быть: переход на новый дизайн, разработка собственного модуля или компонента, разработка сайта с нуля. Это нужно для того, чтобы нам самим убедиться в корректности работы кода и ничего не сломать на боевом сайте, а так же продемонстрировать заказчику и согласовать с ним получившийся результат.
После того, как задача была протестирована и согласована - оформляется еще один MR, но на это раз уже в ветку master, после чего код задачи попадает на боевой сайт.
Если в задаче не сказано, что она требует тестирования на development версии сайта, но разработчик считает иначе (например, если затрагивается большое количество файлов или у решения задачи сложный алгоритм) он может обсудить это с TeamLead-ом.
4.3. В начале заголовка у Merge Request указывается номер задачи
При решении задачи часто бывает, что она имеет несколько Merge Request-ов. Например, первый MR содержит сам код решения задачи, а второй - исправляет ошибки в нём. Чтобы иметь возможность найти все MR-ы по определенной задаче, в начале заголовка необходимо указывать её номер.
4.4. Заголовок Merge Request должен вкратце описывать проделанную работу, которая зафиксированна в коммитах
Допустим, мы решаем задачу "1100 Оптимизировать скорость загрузки сайта". Во время её выполнения мы сделали множество коммитов, например:
1100 удаляет неиспользуемые скрипты из header-a
1100 оптимизирует подключение скриптов через Assets
1100 минимизирует css код шаблона сайта и компонентов
...
1100 оптимизирует подключение шрифтов
Все технические детали решения задачи мы уже описали в коммитах. Теперь, когда мы создаем Merge Request, нам нужно написать для него обобщенный заголовок, который в нескольких словах опишет, что мы делали. Заголовок может быть написан в свободной форме, к нему нет определенных правил. Идеальным вариантом здесь будет "1100 Оптимизация скорости загрузки сайта", как и название самой задачи.
Этот Merge Request был проверен на Code Review, принят и залит на боевой сайт. При тестировании на боевом сайте выяснилось, что разработчик случайно удалил несколько нужных скриптов, и теперь часть функционала сайта не работает, нужно это срочно исправлять. Разработчик внес соответствующие правки, зафиксировал их коммитами и снова создал Merge Request. В этом случае заголовок может быть уже таким: "1100 Исправление ошибок после оптимизации скорости загрузки сайта".
4.5. В качестве проверяющего (Assignee) выбирается Release Manager
В GitLab есть специальный пользователь - Release Manager. У него есть доступы ко всем репозиториям и права на изменение защищенных веток, таких как master и develop. Release Manager проводит code review и отвечает за доставку кода на боевые и тестовые сайты, иначе говоря, за релиз. Именно его нужно выбирать в качестве проверяющего при создании Merge Request-а.
Ответственный за релиз - это переходящая должность, cегодня его роль может исполнять один разработчик, а завтра другой. Поэтому, если в качестве проверяющего указать конкретного пользователя, но ответственным за релиз окажется другой, то он не увидит этот Merge Request, а значит не сможет его проверить и доставить код на сайт.
4.6. Если Merge Request оформлен, но задача еще находится в разработке (не доделана), то Merge Request необходимо отметить статусом WIP
Если задача еще не доделана, то ни в коем случае нельзя её проливать на боевой сайт, иначе есть риск его сломать. Если задача еще не доделана, но Merge Request уже создан, то необходимо поменить его статусом WIP (Work In Progress), чтобы Release Manager случайно его не пролил.
Для этого, в самое начало заголовка MR-a необходимо дописать WIP: или кликнуть на ссылку "Start the title with WIP:"
Такие MR-ы ответственный за релиз не будет проверять и не сможет выполнить слияние веток до нех пор, пока WIP статус не будет снят.
4.7. Если работа над задачей закончена, то необходимо снять статус WIP с Merge Request, заполнить отчет в planfix и перевести задачу на статус Code Review
После того, как разработчик закончил работу над задачей, проверил её и создал Merge Request, необходимо убедиться, что у MR-a не стоит статус WIP, иначе ответственный за релиз не сможет выполнить слияние веток.
Так же, в крточке задачи в planfix необходимо заполнить поле "Отчет" и перевести задачу в статус Code Review, чтобы уведомить проектного менеджера и TeamLead-а о её готовности к релизу.
Правила оформления отчёта к задачеLast updated
