Continuous Integration на практике. Часть 1

79 комментариев
Continuous Integration на практике. Часть 1

Недавно cостоялась 4-ая встреча PHP User Group Minsk в коворкинге ME100. Такие встречи проходят раз в месяц, а их организаторами являются минские PHP-разработчики. Цель таких встреч — поделиться опытом и знаниями, посмотреть, как похожие процессы построены в других командах/компаниях. Это скорее неформальные мероприятия, которые проходят в режиме свободной дискуссии и в которых принимают участие PHP-разработчики из разных IT-компаний в Минске.

Основными темами на 4-ой встрече PHP User Group Minsk, которая прошла в октябре, были Symfony, Continuous Integration, NodeJS и DDD. На этой встрече выступил и наш Tech Lead Антон Сердюк с докладом на тему Continuous Integration. На этой встрече выступил и наш Tech Lead Антон Сердюк с докладом на тему Continuous Integration.

В своем докладе Антон подробно рассказал о том, как код 15-ти разработчиков Startup Labs два раза в неделю выкатывается на продакшен: «Мы разрабатываем B2B систему, не очень большую, но и не очень маленькую. Проект длится уже полтора года, и в разное время над ним работали от 4 до 15 разработчиков (сейчас 15). Трафик у нас небольшой, но дорогой, данных тоже не очень много — 15 гигабайт. Незапланированный downtime нам обходится дорого (однако есть maintenance window), т.е. мы можем позволить себе небольшой запланированный downtime. Баги на продакшене нам тоже обходятся дорого, потому что у нас не соцсеть: люди делают бизнес c помощью нашей системы и просто уйдут к конкурентам, если увидят, что у нас все нестабильно.

Технологии, которые мы используем:

  • PHP 5.4;
  • Java 7;
  • PostgreSQL для БД;
  • RabbitMQ как шина сообщений, соединяющая все компоненты между собой.

Примерный список фреймворков:

  • в Java части — Hibernate и JUnit;
  • в PHP части — Symfony 2, Silex для каких-то мелких компонентов, Behat для функциональных тестов, PHPUnit для юнит-тестов.

Мы любим Agile и основные принципы берем из него:

  • делаем маленькие изменения;
  • часто поставляем их клиенту;
  • рано принимаем фидбек.

На пути становления наших процессов были определенные вещи, от которых мы по тем или иным причинам осознанно отказались.

1. В первую очередь это фиче-бранчи. Вообще, как мне кажется, фиче-бранчи очень слабо вяжутся с идеей Continuous Integration. Я бы даже сказал: либо фиче-бранчи, либо CI. Проблема в том, что код в фиче-бранче не интегрируется с остальным кодом, поэтому может сильно расходиться с кодом внутри других фиче-бранчей, даже если регулярно к нему подмерживается мастер.

Второй аргумент против фиче-бранчей — это то, что не всегда можно понять, что же происходило уже иногда даже на следующий день. Ниже на скриншотe — история гита проекта другой команды, состоящей примерно из 15 девелоперов и верстальщиков. Разобраться в каком-то нетривиальном кейсе в такой истории получается очень сложно.

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

3. Также мы отказались от всяких develop-бранчей. Часто при создании проекта даже на двух девелоперов создают сразу staging и master. Разработку ведут в develop, а потом мержат это все в другие бранчи. Для нас это оказалось избыточно, и мы не нашли в этом никакой пользы.

4. Мы не делаем релиз-теги. Хотя это не мешает работе и не требует сложной поддержки, пока что необходимости в них у нас тоже не было.

5. В отдельности можно сказать, что мы не используем git-flow. Я вообще не понимаю, почему так много людей его боготворят. Это огромный оверкилл, заставляющий даже плагины к гиту использовать, потому что без них работать уже неудобно.

Что мы используем, так это Continuous Integration. Что это значит для нас:

  • девелопер должен каждый день интегрироваться с основной (и единственной) веткой разработки;
  • каждый коммит собирается на билд-сервере;
  • на каждый билд выполняются все автотесты;
  • красные билды надо фиксить быстро.

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

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

Важный момент с Continuous Integration — это то, что ты постоянно должен интегрировать свой код с мастером. Понятное дело, что не все фичи делаются меньше дня. Для таких случаев есть интересный подход: Branch By Abstraction. Первым делом девелопер коммитит выключатель для фичи, который выключен по умолчанию. Далее он может постоянно интегрироваться с мастером, не боясь что-то сломать. Его код может уже быть (а иногда не раз) задеплоен в выключенном состоянии на продакшен. Потом, когда фича подходит к концу, она включается и отправляется в QA, которые ее проверяют, и если все хорошо, то уже следующий релиз ее включит на продакшене.

Нет смысла говорить о CI без автотестов. Автотесты мы очень любим и активно используем. QA у нас пишут Behat сценарии до разработки фичи или во время ее разработки, а девелоперы их имплементят. Мы стараемся абсолютно каждую фичу покрывать сценариями. Таким образом, получается отличный большой пак регрессионных тестов, который позволяет нам достаточно просто и безболезненно проводить рефакторинг.

Вот несколько цифр с проекта:

У нас уже 1000 Behat сценариев (это не включая юнит-тесты, которых у нас поменьше). Билд длится в среднем 15 минут (включая прогон всех функциональных тестов). У нас два достаточно мощных билд-сервера и примерно 15 билдов в день. Нам важно, чтобы время билда было минимальным, тесты занимают бóльшую часть времени билда, поэтому мы постоянно работаем над их ускорением.

Два раза в неделю мы деплоимся на продакшен. Деплой запускается вручную. У нас для этого собирается мини-команда из девелопера, менеджера и архитектора, которая нажимает на кнопку и проверяет потом, все ли в порядке. Дополнительно у нас есть сервер nb-prod — он инкрементально обновляется вместе с продакшеном, это песочница для других команд, которым нужно интегрироваться с нашим продуктом.

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

Более подробно о том, как происходит сам процесс билда и какие фазы он в себя включает, можно будет узнать в нашем следующем посте.

Посмотреть полную презентацию можно здесь.

Горячие события

Конкурс EY Entrepreneur Of The Year 2020
31 мая — 31 мая

Конкурс EY Entrepreneur Of The Year 2020

GoWayFest 4.0
11 июля — 11 июля

GoWayFest 4.0

Минск

Читайте также

Состоялся релиз PHP 7.4
Состоялся релиз PHP 7.4

Состоялся релиз PHP 7.4

Уязвимость PHP7 подвергает сайты риску удалённого взлома
Уязвимость PHP7 подвергает сайты риску удалённого взлома

Уязвимость PHP7 подвергает сайты риску удалённого взлома

3 комментария
7 языков программирования, которые стоит изучать в 2019 году
7 языков программирования, которые стоит изучать в 2019 году

7 языков программирования, которые стоит изучать в 2019 году

5 комментариев
Python назвали самым популярным языком программирования
Python назвали самым популярным языком программирования

Python назвали самым популярным языком программирования

Обсуждение

4

прикольная схема. один бранч и Branch By Abstraction - я такое юзал всю жизнь и втайне думал - зачем вообще придумали всякие бранчи которые только добавляют гемора, если достаточно двух команд - pull/push, commit/update и т.п.
только я всегда думал что я чего-то не дорабатываю в этой области, и наверняка более дисциплинированные и масштабные команды меня облажают сразу же, поэтому вслух старался такого не рассказывать :)

3

пока клиент один - все клево.

sherkhan
sherkhan Senior Front-end developer в ScienceSoft
-1

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

2

Это вы мимо. В продуктовой разработке как раз как правило клиентов больше чем один. И бранчи на каждого клиента нам приходилось делать и т.п.

Михаил Дубаков
Михаил Дубаков Writer в Fibery
4

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

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

2

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

0

А зачем тогда git? Такой простой схеме нужны средства попроще. SVN был бы в самый раз, как мне кажется.

0

*на правах иронии* Developers из Startup Labs, согласно Agile и Continuous Integration, commit'ят в master свои features, используя подход Branch By Abstraction, чтобы deploy'иться на production почаще, а вы со своим устаревшим SVN ? =)

Anonymous
Anonymous PHP Developer в Startup Labs Inc.
1

так и разница между гитом и свн заключается же не только в управлении remote ветками.

0

Согласен. Правда я с git знаком очень поверхностно. Но из статьи я не увидел, что именно толкнуло использовать git (кроме того, что в начале был git-flow и постепенно от него отказались, но остались на git). SVN проще git, но git мощнее. Только я не совсем понимаю, зачем нужна его сложность, когда его мощь не используется. Может есть конкретные примеры, чем git лучше в таком простом сценарии?

Anonymous
Anonymous Project Manager в Wargaming / Гейм Стрим
0

Что мне приходит сразу в голову это, например, команда git stash. Сделайте что-то похожее в svn. Есть варианты, но это не настолько просто.
Или git bisect.
Список можно продолжать и продолжать.
Мне лично, больше меркуриал по душе, но разница не большая.

0

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

Это навскидку.

1

Кроме приятной работы с фичебранчами гит предоставляет очень много дополнительных удобностей, например: удобная работа с локальными бранчами, децентрализованность (возможность работать без связи с центральным репом), удобная работа из консоли, всякие плюшки типа stash. Децентрализованность, например, дает такой очень приятный workflow: можно создавать кучу локальных бранчей для экспериментов, все это очень быстро и не засоряет общий репозиторий, можем переключаться между ними опять же очень быстро. В это время можно коммитить кучу промежуточных мусорных коммитов, чтобы иметь возможность к ним откатиться в экспериментах. Потом можно аккуратно собрать весь мусор в один красивый коммит с правильным описанием и запушить. К таким вещам начинаешь относиться как к само собой разумеющимся фичам и перестаешь замечать их.

Anonymous
Anonymous .Net Lead Developer в ScienceSoft
4

Branch-by-abstraction тоже дает оверхед, просто этот оверхед не выражен в манипуляциях в source control/continuous integration. У него тоже есть плюсы и минусы, так что Branch-by-abstraction/Feature branches это две стороны одной монеты. Что выбрать зависит от контекста проекта, команды, релиз менеджмента. Одно другое не отменяет. Да, еще есть сходный механизм Feature Toggling.
Не надо зацикливаться на чем-то одном а просто выбирать корректный инструмент для нужд проекта.

0

Вы совершенно правы! В статью это не вошло, но в самом начале презентации я говорил именно о том, что применимость любых инструментов, в том числе и описанного подхода сильно зависит от кучи факторов: специфики проекта, команды, кастомера(ов), бизнес-процессов - да вообще чего угодно

6

Адекватный доклад (был на этом ивенте), тем более по сравнению с последним ) Похоже, они применяют технологии осмысленно, а не просто берут бездумно то, что модно. И это радует.

0

Спасибо!

0

Branch-by-abstraction. Это получается, разработчик должен постоянно держать у себя незакоммиченным кусочек кода, включающий фичу, чтобы запускать ее локально? Ну-ну...

sherkhan
sherkhan Senior Front-end developer в ScienceSoft
1

Читайте внимательно: Первым делом девелопер коммитит выключатель для фичи, который выключен по умолчанию. Далее он может постоянно интегрироваться с мастером, не боясь что-то сломать. Его код может уже быть (а иногда не раз) задеплоен в выключенном состоянии на продакшен. Потом, когда фича подходит к концу, она включается и отправляется в QA, которые ее проверяют, и если все хорошо, то уже следующий релиз ее включит на продакшене.

4

Я-то как раз внимательно прочитал.

Вот это коммитится:
bool feature_enabled = false;
if ( feature_enabled )
{
/// bla-bla-bla
}

А вот это - нет:
bool feature_enabled = true;

А это надо, чтобы локально фичу запускать. Или ваши разработчики даже не запускают у себя ничего до момента "включения"?

1

bool feature_enabled = config.getParameter('feature_enabled');
конфиг не под гитом, на локальным машинах "деплоится" папет-скриптом
на проде свой папет скрипт, в который вносятся изменения когда все готово

-1

> конфиг не под гитом
Вы уже дважды молодцы! Удачи!

1

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

1

так и есть. под гитом config.sample + папет скрипт, который деплоит конфиг на локальные машины девелоперов

0

Очень хочется еще и эту бадягу сюда запостить: http://12factor.net/config

1

Вы говорите о техническом моменте реализации такого подхода, вариантов тут может быть очень много. Один из которых, не самый удобный но все же вполне рабочий, действительно не коммитить строку с включением фичи в конфиге. Не вижу проблемы с ним - коммиты все-равно перед пушем желательно просматривать на предмет всяких TODO и другого мусора забытого. Есть более удобный способ. Конфиг всегда состоит из двух частей - той части которая коммитится и той части которая env-specific: в ней хранятся креды к БД и прочие вещи, которые на разных серверах разные. env-specific конфиг не коммитится в репозиторий. Вот в него и можно, например, добавить включатель на время разработки.

2

>>красные билды надо фиксить быстро.
Это жесть, в CI с нормальными бранч-фичами в случае поломки ломается только один бранч, все остальные работают нормально. Получается, что у вас если сломали билд, то работа парализована и бедняга должен либо в экстренном порядке делать реверт, либо фиксить баг. Опять же, чтобы прогнать тесты нужно рискнуть пульнуть коммит в основную ветку, а не спокойно прогнать на своей. Так как фича реализуется кучей коммитов, то её код размазывается и нет возможность посмотреть просто весь код сравнив ветки, как делать ревью в таких условиях?
И всё это XP только для красивого и ровного графика.

Вы нарисовали страшный график с кучей веток, работая же реально по такому сценарию с фиче-бранчами и даже отдельными репозиториями и пулл реквестами, это дерево никогда не видишь. Я навскидку даже не вспомню какой командой оно строится. В реальности работаешь с двумя бранчами - своим и тот, куда будем мержить, всё остальное дерево нас не волнует. Любая поломка случается в твоём бранче, ты этот бранч тестишь через стандартный механизм CI, легко можешь сравнимать с основной веткой, делать ревью, а перед мержем собирать в один коммит-фичу.

0

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

3

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

Получается что у вас билд сервер, а не CI. Да и то, билды для одной мусорной ветки.

Во времена svn мы это называли работа с нестабильным транком, коммитили всё в транк, а когда он вдруг оказывался рабочим, помечали это тегом. Но тогда проект делали 1-2 человека, да и мы были молоды, не думал, что такое может быть в больших командах.

0

Мы с вами скорее всего сталкивались с разными проектами и разными проблемами, поэтому друг друга понять не можем. Фичебранчи тоже вполне себе можно применять, хотя мы их сильно не любим. Справедливости ради хочу привести несколько примеров: Badoo использует фичебранчи (релизятся два раза в день), в JetBrains команда ReSharper использует фичебранчи, а команда TeamCity использует Branch By Abstraction (и релизится каждый день).

Я не согласен с вами принципиально в вопросе что есть CI. CI это в первую очередь Integration. Вся суть и цель CI - избежать больших мержей, когда сделанные одним девелопером изменения остальные члены команды видят как можно раньше. Особенно остро этот вопрос стоит при активном рефакторинге. А уже как билдить и когда - это вопрос второстепенный.

Называть мастер мусорной веткой некорректно, потому что он вполне стабилен

1

Какая может быть интеграция, если с красным билдом все стоят? Да и толку что команда видит кусок кода, нужно видеть ГОТОВЫЙ, оттестированный и работающий вариант кода.
Ревью провести невозможно, т.к. код раскидан по коммитам, появляется мёртвый код, фичу выпилить тоже не возможно, чтобы доработать, нужно искать места, где валятся тесты - всё это вместо того чтобы посмотреть на диф между двумя ветками.
Я не спорю, что микроскопом можно забить гвоздь, не повредив сам инструмент, но здесь всё держится на способностях разработчика, а не на методологии работы.

0

Любой подход подразумевает под собой жертву чем-то в пользу чего-то другого. Для разных проектов важны разные вещи. Поэтому считаю спор "CI vs фичебранчи в сферическом проекте в вакууме" ничем не лучше спора "Win vs Lin vs Mac" или "Android vs iPhone".

0

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

1

Самый важный профит, который мы получаем от такого подхода, это отсутствие больших мержей. Под большим мержем я подразумеваю мерж двух девелоперов, которые неделю или две работали над своими фичами в своих фичебранчах. Если вдруг так получилось, что они работают рядом в коде, а еще один из них решил подрефакторить немного - все, вешайся, вместе это работать не будет. Пока речь идет о фичах в 2-3 дня это вообще не принципиально. Но когда речь идет о функциональности, которую нужно делать две недели (а то и месяц) и в рамках которой нужно переделать кучу всего прям вот внутри системы, то тут без branch by abstraction я вообще не представляю как жить. Если девелопер закроется в своем бранче на две недели, то он просто физически не сможет мержить постоянный поток кода остальных 15 девелоперов со своим бранчем.
Плюс еще такой момент: чем меньше изменения, тем меньше вероятность что-то сломать. Получается намного надежнее выливаться по чуть-чуть, потому что эти изменения раньше попадут в руки QA, они раньше увидят что что-то отвалилось не покрытое тестами.

0

Тут короче мужик один вот такое пишет: http://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitsToTheMainlineEveryDay

В общем, если по-русски: "Сливайтесь в основную ветку каждый день, иначе это какой-то другой CI"

Ну у вас так и есть, по ходу.

2

Смотри. Я сделал бранч от dev ветки, пишу две недели код, готово, собрал всё в один коммит, делаю rebase на актуальное состояние. Получаю конфликт - это круто, я узнал что кто-то правил мой код и мая фича может работать не правильно, разгребаю конфликт и после этого я уверен, что моя фича и после мержа будет работать правильно.

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

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

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

0

Да, мы стремимся именно к идеям Фаулера

-1

Если вы так работаете и вас это устраивает и нету проблем, то все отлично! Значит CI вам просто не нужен. Я описал важные для нас профиты, которые мы получаем от CI и почему это важно для нас, но ни в коем случае не говорю, что это подойдет каждой команде и проекту. Значит у вас просто другие приоритеты. Возможно вы не так часто релизитесь, либо вы намного чаще релизитесь, либо у вас сильно меньше команда, либо у вас сильно больше команда, либо еще что-то, что не позволяет раскрыть основные профиты от CI и частых коммитов на полную.

0

Он это писал 13 лет назад, да и коммит - это не значит в единую ветку. Всё описанное там вполне подходит для фиче бранчей с ребейсом при билде. Актуальная кодовая база и отличный дифф только вашей фичи.

7

Ок, у вас есть 5 "фичебранчей". При этом никто не спешит вливать код в мастер - фичи то еще не готовы. И мастер, вроде как, в актуальном состоянии - никаких проблем.

Наступает срок "сдачи фич" и люди начинают мержить свои ветки, один обновил мастер - у четверых сломалось... и так по очереди. Все всё чинят, а тут еще и сроки поджимают. И это не говоря о том, что Петрович в своей ветке такого рефакторинга наколбасил, что Кузьмич вообще не понимает как ему теперь свою фичу подлить.

Честно говоря, мне думалось, что понятие "непрерывная" (интеграция) включает в себя еще и понятие "равномерная". Ну там еще че-то про "коммуникацию" говорилось, но я не осилил.

В общем, товарищ Фаулер о своем, а вы о своем. Как дипломатично пишут товарищи в комментах вокруг - каждому свое, истории разные.

Только я не понял как у вас 13 лет получилось. Потому как 2013 - 2006... ну да ладно.

4

>>01 May 2006: Complete rewrite of article to bring it up to date and to clarify the description of the approach.
>>10 September 2000: Original version published.
По первой части. Если сложить
1+2+3+4+5 =10 у меня фича 2, получается 1+3+4+5+2=10, в любом случае мы получаем один и тот же код.
Какая разница как часто и когда вы мержите, в результате конфликты в любом случае будут одни и те же. Только в нормальном варианте вы их разрулите за один раз, а в случае частых коммитов несколько.

Фичи могут месяц не мержиться - это нормальная ситуация. Зато у вас в коде нет кусков от неё до момента включения.

Ну и главное - ситуация с конфликтами - это самый главный плюс, сломалось - отлично, ты нашёл интеграционный баг и можешь его целиком проанализировать, а не bisect в попытке найти что сломало твою фичу. Если кто-то переписал код от которого зависит ваша фича, то ваша фича уже будет работать не так как задумано. Тем более что BDD в такой ситуации напрочь выбрасывается, так как тесты на неписаный функционал будут портить весь билд.

1

По поводу дат. Видел в футере, да. Так "complete rewrite" же автор сделал. Чтоб "up to date" было. Ну то есть не забил товарищ на свой труд. Ну да ладно, в чем то вы правы.

По поводу математики "1+2+3+4+5 = 10". Если честно, я не понял.

А в целом. Разница не в том, насколько часто я мержу, да. В целом, это детали "реализации" подхода. Но имеет значение, насколько вовремя мои коллеги узнают об изменениях. Ну и насколько "фатальными" эти изменения окажутся для системы в целом (особенно, когда куски системы будут интегрироваться).

То есть теория такая: чем раньше сломалось, тем проще починить. Чем раньше узнал об изменениях, тем проще заюзать ("о, Петрович, ты новый модуль написал! счас переделаю свою фичу, а то нагородил костылей")

Ну и да, как всегда всё зависит от контекста, от процесса и от кучи других факторов.

0

добавлю слово в поддержку вашей методы.
я не знаю как в больших командах, но в небольших - overhead на глобальные мержи очень большой, точно больше чем добавить if/else для каждой фичи. я уж не говорю про текучку кадров, ведь никто не станет копаться в чужом бранче если что. другое дело мастер. и я не думаю что есть большая разница с большой командой, ведь тут правильно отметили в итоге это все равно "столкновение" двух девелоперов, редко больше.

Александр Котыня
Александр Котыня Php-developer в Onliner
3

По-моему формулировка "CI vs фичабранчи" некоректна само по себе, что-то из рода "agile vs git"

0

Не согласен. Почему - написал в комменте тут http://dev.by/blogs/startuplabs-inc/continuous-integration-na-praktike-chast-1#comment42672 . Опять же, речь идет про долгие фичебранчи. Речь не идет о бранчах, которые живут 2-3 дня. Но не вливать код в основную ветку 2-3 недели, а держать его в фичебранчах - это уже не CI ИМХО.

Александр Котыня
Александр Котыня Php-developer в Onliner
-1

какой смысл видеть неготовый функционал(код) другим разработчикам?
зачем да и как можно наполовину "отрефакторенный" код выливать в мастер?
а вопрос о 1-2-4 недельных фичах(бранчах) это скорее вопрос к постановке задачи и разбиению ее на таски)

Александр Котыня
Александр Котыня Php-developer в Onliner
0

при этом я соглашусь, что CI это больше про интеграцию

2

Не понимаю, что значит "наполовину отрефакторенный". Я всегда думал, что рефакторинг - это процесс непрерывный, который должен идти рядом с разработкой фичи, чтобы код не загнивал и потом не хотелось "переписать все с нуля". Хочешь не хочешь, а иногда встает вопрос, что надо сделать большой кусок функциональности, который не имеет никакого смысла если он не весь сделан. Поставить его наполовину смысла вообще нету никакого. А деплой на прод два раза в неделю. Вот тут встает выбор: либо делать в отдельном бранче здоровый кусок, либо как-то делить на части мелкие и поставлять кусочками, но при этом чтобы пользователи не видели ничего сделанного наполовину.

Александр Котыня
Александр Котыня Php-developer в Onliner
0

>Вся суть и цель CI - избежать больших мержей, когда сделанные одним >девелопером изменения остальные члены команды видят как можно раньше. >Особенно остро этот вопрос стоит при активном рефакторинге
я про это. т.е. цель как можно раньше увидеть чуть-чуть отрефактореный код? я тоже этого не понимаю)

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

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

1

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

Часть большой фичи не имеет смысла для пользователей, поэтому эта фича выкладывается в продакшен в выключенном состоянии вместо того чтобы разрабатываться в фичебранче. Собственно это пример применения Branch By Abstraction вместо фичебранчей. Я хочу сказать, что фичи длиной 1-2-4 недели это не косяк постановки задачи. И когда встает выбор делать выключатель для таких фич или фичебранч, мы выбираем выключатель, чтобы часто интегрировать код с основной веткой.

0

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

2

Мы с вами занимаемся тут пустым теоретизированием. Если вы готовы научить все проекты как правильно работать, то у меня для вас плохие новости.. Обсуждать применимость подходов нету никакого смысла без успешного или неуспешного примера их применения. Пожалуйста, не понимайте это как "сначала добейся, а потом критикуй", речь не об этом. Однако хотелось бы повернуть дискуссию в более конструктивное русло и начать говорить про реальные примеры применения тех или иных практик. Вот это действительно были бы ценные и интересные данные.

1

Я не пытаюсь переубедить, в интернете это делать бесполезно.

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

0

Конечно же вся моя аргументация будет сведена к поиску проблем с фичебранчами, потому что единственная цель всего этого огорода с CI - не использовать фичебранчи ) . Понимаете? Мы юзаем CI чтобы не юзать фичебранчи, и я пытаюсь объяснить почему мы не хотим использовать фичебранчи, что в них нам не нравится.

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

-1

Ладно, раз аргументов за не будет, значит не будет.
Вторая беда в том, что вы говорите что фичебранчи это не CI и ссылаетесь на то, что у меня другой проект. Ладно, давайте об опыте.
Мы используем фиче бранчи, сегодня я
реализовал 3 фичи, 2 уже на продакшене, 1 ждёт ревью,
так же вмержили 2 фичи которые я делал ранее, одна из них недельной давности,
1 фича отбараковалась на ревью, пью кофе, делаю правки и обратно в кандидаты.
Итого: 4 мои фичи за 6 часов попали на продакшен, а вы пишете, что фичебранчи - это не CI. (либо фиче-бранчи, либо CI). К тому же фича, которая не прошла интеграцию не остановила разработку как в случае с вашим красным билдом. Что тогда CI, если не это?

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

sherkhan
sherkhan Senior Front-end developer в ScienceSoft
-1

Вы потролить сюда пришли, или вам заняться на работе нечем? Аргументами "за" - полнится статья. Так же вам уже раз 20 сказали прямым текстом: сравнив 2 подхода мы выбрали оптимальный ДЛЯ СЕБЯ!!! Не для вас... Доказывать вам что-то с пеной у рта никто не собирается. А количество реализованых мною фич за сегодня вам перечислить?

-1

Ну вот, пошли обвинения в троллинге.
Комментом выше я писал, что мне плевать какой у вас процесс, я забочусь только о своём. А в статье утверждается "либо фиче-бранчи, либо CI", вот это троллинг, потому как с бранчами CI работает ещё лучше, для этого привёл статистику. А вы опираетесь на идеи 13-ти летней давности, которые не актуальны с приходом новых методологий и инструментов, так при этом ещё и утверждаете что у других не CI.

p.s.Уверен, у вас хорошая компания, кто-то да прислушается к аргументам и попробует использовать бранчи и через год вы сами будете использовать подход, основанный на бранчах, не обязательно как делаем мы, но бранчи обязательно.

0

Суть и цель в минимизации рисков, путем более частых проверок состояний.

1

< В реальности работаешь с двумя бранчами - своим и тот, куда будем мержить, всё остальное дерево нас не волнует. > Не волнует, пока каждый девелопер вот так сам себе пишет код и мерджит свою ветку с некой другой. А чуть позже ведь все девелоперы должны будут смерджить результаты таких мерджей в одну итоговую ветку - вот тогда возможны сюрпризы :)

2

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

Александр Котыня
Александр Котыня Php-developer в Onliner
0

неистово плюсую тебе чувак!!!

0

Так а что с git-flow? Пользовался кто?
А то я тоже "не читал, но осуждаю", но мало ли...

Александр Котыня
Александр Котыня Php-developer в Onliner
0

git-flow не всем подходит действительно, нужно пробовать и смотреть подойдет ли вам)))

0

Саня, привет :)

Я помню, ты хвалил ;)

Александр Котыня
Александр Котыня Php-developer в Onliner
0

привет) хвалил до тех пор пока у нас это работало)

1

Я использовал git + gerrit (review) + jenkins (CI).
В гите имел один бранч и релиз теги, в геррите цепочки виртуальных бранчей (patch set), которые только после ревью и CI можно было вмержить в мастер.
Понятное дело, когда вмержить в мастер нельзя, нужно было перезалить новый патч сет без конфликтов для мастера.
В итоге, в истории все красиво, в геррите можно вести парралельно несколько фич, с любой длинной коммитов, едиственный недостаток это необходимость освежать патч сеты, когда они долго лежат на ревью и имеют конфликты.

Юрий Красовский
Юрий Красовский Web Developer в Wargaming / Гейм Стрим
0

Это здорово, что все тесты проходят за 15 минут, если я правильно понял. Но очень часто бывает, что на выполнение тестов может потребоваться пол дня. Следовательно имеет смысл разбить тесты на юнит, смоук, регрешн и т.д.
Зачем?
Допустим, создадим в CI две похожие задачи staging - master:
отправили (gerrit+jenkins) коммит в мастер, но на самом деле он сначало попадает в
staging - где собирается проект и запускаются юнит, смоук, адванст тесты (которые в сумме отнимают мало времени), можно еще пару тестов с новой функциональности.
Затем и только затем, после успешной сборки и прохождения смоук тестов он попадет в
master - где сново собирается проект и запускаются все оставшиеся тесты после того как (повторюсь) staging отработает без проблем (коммит будет вмержен в мастер вертку)
Очень часто забывают, что CI - это инструмент разработчика, и не нужно боятся сломать билд на staging, так как часто понять работает или нет можно лишь закомитив и пройдя базовые тесты. При данном подходе получается, что в мастере "всегда" рабочий код, на котором можно запускать долгоиграющие тесты. А на staging можно проверять новую функциональность, хоть и базовые тесты.

0

Что мешает (в теории) запустить на мастере сначала "быстрые" тесты, а если они проходят - запускать долгоиграющие? Или вы о том, что у вас в мастере код, который никогда не падает на простых тестах (так сказать, почти "рабочий")?

Юрий Красовский
Юрий Красовский Web Developer в Wargaming / Гейм Стрим
0

Второе.
Я о том, что staging - это своего рода песочница, а master, как вы сказали, почти "рабочий" код.

2

Про длительность тестов отдельный разговор, это очень интересная тема! На самом деле да, у нас абсолютно полный пак тестов проходит за 15 минут. Но это не то чтобы нам повезло так - это результат целенаправленной и постоянной работы над ускорением билда. ИМХО тут вопрос стоит очень просто: либо частые релизы, либо долгий билд. Не уверен, что можно с билдом длительностью в пол-дня релизиться часто и регулярно, при этом не забивая на часть отвалившихся тестов. Мы выбираем быстрый билд и частые релизы, поэтом постоянно работаем над ускорением тестов, а так же покупаем больше железа на тестовые сервера, чтобы выполнять их параллельно. Об этом будет во второй части более подробно.

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

Anonymous
Anonymous .Net Lead Developer в ScienceSoft
1

Вообще Feature Branches не отменяют интеграцию. Об этом можно прочитать у Фаулера - promiscious integration - http://martinfowler.com/bliki/FeatureBranch.html.

Да и branch-by-abstraction требовательна к архитектуре, feature branches выносят изоляцию на другой уровень. Так что всегда найдется гайка с хитрой резьбой.

1

все конечно хорошо. Но не дай Бог расширение проекта...

1

Подозреваю, что все это вообще перестанет работать при команде 20+ девелоперов. Сейчас 15 и пока что работает. Да, конечно, при расширении проекта уже вылезут совершенно другие проблемы и придется применять совершенно другие подходы.

0

Да ничего не нужно будет применять. Нужно будет просто сделать все НОРМАЛЬНО.
То что я вижу теперь - это статья которая пытается объяснить, почему ничего не сделано и нету никакого пресса.

Вангую негативные коменты на мой пост.

0

Вы верите, что есть "НОРМАЛЬНО", которое подойдет для всех проектов? У меня для вас плохие новости

0

Не бывает ни нормально ни правильного. И незачем сразу кидаться фразами &quot;для всех проектов&quot; - намекает на неуверенность в своей позиции.
Согласитесь просто на данный момент ваш &quot;процесс&quot; выглядит как &quot;дефолт инстолейшн&quot;, извините за грубые аллюзии.
Но я, в любом случае, желаю вам успеха. Любой стартап достоин того, что бы быть успешным. Ибо "только смелым покоряются моря!"

0

Я так и не понял вашу точку зрения и позицию, но спасибо за мнение!

0

а что есть НОРМАЛЬНО - кто в епаме решает?)

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
1

я)