Непрерывная интеграция лучше, чем ветвления

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

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

Был случай, когда программист не обратил внимание, что его редактор кода поменял все Tab на пробелы и в результате каждая строка была помечена, как изменённая. Да, git не смог справиться со слиянием и пришлось сравнивать файлы в kdiff, но это было очень давно и тогда не было pull request, чтобы заранее остановить такую ошибку. 

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

Допустим что вы каждый день интегрируете свои изменения в мастер и вот подходит день запуска новой версии сайта, а ваша часть не готова, что делать? Запуск невозможен! Откатывать все ваши ежедневные комменты невозможно. 

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

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

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

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

 

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

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

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

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

 

Следующее утверждение. Пока вы не интегрируете, вы не можете быть уверенными, что вообще изменение работает. Отчасти это правильно, потому что вообще изменение может работать локально, но после интеграции может быть сломано. 

А тогда возникает вопрос – если вы не закончили разрабатывать и не протестировали, а начинаете интегрировать только для того, чтобы не отставать от мастера – вы можете гарантировать, что вообще изменение работает? Вообще нет! 

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

Те, кто за постойную интеграцию приводят пример – а что если кто-то сделает хорошее изменение и это же круто, если все его сразу получат! Да, это круто. А я могу сказать – а что если кто-то сделает плохое изменение и все его получат?

У нас на работе все программисты сливают свой код в master, код тут же доставляется на QA сервера и они только после этого начинают тестировать. Знаете сколько раз программисты были заблокированы потому, что какой-то программист не протестировал свой код и благодаря непрерывной интеграции слил свою работу в мастер, как в унитаз? И как только один программист делает это, то вся компания блокируется и все тестеры сидят и плюют в потолок. 

Виновный потом вынужден срочно фиксить, хотя бы как-то тестировать локально и в нормальном случае это займёт час. Потом создать запрос на слияние и ждать, когда build сервер закончит работу – ещё до часу. Потом ещё как минимум час ждать, когда пройдёт интеграция все выкатиться на сервера для тестеров. Да, все автоматизировано, но в среднем весь процесс занимает 4 часа и все это время огромное количество человек сидит и плюет в потолок. 

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

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

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

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

Утверждение, что постоянная интеграция позволяет вам знать, что делают другие. А зачем? В нынешней компании у нас кажется уже тысяча программистов работает над проектом и я даже при всем желании не буду знать, если кто-то внесёт изменение в мой проект и я получу его при следующем обновлении кода. Да, что-то можете сломаться и я сразу узнаю об этом, но допустим, что вы узнаете о том, что кто-то внёс ломающие изменения не сразу, а на следующий день, сильно  измениться время на работу проекта? Какая разница – вы обновите свой код сегодня или завтра? В большинстве случаев разницы не будет. 

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

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

От того, что вы доставили свой код – вы не доставили решение и очень часто вы на самом деле увеличиваете время разработки. Доставка должна быть только законченного и протестированного продукта. Так что автоматизация доставки важна и необходима, но только для законченного продукта, а убедиться, что он закончен можно только если разрабатывать и тестировать в ветках. 

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

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

Очень хотел бы поработать в компании и команде, где проблемы со слиянием и кто боится делать ветки. У всего есть преимущества и недостатки, но на мой взгляд от постоянной интеграции проблем больше. Делайте ветки и:

- вы будете отгружать только стабильный код

- вы не будете блокировать других

- вы не будете блокировать релизы

- вы легко сможете откатиться

Единственный недостаток веток – возможные конфликты. Что вы делаете, что вы боитесь конфликтов? Пишите тесты, чтобы не бояться интеграции в результате неверного разрешения конфликтов и все.

 

Яркий пример двух подходов – CentOS и CentOS Stream. Почему поднялось такое большое количество разговоров, когда объявили о смерти CentOS? Потому что это стабильный дистрибутив, в который добавляют только протестированные вещи. 

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

Вы можете иметь тестовые сервера, куда будут сливаться ещё не завершённые ветки кода,  Томы тестировать интеграцию, чтобы иметь так сказать rolling ветки кода. Но сливать в мастер я бы все же не стал. 

Я не говорю, что постоянная интеграция с мастером – недопустимо. Если вы хотите и для вас это работает, то вперёд. Для меня такой подход недопустим из-за того, что у него недостатков больше, чем преимуществ и недостатки более серьезные, чем преимущества. Работая на работе с постоянной интеграцией в мастер, я выбираю ветвление и интеграцию только протестированных и готовых проектов. 

---

Внимание!!! Если ты копируешь эту статью себе на сайт, то оставляй ссылку непосредственно на эту страницу. Спасибо за понимание