Путь Github. Цикл разработки

Разработка

Я расскажу о цикле разработки через 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