Всем привет,

У нас проект на С++ для Windows. Пишем на VC++, тикеты в trac, репозиторий svn.

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

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

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

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

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

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

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

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

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

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

Что же, в таком случае надо делать мердж бранча и коммитить его в development, а уже потом прогонять тесты?

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

Можно было бы тесты прогонять в git hook, но они прогоняются довольно долго. Не получится ли так, что нельзя будет делать новые коммиты пока хук не отработал свое? Ну а как еще гарантировать, что каждая ревизия development стабилльна...

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

Имхо вы пытаетесь натянуть стереотипы работы с svn на git.
В git'e у каждого свой репозиторий, коммит -> фиксация изменений в своем репозотории, потом push -> на сервер в свою ветку, далее слияние на сервере с development. Прогоны тестов с development. Пока запущены прогоны сливаться с development запрещено. Если тесты прошли успешно слияние development с prodution.
Вот как-то так, широкими мазками.

Здравствуйте, Unhandled_Exception, Вы писали:

U_E>Процесс сейчас поставлен таким образом.
....
U_E>Как лучше всего организовать процесс? У кого какая практика?

Вообще странный у вас процесс. Но мало входных характеристик. Количество кода, количество девелоперов, что такое тикет(описание бизнес функционала, или просто задача), среднее время выполнения тикета.
Мне непонятно за чем тикет=ветка, уж тем более в svn. Поиски корней в таком code base — скорее всего ахтунг.

По вашему описанию создается чувство, что у вас слишком сильная защита от того, чтобы девелопер, что-то не "залепил", чтобы все остальное не поламалось. Каждый девелопер решает только свою задачу и команды нет, отсюда слабое видение всего проекта.
Мне кажется ревьювить код целого мержа это равносильно убиться об стену, функиональных дефектов там все равно не найти. Ревью в 300 строк кода у меня уже ассоциируется, а че так много?

Вообще стандартно (как у меня было более менее везде), чем больше проект, тем строже и сложнее были правила.
Если проект небольшой комитили в транк, релизы были забранчеваны. В большом проекте под набор фич(хотелки пользователя, которые представляют достаточно большой функционал) создавали (и то не всегда) ветку и комитили туда.
Еще continues integration был везде.

Здравствуйте, Dym On, Вы писали:

DO>Имхо вы пытаетесь натянуть стереотипы работы с svn на git.

Наверняка! git пока изучаю, но мне кажется, что в схеме не так уж важно, svn или git.

DO>В git'e у каждого свой репозиторий, коммит -> фиксация изменений в своем репозотории, потом push -> на сервер в свою ветку, далее слияние на сервере с development. Прогоны тестов с development. Пока запущены прогоны сливаться с development запрещено. Если тесты прошли успешно слияние development с prodution.

Да, я так и задумал. Вот выделенное, это кажется решает вопрос о гарантии стабильности development.

Здравствуйте, diez_p, Вы писали:

_>Но мало входных характеристик. Количество кода, количество девелоперов, что такое тикет(описание бизнес функционала, или просто задача), среднее время выполнения тикета.

Немного разработчиков. Тикет — это задача вроде пофиксить баг, добавить функциональность. Обычно тикеты не долго живут, но бывает, что разработка и затягивается.

_>Мне непонятно за чем тикет=ветка, уж тем более в svn.

Чтобы те изменения, что делает разработчик, были изолированы от trunk в отдельной ветке, в которой идет работа по тикету.

_>Поиски корней в таком code base — скорее всего ахтунг.

Что такое корни?

_>По вашему описанию создается чувство, что у вас слишком сильная защита от того, чтобы девелопер, что-то не "залепил", чтобы все остальное не поламалось. Каждый девелопер решает только свою задачу и команды нет, отсюда слабое видение всего проекта.

Все правильно. Разработчики удаленные, иногда работают в разное время, работают над своими задачами, и если каждый будет коммитить прямо в trunk, то будем регулярно получать несобирабельные ревизии, конфликты. Уж лучше дать разработчику спокойно работать в своей ветке.

_>Мне кажется ревьювить код целого мержа это равносильно убиться об стену, функиональных дефектов там все равно не найти. Ревью в 300 строк кода у меня уже ассоциируется, а че так много?

А что делать, надо смотреть код, куда деваться

Ревью делается, чтобы скорее оценить качество кода, чтобы выявить какие-то явные проблемы, ну например какой-то функционал уже реализован, а разработчик не знал, что не надо ее реализовывать, а можно вызвать вот ту и ту функцию. Или класс как-то странно назвал. Или написал нетривиальный код, который следует прокомментировать получше. Или какой-то код продублировался, и надо его выделить в отдельный блок. Мало ли чего. Не представляю, что было бы, если бы все это немедленно попадало в trunk

Функциональность же проверяется тестами. Код теста тоже надо посмотреть, все ли он проверяет, что нужно.

_>Если проект небольшой комитили в транк, релизы были забранчеваны. В большом проекте под набор фич(хотелки пользователя, которые представляют достаточно большой функционал) создавали (и то не всегда) ветку и комитили туда.

Т.е. в основном без веток, коммиты прямо в trunk? Скажем три разработчика параллельно коммитят, не было ли такого, что не собирается, что были ошибочные коммиты? Если было, то как это разруливается? И как быть, если надо выпустить релиз, в который должна войти фича 1, фича 2, а фича 3 не должна войти, потому что она не доделана. В текущем виде trunk не возьмешь, потому что фича 3 еще в процессе, ее реализация ломает старые тесты...

В подходе с ветками я в trunk смерджу только то, что уже готово и протестировано.

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

Здравствуйте, Unhandled_Exception, Вы писали:

_>>Поиски корней в таком code base — скорее всего ахтунг.
U_E>Что такое корни?
Ну например было одно условие в if потом их стало два, потом еще что-то добавилос и пошло поехало, хочется видеть в рамках каких комитов, а главное тасков это делалось.

U_E>Все правильно. Разработчики удаленные, иногда работают в разное время,
Вот это собственно объясняет весь гемор процесса.

U_E>А что делать, надо смотреть код, куда деваться
Возможно делегировать ревью еще кому-то, но если все на удаленке то

В моих сиуациях по сравнению с вашими очень большая разница. У вас удаленная команда, а у меня нет и по этому все наших подходы(комиты в транк) у вас не заработают

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

Внедрить средство ревью кода. Заставить комитить имплементацию таски небольшими кусками. и ревьювить эти таски. Если кто-то что-то "залепит" вы узнаете об этом раньше, да и мерж будет проще.
Внедрить (Continues Integration), на каждую ветку должны ранаться нужные тесты, которые проверяют текущий и новый функционал. Опять таки вы узнаете о фейлах раньше и примите раньше решение.

Но вообще такая удаленка это "ой, мать... твою мать ))"

Здравствуйте, Unhandled_Exception, Вы писали:

U_E>Как лучше всего организовать процесс? У кого какая практика?
У тебя описана обычная практика CM, правда там на девелоперский бранч можно коммитить всё, что не ломает билд, но при это есть ещё один бранч — интеграциооный, куда CM сливает всё, что не ломает все тесты.
Насчёт улучшений:
1. На девелоперский бранч заливать всё с помощью git rebase чтобы оно вошло в дев. бранч одним коммитом.
2. После ребэйза разработчик вешает тэг на коммит и система/человек запускает свои тесты (обычно юниттесты).
3. После того как юнит-тесты удачно запасились этот тэг мёрджится на интеграционный бранч и запускаются все тесты.
4. С интеграционного бранча всё мёрджится на продуктовый.
Т.е. схема такая: bugfix->unit test->dev branch(rebase+commit)->integration test(by tag, no commit)->integration branch (merge)->product branch.
Могут быть пробелмы с апмёржем, багфиксы могут влиять друг на друга что приведёт к другим багам(можно будет понять по интеграционному бранчу кто и что внёс)
Недооценивай тэги — тэги это очень мощный инструмент.
Интеграционный бранч можно делать каждый спринт, например.
Ах да, кто не успел закоммитить, тот опоздал.

Здравствуйте, Kernan, Вы писали:

K>Здравствуйте, Unhandled_Exception, Вы писали:

U_E>>Как лучше всего организовать процесс? У кого какая практика?
K>У тебя описана обычная практика CM, правда там на девелоперский бранч можно коммитить всё, что не ломает билд, но при это есть ещё
простите что такое СМ?

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

Этот шаг называется "pull request". Поищите по этим ключевым словам. Примерно так организована разработка во многих open-source командах.
Разработчик делает фичу, коммитит ее к себе в репозиторий, затем создает pull request. В этот момент сервер вытягивает (прямо из репозитория разработчика) изменения и далее делает все как вы описали: мержит, гоняет автотесты, push-ит изменения в основной репозиторий.

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

Обработка Pull Requests идет последовательно. Пока один не отработал, следующий не стартует.

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

Именно такая, с pull requests.

Второй вариант — на нышенем месте организовано через промежуточный репозиторий и commit hooks, которые запускают hudson build (эту схему вы и описали). Но это просто исторически сложилось, а переделывать нет желания. Да и мало коммитят, между коммитами тесты успевают отработать с большим запасом.

Здравствуйте, diez_p, Вы писали:

_>простите что такое СМ?

CM — это Configuration management:
http://en.wikipedia.org/wiki/Configuration_management

Здравствуйте, Unhandled_Exception, Вы писали:

U_E>Как лучше всего организовать процесс? У кого какая практика?
Посмотри на связку Git+Gerrit+Jenkins. Вот с картинками объяснение есть:

Т.е. в главную ветку (master) попадают только изменения, которые прошли все желаемые автоматические проверки и, обычно, ручной code review.

Дальше можно ещё стадии навешивать. Скажем, главная ветка может промотиться в ещё более главную (release candidate) после, например, выполнения performance tests, которые выполняются очень долго, поэтому только раз в сутки, по ночам.

Здравствуйте, Unhandled_Exception, Вы писали:

DO>> Пока запущены прогоны сливаться с development запрещено.
Все конечно зависит от того, сколько идут прогоны, но в таком виде это не очень жизнеспособное решение решение. Говорю, как человек, который с подобной системой поработал

Имеем прогоны идут 30 минут, 3 разработчика.

1 — слился, запустил прогоны
2 — сидит ждет пока прогон пройдет, выкачал изменения запустил прогоны локально с полученными изменениями, захотел слится
3 — обогнал второго, слился — запустил прогоны глобально, второй сосет лапу
2 — все по-новой

Вариантов подобных колизий может быть бесконечно много. "Неудачники" могут получать до 2-3 часов (5-6*30 мин) чистого ожидания. Во что это может вылиться, предлагаю додумать самому.

H>Вариантов подобных колизий может быть бесконечно много. "Неудачники" могут получать до 2-3 часов (5-6*30 мин) чистого ожидания. Во что это может вылиться, предлагаю додумать самому.
Здесь это не принята. А причина массового внедрения сего бреда в социальной ответственности бизнеса (нужно обеспечивать работой толпы народа).