Организация процесса разработки продукта на C++ / Windows
От: Unhandled_Exception Россия  
Дата: 27.02.14 11:58
Оценка:
Всем привет,

У нас проект на С++ для 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 стабилльна...

Как лучше всего организовать процесс? У кого какая практика?
Re: Организация процесса разработки продукта на C++ / Windows
От: Dym On Россия  
Дата: 27.02.14 12:32
Оценка:
Имхо вы пытаетесь натянуть стереотипы работы с svn на git.
В git'e у каждого свой репозиторий, коммит -> фиксация изменений в своем репозотории, потом push -> на сервер в свою ветку, далее слияние на сервере с development. Прогоны тестов с development. Пока запущены прогоны сливаться с development запрещено. Если тесты прошли успешно слияние development с prodution.
Вот как-то так, широкими мазками.
Счастье — это Glück!
Re: Организация процесса разработки продукта на C++ / Windows
От: diez_p  
Дата: 27.02.14 12:59
Оценка: +2
Здравствуйте, Unhandled_Exception, Вы писали:

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

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

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

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

Вообще стандартно (как у меня было более менее везде), чем больше проект, тем строже и сложнее были правила.
Если проект небольшой комитили в транк, релизы были забранчеваны. В большом проекте под набор фич(хотелки пользователя, которые представляют достаточно большой функционал) создавали (и то не всегда) ветку и комитили туда.
Еще continues integration был везде.
Re[2]: Организация процесса разработки продукта на C++ / Windows
От: Unhandled_Exception Россия  
Дата: 27.02.14 13:02
Оценка:
Здравствуйте, Dym On, Вы писали:

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


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

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


Да, я так и задумал. Вот выделенное, это кажется решает вопрос о гарантии стабильности development.
Re[2]: Организация процесса разработки продукта на C++ / Windows
От: Unhandled_Exception Россия  
Дата: 27.02.14 13:27
Оценка:
Здравствуйте, diez_p, Вы писали:

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


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

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


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

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


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

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


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

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


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

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

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

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


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

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

Впрочем, я думаю, что может быть кому-то удобно и все прямо в trunk-е делать. Зависит от, как говорится. Мне с ветками мегаудобно, это я менять не буду, но хочется больше автоматизировать
Re[3]: Организация процесса разработки продукта на C++ / Windows
От: diez_p  
Дата: 27.02.14 14:22
Оценка: 4 (1)
Здравствуйте, Unhandled_Exception, Вы писали:

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

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

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

Вот это собственно объясняет весь гемор процесса.

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

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

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

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

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

Но вообще такая удаленка это "ой, мать... твою мать ))"
Re: Организация процесса разработки продукта на C++ / Windows
От: Kernan Ниоткуда https://rsdn.ru/forum/flame.politics/
Дата: 27.02.14 16:31
Оценка: 6 (1)
Здравствуйте, 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.
Могут быть пробелмы с апмёржем, багфиксы могут влиять друг на друга что приведёт к другим багам(можно будет понять по интеграционному бранчу кто и что внёс)
Недооценивай тэги — тэги это очень мощный инструмент.
Интеграционный бранч можно делать каждый спринт, например.
Ах да, кто не успел закоммитить, тот опоздал.
Sic luceat lux!
Re[2]: Организация процесса разработки продукта на C++ / Windows
От: diez_p  
Дата: 27.02.14 17:56
Оценка:
Здравствуйте, Kernan, Вы писали:

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


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

K>У тебя описана обычная практика CM, правда там на девелоперский бранч можно коммитить всё, что не ломает билд, но при это есть ещё
простите что такое СМ?
Re: Организация процесса разработки продукта на C++ / Windows
От: SkyDance Земля  
Дата: 27.02.14 22:44
Оценка: 11 (2)
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 (эту схему вы и описали). Но это просто исторически сложилось, а переделывать нет желания. Да и мало коммитят, между коммитами тесты успевают отработать с большим запасом.
Re[3]: Организация процесса разработки продукта на C++ / Windows
От: bkat  
Дата: 28.02.14 18:03
Оценка: +1
Здравствуйте, diez_p, Вы писали:

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


CM — это Configuration management:
http://en.wikipedia.org/wiki/Configuration_management
Re: Организация процесса разработки продукта на C++ / Windows
От: . Великобритания  
Дата: 04.03.14 09:36
Оценка: 6 (1)
Здравствуйте, Unhandled_Exception, Вы писали:

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

Посмотри на связку Git+Gerrit+Jenkins. Вот с картинками объяснение есть:

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

Дальше можно ещё стадии навешивать. Скажем, главная ветка может промотиться в ещё более главную (release candidate) после, например, выполнения performance tests, которые выполняются очень долго, поэтому только раз в сутки, по ночам.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[3]: Организация процесса разработки продукта на C++ / Windows
От: hotdox  
Дата: 19.03.14 17:10
Оценка: 3 (1)
Здравствуйте, Unhandled_Exception, Вы писали:

DO>> Пока запущены прогоны сливаться с development запрещено.

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

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

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

Вариантов подобных колизий может быть бесконечно много. "Неудачники" могут получать до 2-3 часов (5-6*30 мин) чистого ожидания. Во что это может вылиться, предлагаю додумать самому.
Re[4]: Организация процесса разработки продукта на C++ / Windows
От: Аноним  
Дата: 21.03.14 08:09
Оценка:
H>Вариантов подобных колизий может быть бесконечно много. "Неудачники" могут получать до 2-3 часов (5-6*30 мин) чистого ожидания. Во что это может вылиться, предлагаю додумать самому.
Здесь это не принята. А причина массового внедрения сего бреда в социальной ответственности бизнеса (нужно обеспечивать работой толпы народа).