Разработка
Я расскажу о цикле разработки через Github, который я использую. Он был проверен в течении года на командах разного размера: 3 — 14 человек.
Существует 2 основных ветки: master и dev.
master — стабильная ветка, готовая к выкатыванию на production сервер в любой момент.
dev — ветка, над которой в данный момент работает команда.
Итак, в начале разработки master и dev ветки идентичны.
1. Когда программист начинает работу над новым дефектом / функционалом, он должен переключиться на ветку dev и получить ее последнюю версию.
git checkout dev
git pull origin dev
2. К примеру, разработчик хочет начать исправлять дефект страницы аутендификации. Номер ошибки на Github — 12345. Разработчик должен создать новую ветку из dev
git checkout -b 1234-bug-login
1234-bug-login это только пример. Первым словом должен быть номер дефекта, вторым — bug / feature, а дальше — описание проблемы.
3. Далее разработчик продолжает работу локально: делает изменения, коммиты и т.д. Commit-cообщения должны содержать номер ошибки и техническое описание
git add ...list of files...
git commit -m "#1234 changing backbone model url"
4. Итак, разработка окончена, и теперь необходимо отправить изменения на Github
git push origin 1234-bug-login
Все изменения теперь в репозитории. После этого разработчику необходимо обновить свою ветку из dev, чтобы иметь возможность слить ее без конфликтов.
Сперва необходимо получить последнюю версию dev ветки
git checkout dev
git pull origin dev
И затем влить все изменения, которые произошли в dev ветке, в свою ветку (1234-bug-login)
git checkout 1234-bug-login
git rebase dev
git push -f origin 1234-bug-login
5. Отлично! Ветка с решенными конфликтами в репозитории. Теперь разработчик делает Сreate Pull Request из 1234-bug-login в dev ветку при помощи Github. Так же необходимо разместить ссылку на задачу (#1234) в описании Pull Request.
6. Pull Request отправлен, любой разработчик может сделать code review, написать комментарии, уточнения и т.д.
Комментарии должны быть исправлены и отправлены на Github обычным способом. Pull Request обновится автоматически.
7. Иногда, исправления занимают некоторое время, и другие разработчики уже слили свои ветки с dev. В этом случае есть 2 варианта:
— кнопка Merge pull request на Github активна. Это означает, что изменения других разработчиков не конфликтуют с текущими изменениями, и ничего дополнительного делать не требуется.
— кнопка Merge pull request неактивна. Необходимо вернуться к пункту 4) и заново слить и отправить изменения из dev ветки в 1234-bug-login.
git checkout dev
git pull origin dev
git checkout 1234-bug-login
git rebase dev
git push -f origin 1234-bug-login
8. Отлично! Все изменения сделаны, и кто-то написал комментарий «merge it» в Pull Request. Пора нажимать кнопку Merge pull request, чтобы влить изменения 1234-bug-login в dev ветку.
Тестирование
9. Как только 1234-bug-login попадает в dev, Jenkins (система непрерывной интеграции) автоматически обновляет dev сервер из dev ветки. QA могут начинать тестировать и как итог подтвердить или переоткрыть задачу.
10. Если Pull Request вносит много изменений, разработчик может при помощи Jenkins загрузить свою ветку на qa сервер для проверки тестерами.
Релиз
11. Перед обновление production сервера необходимо влить dev ветку в master. Для этого мы создаем Pull Request из dev в master при помощи Github и нажимаем Merge pull request, вот и все. При выполнении предыдущих пунктов, никаких конфликтов быть не будет.
12. Если регрессионное тестирование успешно закончено, можно обновлять production сервер, при этом берется последний пакет (тот, на котором проходимо тестирование), и именно он устанавливается на production сервер.
13. Иногда QA находят ошибки во время регрессионного тестирования. В этом случае исправления выполняются по стандартной схеме, исключая то, что ветка создается и сливается не из dev, а из master. После релиза необходимо влить исправления из master в dev.
git checkout master
git pull origin master
git checkout dev
git pull origin dev
git merge master
git push origin dev
Автор: ArtyomTrityak
