Continuous Integration в связке с DVCS — как?

Question

[StepEv]

Дано:

* DVCS — Git

* CI сервер — Hudson

* Используем модель ветвления GitFlow


Теперь вопрос — на какие события в origin репозитории и что должен собирать CI?

Поделитесь опытом, пожалуйста.



Понятно, что любой коммит в master должен собирать релиз.


Скорее всего, коммит в develop также должен собрать билд, прогнать тесты и задеплоить на демо сервер.


А вот с feature бранчами возникают непонятки. CI нам нужен что бы интегрироваться часто. То есть в идеале на каждый коммит в feature-* надо смерджиться с develop и, при успехе, собрать и протестировать билд. Нужно ли при успехе коммитить изменения обратно в develop на origin (вроде hudson это умеет)?


Если да, то увеличивается риск сломать develop. В любом случае, в нём оказываются незавершённые фичи. Если нет, то интеграция с работой других разработчиков/команд откладывается до завершения фичи и окончательного её мерджа в origin/develop. А к этому моменту конфликты могут накопиться.


И в какой момент делаем code review?

Answer 1

[Ярослав Астафьев]

Не знаю, у нас коммиты в develop делаются только руками и только после ручного тестирования. Да, hudson умеет делать post-build push, но успешная прогонка тестов не означает абсолютно правильную работу программы.

Comments

[Ярослав Астафьев]

Ну и бывают еще конфликты при merge, и прочие неприятные вещи, которые не совсем понятно, как автоматизировать.

[StepEv]

Ну, push он делает только после успешной сборки. Так что при конфликтах его не будет.

Но, похоже, develop надо оставить в покое :)

Может быть позже заведём отдельный бранч для автоматического слияния, если почувствуем необходимость.

[Ярослав Астафьев]

Простой пример: вы изменили одну и ту же строчку в разных ветках. При этом тесты могут проходить, сборка успешна, а слияние двух веток происходит с конфликтом.

[StepEv]

Так разве не лучше, если этот конфликт будет обнаружен немедленно, а не через несколько дней?

[Ярослав Астафьев]

Ну у нас настаивают на ручном тестировании и последующем ручном слиянии в девелоп. Причина простая: во многих компаниях code coverage довольно низкий и успешно пройденные тесты еще не гарантируют отсутствие критикал багов. По этому и не хочется делать автомерж в девелоп — от него же отделяются все дальнейшие ветки, а лишнего тянуть не хочется. У нас довольно много веток, которые живут несколько дней, а иногда и меньше.
На счет конфликтов при слиянии пожалуй вы правы, уж лучше они вылезут сразу.

[StepEv]

Спасибо.

Пока автоматически обратно мерджить обратно не будем. А вот мердж из develop и сборку всех бранчей по коммиту попробуем настроить и посмотрим как пойдёт.

Answer 2

[1nd1go]

feature бранч — это вообще говоря вещь для локальной разработки девелопером. Иногда надо поделится с другим девелопером кодом из этой бранчи, тогда, как неизбежное зло, эта бранча попадает на центральный репозиторий вашей команды. Но вообще говоря, ее для остального мира не существует. А функциональность для мира начинает существовать только когда бранча смерджена в develop, а сама она уже прибита.

Так вот исходя из вышесказанного, CI собирает только develop и master. Остальных бранчей для него не существует.

Решением сложностей при мердже бранчи в девелоп после длительного периода является периодический бэкпортинг изменений из девелопа в бранчу, чтобы бранча была как бы все время up-to-date с изменениями в девелопе.

Код ревью делается при мердже бранчи в девелоп, т.е. когда можно посмотреть изменения между результатом git merge --no-ff --no-commit и develop baseline.

Comments

[StepEv]

Такой подход имеет право на существование. Но он откладывает все проверки качества до момента возврата ветки в develop. Ну или полагается на то, что разработчик будет периодически подкачивать к себе изменения вручную (ха три раза).

При этом у нас есть железяка, которая всё равно делает ту же работу. Почему не переложить на неё обязанность проверять здоровье ветки как самой по себе, так и при интеграции? И не получить раннее обнаружение потенциальных проблем?

Не вижу аргументов против.

[1nd1go]

StepEv, Я бы лично хотел видеть у себя в проекте коротко-живущие бранчи (1-3 дня). Причин тому много — начиная от проблем трэкинга прогресса по таскам, заканчивая проблемами с мерджем туда-сюда. В этом случае проблема с качеством кода в фича-бранче не стоит.

Для ad-hoc проверок на качество кода, существуют в java мире checkstyle и pmd, которые выполняются во время сборки проекта девелопером. Скорее всего для других языков тоже что-то есть подобное.

[StepEv]

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

[1nd1go]

StepEv, потому что хадсон эту бранчу не видит, если она допустим одним девелопером делается — ее тупо нет в remote (central). А если она там оказалась потому что ее девелопят 2 девелопера (и то если они не стали поднимать git server у себя), то вам каждый раз надо заводить новые джобы в хадсоне на каждую бранчу, и джоба как и бранча там существует 1-2 дня.

Два этих фактора ставят ценность наличия таких проверок за чертой эффективности по соотношению эффорт/выхлоп, откуда получаетя процесс ради процесса, а не ради delivery.

PS Если вы не ставите мой ник, как это делаю я с вашим, то я не получаю уведомления что вы мне ответили. Могу провафлить дискуссию.

[StepEv]

1nd1go

Ну, делать периодически push в origin как раз не сложно. И hudson умеет мониторить и собирать все ветки, с предварительным мерджем с указанной. Не умел бы, я бы и не заморачивался, наверное.