1. Цикл работы над задачей
Данный раздел в общих чертах описывает стандартный процесс работы разработчика над задачей.
Обзор цикла работы над задачей
1.1. Получение задачи и взятие её в работу
1.2. Развёртка локальной копии сайта
1.3. Создание ветки, в которой будет решаться задача
1.4. Решение задачи с фиксацией каждого шага в GIT
1.5. Отправка ветки с кодом решения задачи в центральный репозиторий и создание Merge Request
1.6. Прохождение Code Review и внесение корректировок
1.7. Доставка кода на сайт (релиз), внесение правок в параметры компонентов (если требуется)
1.8. Тестирование
1.9. Закрытие задачи
1.1. Получение задачи и взятие её в работу
Постановка задач и смена их статусов осуществляется в planfix. Перед тем, как приступать к работе, необходимо сменить статус выбранной задачи с "в ожидании" на "в работе". Сделать это можно просто перетащив карточку задачи в соответствующую колонку. При этом, заказчику придет уведомление о том, что его задачу взяли в работу.
Если по описанию задачи не совсем понятно, какой результат хочет получить заказчик, то можно попросить по ней уточнения у проектного менеджера.
Если не совсем понятно, каким способом или как правильней реализовать задачу, то это можно обсудить с teamlead-ом.
Если у вас нет доступа к административной части сайта, то её можно запросить у проектного менеджера или у teamlead-a.
1.2. Развёртка локальной копии сайта
Вся работа над задачей должна происходить в копии сайта, и для этого нужно развернуть её на локальном компьютере. Копия сайта состоит из 3х частей: файлов сайта, ядра сайта, и базы данных.
В качестве сервера для разработки используется OpenServer.
Файлы сайтов хранятся в нашем GitLab, к ним относятся все файлы сайта кроме папок bitrix и upload. GitLab - это центральное хранилище, в котором лежат все наши Git репозитории. Для развертки локальной копии сначала нужно, чтобы вам выдали доступ к репозиторию требуемого сайта (запросить доступ можно у teamlead-а), а затем склонировать его себе на компьютер — git clone [repository-url] [folder] , где [repository-url] путь к центральному репозиторию (на скриншоте ниже), а [folder] имя папки, в которую будет склонирован репозиторий (. для текущей папки)
В ядро сайта входит папка bitrix, это копия папки с production сервера. Она архивируется, и архив с ней помещается в наш OneDrive. Следующим шагом разархивируется ядро сайта, в ту же папку, куда был склонирован репозиторий
И третья часть — это дамп базы данных, который делается так же с production сайта. На локальном компьютере необходимо создать новую базу данных и залить в нее данные из дампа.
🎆Развертка локальной копии сайтаЕсли копия уже развернута, то стоит подумать, а не устарела ли она, возможно нужна более свежая версия базы данных или ядра. Если свежей копии базы данных или ядра сайта нет, то её можно запросить у teamlead-а.
В некоторых случаях работу разрешается выполнить на production сайте. О том, когда работу нужно делать в локальной копии сайта и когда можно выполнить её на production сайте, написано в соответствующем разделе данного регламента.
1.3. Создание ветки, в которой будет решаться задача
Так, как над одним проектом могут работать сразу несколько разработчиков, то для того, чтобы уменьшить количество конфликтов и не мешать друг-другу, каждый должен вносить изменения в своей ветке. Подробнее о создании веток рассказывается в соответствующем разделе данного регламента.
2. Работа с ветками1.4. Решение задачи с фиксацией каждого шага в GIT
При выполнении любой задачи разработчик обычно строит у себя в голове примерный план её решения. Например, для того чтобы решить эту задачу, мне нужно:
Скопировать стандартный компонент, чтобы в дальнейшем его можно было изменять
Переделать разметку и переписать стили
Написать JavaScript код, который будет решать задачу
Каждый такой шаг желательно зафиксировать отдельным коммитом в GIT. О том, как оформлять коммиты, рассказывается в соответствующем разделе данного регламента .
3. Оформление коммитов1.5. Отправка ветки с кодом решения задачи в центральный репозиторий и создание запроса на слияние с главной веткой
Момент, когда отправлять свою ветку в центральный репозиторий (git push) разработчик выбирает на своё усмотрение. Это может быть, например, в конце рабочего дня, по окончанию работы над задачей или же после каждого коммита. Нужно это для удобства самого разработчика, на случай, если вдруг понадобиться поработать с другого устройства, чтобы можно было получить свои изменения в коде с центрального репозитория проекта в GitLab.
Не забывайте переодически выполнять git push origin feature/xxxx. Иногда может потребоваться продолжить работу из другого места, например из дома. Если уже зафиксированные изменения будут в центральном репозитории, их можно будет получить себе на другом устройстве и продолжить работу.
Когда задача выполнена и протестирована на локальной копии, необходимо убедиться, что все коммиты из локальной ветки были отправлены в GitLab, и создать там Merge Request - запрос на слияние вашей ветки с основной веткой проекта. Подробнее о создании Merge Request написано в соответствующем разделе данного регламента.
После создания запроса на слияние необходимо перевести задачу из статуса "в работе" в статус "Code Review".
4. Merge Requests1.6. Прохождение Code Review и внесение корректировок
После оформлении запроса на слияние и смены статуса задачи на "Code Review", код решения задачи просматривается другим, более опытным разработчиком. Это нужно для того, чтобы избежать возможных ошибок перед релизом, выявить слабые места в коде или подсказать другое, чуть более оптимальное решение.
Code Review проводится через интерфейс GitLab. Там проверяющий оставляет комментарии к коду для рекомендаций, обсуждения, или уточнения деталей реализации задачи. Проверяющий может по своему усмотрению не допустить код к слиянию до того момента, пока не будут внесены рекомендуемые исправления.
1.7. Доставка кода на production сайт (релиз), внесение правок в параметры компонентов (если требуется)
Если код решения задачи был одобрен проверяющим на Code Review, то ветка разработчика сливается с основной веткой сайта и новый код доставляется на production сайт. После этого, ответственный за релиз переводит задачу разработчика из статуса "Code Review" в статус "на проверке". Когда код был доставлен на production сайт, разработчику разрешается внести изменения в переменные настроек, константы или параметры компонентов на production сайте, если это требуется для обеспечения работы кода.
Так же, после перевода задачи на статус "на проверке", заказчику приходит автоматическое письмо о том, что работа была выполнена и код доставлен на production сайт. Поэтому, если требуется внести изменения в параметры компонентов, делать это нужно, по возможности, сразу после доставки кода.
Подробнее о правилах проведения релиза написано в соответствующем разделе данного регламента.
1.8. Тестирование
После релиза проводится тестирование, как с нашей стороны, так и со стороны заказчика. Цель тестирования - проверить, действительно ли поставленная задача была выполнена так, как и требовалось, не возникает ли ошибок.
Если во время тестирования обнаруживаются ошибки или несоответствия, то задача из статуса "на проверке" переводится в статус "корректировки". Разработчику необходимо внести требуемые изменения в коде, зафиксировать их коммитами, снова создать запрос на слияние, и перевести задачу в статус "Code Review" (повторно выполняются все действия, начиная с четвертого пункта данного раздела, до тех пор, пока не будут исправлены все несоответсвия или ошибки).
1.9. Закрытие задачи
Если во время тестирования ошибки или несоответствя не обнаруживаются, то, после того, как заказчик примет работу, задача переводится в статус "закрытая". Закрыте задачи больше не могут быть переведены обранто, в другие статусы.
Last updated
