Как организовать процесс разработки продукта на C++, используя GIT?

Question

[Unhandled_Exception]

У нас проект на С++ для Windows.

Процесс сейчас у нас поставлен таким образом.

Используем svn. В trac создается тикет, на каждый тикет создается ветка. Когда разработчик считает, что все в ветке сделал, я смотрю на код, если все выглядит хорошо, то делаю мердж в trunk и вручную прогоняю функциональные тесты. Если все ок, то делаю коммит в trunk. Таким образом, trunk всегда стабилен.

Решил улучшить процесс, чтобы большая часть работы выполнялась автоматически, заодно перейти на git (в котором я пока не специалист, увы).

Будет ветка development и ветка production. Ветка production всегда содержит только тот код, который прошел тесты. Ветка production - для текущей разработки.

Вижу процесс таким образом: создается тикет, далее создается ветка (от development), в которой работает разработчик. Он пишет код и добавляет тесты для проверки новой функциональности.

Когда он считает, что разработка завершена, то выставляет в тикете статус "Seems to be ready". Это отслеживает специальный скрипт, который по выставлению статуса мерджит ветку в development (но не коммитит).

Если произошел конфликт при мердже, то тикет опять переходит в статус "Open".

Если все смерджилось, то код собирается, потом прогоняются тесты. Если тесты не прошли, то тикет опять переходит в статус "Open".

Если тесты прошли, то - если бы тут был svn, то было бы сделано svn commit в development, не знаю как в git, а тикет закрывается.

Меня пугает такой сценарий: пока прогоняются тесты development может измениться, и нету гарантии, что после мерджа development останется стабильным (т.е. тесты проходят). Ведь мы брали старую ревизию development-а.

Хорошо, думаю я, в таком случае надо делать мердж и коммитить его в development, а уже потом прогонять тесты, но тогда новые ветки могут быть созданы от нестабильной версии development. Кроме того, пока мы прогоняем тесты для этого коммита в development, может подоспеть мердж другого бранча (а то и нескольких!), и соответствующий ему прогон тестов покажет ошибки, как первого бранча, так и второго, что всех может здорово запутать. Наконец, не вполне ясно, как делать откат, если тесты не прошли.

Как лучше всего организовать процесс?

Answer 1

[Александр Литвинов]

Советую посмотреть Git flow (habrahabr)
Git flow (GitHub) для автоматизации рутинных задач.
Branching model

Comments

[Unhandled_Exception]

Спасибо! Как раз прочитал заметку git flow, но все еще не могу сообразить, когда именно надо прогонять тесты, и как гарантировать стабильность develop.

[Александр Литвинов]

Если речь об автоматических тестах, думаю лучше прогонять при push в bare репозиторий, что бы сразу выявлять баги. Это можно сделать, например через git hooks Тестируется приложение на ветке release, перед выкладыванием на продакшн (На мастер ветку посути).

[Unhandled_Exception]

@Sander_Li Все осложняется тем, что тесты прогоняются достаточно долгое время. Знаю, что плохо, но прогон занимает больше 15 минут. Не получится ли, что гит не будет пропускать коммиты, пока работает хук...

[Александр Литвинов]

@Unhandled_Exception Еще разок git hooks. Есть возможность прогонять тесты, практически как вам угодно. Например, посмотрите в статье в сторону post-commit. Также могу посоветовать интересный репозиторий для запуска PHP Codesniffer.

[Олег Илюшин]

Все разработчики работают в своих фичах/фиксах. В девелоп или релиз пушится не так часто. Так что 15 минут не такая уж проблема.

У нас в команде хуки настроены как раз на запуск тестов по пушу в develop ветку bare репозитория. Подход позволяет своевременно выявить баги и конфликты.

Answer 2

[Сергей Протько]

то что вы описывается называется feature-branch.
ваши фича-брэнчи должны всегда быть синхронизированны с мастером. У всех разработчиков должна быть актуальная версия кода, с которым они работают. В этом смысле подход с feature-branch, особенно когда речь идет о больших изменениях, может сильно рассинхронизировать код между разработчиками.

Мне больше нравится подход с Feature Toggle, так как он более соответствует философии git.

Answer 3

[Алексей Киселев]

Почитайте про набирающую популярность модель ветвления Trunk Based Development.
При использовании этой модели вам потребуется ветка master (trunk) и ветки для релизных версий. В master вы ведете разработку (в вашей терминологии это development) для каждой версии выходящей к пользователям вы создаете отдельную ветку, например 1.0.x.
Самое главное: все изменения вносятся разработчиками только в ветку master. Только ответственные люди могут создавать релизные ветки и переносить изменения из master в них, в том числе и при внесении изменений в выпущенные версии. Релизы
собираются только с релизных веток.

В этой модели разработчики не ограниченны в создании локальных веток, но их никто не хочет видеть на общем сервере. У разработчиков нет прав на создание веток на общем сервере.

Процесс выглядит так:
1. Разработчик делает pull master.
2. Если нужно создает локальную ветку и работает в ней.
3. Прогонят тесты на ветке и мержит ее с master.
4. Делает push.
5. CI видит новый коммит, получает его и выполняет на нем модульные, интеграционные и приемочные тесты.

Я не очень понимаю, для чего могут потребоваться автоматические коммиты, мое мнение - этот процесс должны контролировать люди. А задачи в issue-tracker должны закрывать тестеры или разработчики, если они написали соответствующие тесты.

В том, что на CI не пройдут тесты нет ничего страшного. Он вообщем-то для этого и нужен. Откатывать коммит не нужно, нужно быстрее делать новый, в котором ошибка исправлена.