-
Задачу выбираем из своего стека скрам-доски, во время скрама, с учетом текущих приоритетов. Скрам-мастер сдвигает задачу на колонку «1 день».
Проверяем, что у задачи стоит длительность 0.5 или 1 день. Без длительности задачу не решаем, если больше дня, то декомпозируем.
Обязательно получаем устные уточнения по задаче и устно предлагаем решение в тч интерфейс и аргументы и тп.
Если это Bug, то обязательно лично воспроизводим на своей виртуалке и только потом решаем.
до начала изменения кода, определяем: категорию, масштаб проблемы/задачи
-
если задача не «запрещённая», обсуждение проблемы и решения - приветствуется
выбираем базовую ветку в которые изменения должны попасть:
баги/хотфиксы/критичный функционал для определённой ветки. Например мастер(если баг мастера).
фичи, рефакторинг, крупные правки некритичных багов - интегра
задача всегда решается разработчиком в отдельной ветке, созданной от базовой.
если ветка старая - обновить до начала работы(pull, reset и т.д.)
запрещено решать несколько не связанных задач в одной ветке
от изменения кода до отладки не более 3 секунд, если требуется, делаем скрипт копирования только нужных файлов и рестарт нужных служб. Не делаем полную пересборку при отладке!
Всегда смотрим изменения, которые коммитим: git add -p или git commit -v. Чтобы нежелательные изменения(отладка, и т.п.) не попали в продукт
Создаем сообщение коммита русским, понятным простому пользователю языком, в обезличенной форме. Первая строка сообщения попадает в changelog и на сайт. Она должна иметь форму: «Исправлено(worker, tt32453): в некоторых случаях не выставлялся счёт». Во второй строке, и далее, могут быть более подробные пояснения для разработчиков.
Лучше больше малых коммитов, чем один очень большой.
после внесения любых изменений, обязательно тестирование. В т.ч. разработчик тестирует, что изменения не сломали код и старый функционал, тестируем что новый функционал работает как задумано, другие кейсы, которые разработчик посчитает необходимым проверить. По возможности отдаём приоритет авто-тестам
перед тестами полная пересборка продукта
отлаживаем каждую строку, даже если 1 байт исправления, в тч при исправлении комментариев, дебагов и текстовых строк, тк вероятность ошибки в каждой новой или исправленной строке всегда 100%
если Вы не можете или не хотите отладить и проверить строку, то Категорически нельзя добавлять неотлаженную строку кода т.к. Вы создадите очень очень много проблем в будущем.
после тестирования, создаём реквесты при помощи merge_name2name. Если изменялись несколько репозиториев, то использовать merge_name2name обязательно(чтобы не возникало случаев, когда часть кода не попадает в слияние)
в текст мердж реквеста тезисами пишем «как тестировали». Это напоминание, в первую очередь для себя, о правиле тестировать любые изменения. Так же для оценки(самооценки) полноты тестирования. Если не написали, то проводящий код-ревью, должен напомнить об обязательности проверки
если создали реквест преждевременно, то переводим его на себя или отменяем, в некоторых случаях допускается ставить статус WIP(например небольшие доработки). Не готовый реквест на проверяющего не вешаем. Это отвлекает.
если изменения сделаны не в той ветке, например запрос в интегру, а нужно исправить баг в мастере, то тоже пишем об этом шапке запроса, и молимся, чтобы принимающий реквест смог сделать автоматический черри пик в нужную ветку
после создания мердж реквестов, задача на скрам доске переезжает в колонку testing
ветку, где решали задачу менять нельзя, пока реквест не будет принят. Новую задачу решаем в другой ветке, например kolko2.
ревью изменений в основные ветки продукта всегда проводит другой разработчик. Кто может проводит код-ревью определяет тим-лид продукта *.dev.teamlead
ревью изменений в основные ветки платформы: base, auth, common_scripts и т.п. выполняет руководитель процесса разработки devops.head
после внесения правок по результатам ревью, выполняем пункт тестирование, обновляем реквесты
Когда задача находится в режиме приема реквеста - ответственный за нее остается исполнитель. Он заинтересован, чтобы ревьювер его не продинамил и принял мерж-реквест. Поэтому, если ревью давно не принимают - он должен подойти к ревьюверу лично. Если ревьювер занят и не может провести ревью - он говорит время, когда к нему можно подойти (см. правила решения задач).
задача считается решённой и переносится в Done, только после слияния изменений с нужной веткой. Пока реквест не принят, задача считается не решённой
Для Подтверждение закрытия задачи обязтаельно добавляем скрины и или дифф коммита в задачу или в комент.
Все разработчики раз в день (если высокая нагрузка, то реже) просматривают в gitlab список открытых на них реквестов. Если обнаружены проблемы: пишут об этом комментарий или сообщают лично, заявку при этом не закрываем - свои незакрытые реквесты просматривает разработчики. Закрытые по ошибке реквесты должны пересоздаваться спец.утилитой.
Разработчик раз в день (или чаще) просматривает список своих реквестов. Приняли ли их, что нужно исправить. Если реквест очень срочный - он может подойти к ревьюверу лично или позвонить.
Запрещено двигать задачи на скрам-доске, это делает только скрам-мастер.
Решаем только задачи которые есть на скрам-доске и прикреплена к колонке «N день».
Категорически запрещено решать задачу, если ее нет на скрам доске.
Если решили задачу раньше скрама, выбираете следующую вместе со скрам-мастером или сами если скрам-мастер разрешает.
Если возникла внеплановая аларм-задача или личная инициативная задача, то создается листок задачи и прикрепляется на колонку «1 день» и уведомляем скрам-мастера.
Ежедневно на скраме скрам-мастер сдвигает задачу на один день влево, если задача дошла до 3 дня привлекается помощник.
Если потребуются доработки будет создана отдельная задача.
git commit -am 'Deleted some files' можно использовать только для подтверждения удаления множества файлов, после внесения остальные изменения командой git add -p