Comments 72
Скажите честно, вы Continuous Delivery читали?
Это не основано на Continuous Delivery, скоре на материалах по разным VCS и по СI. Итеративный процессе в agile команде будет основан на CI / использовании бранчей / автоматическом тестировании / автоматическом развертывании, так что сам принцип Continuous Delivery не несет в себе ничего нового.
Так я еще раз спрошу: вы Continuous Delivery читали?
Книгу? — нет, не читал.
Понятно.
Вы что предпочтете — чтобы я тут кратко пересказал аргументы против бранчей, или прочитать их в книжке?
Вы что предпочтете — чтобы я тут кратко пересказал аргументы против бранчей, или прочитать их в книжке?
Аргументы против приводите, книгу занесу в to-read для себя.
Аргументы против бранчинга просты: оверхед на мерж во-первых, и отсутствие гарантии работоспособности mainline (после мержа) во-вторых. Разработка на мейнлайне (в сочетании с еще несколькими приемами) обе эти проблемы решает.
Естественно, мы сравниваем варианты «бранчинг с CI и полным покрытием» и «CD с полным покрытием», без полного покрытия говорить тут не о чем.
Проще говоря, бранчи жизнеспособны только тогда, когда у вас есть административный ресурс, заставляющий всех мержиться не реже раза в день.
Естественно, мы сравниваем варианты «бранчинг с CI и полным покрытием» и «CD с полным покрытием», без полного покрытия говорить тут не о чем.
Проще говоря, бранчи жизнеспособны только тогда, когда у вас есть административный ресурс, заставляющий всех мержиться не реже раза в день.
> и отсутствие гарантии работоспособности mainline (после мержа)
А кто даёт гарантии работоспособности мейнлайна в случае разработки исключительно в мейнлайне?
А кто даёт гарантии работоспособности мейнлайна в случае разработки исключительно в мейнлайне?
Автоматическое тестирование.
Просто когда у вас коммиты в мейнлайн идут часто, то починка проблемы путем отката последнего коммита лишает нас очень маленького куска функциональности (плюс, проблема очень легко локализуется). А бранчи (которые ведут к редким коммитам в мейнлайн) банально умножают время.
Просто когда у вас коммиты в мейнлайн идут часто, то починка проблемы путем отката последнего коммита лишает нас очень маленького куска функциональности (плюс, проблема очень легко локализуется). А бранчи (которые ведут к редким коммитам в мейнлайн) банально умножают время.
Автоматические тесты можно запустить и после мерджа. И пофиксить все упавшие тесты.
Напомню: в вашем комментарии вы написали об «отсутствии гарантий», а не увеличении стоимости поддержки этих «гарантий».
Стало быть, никакого «отсутствия гарантий» нет?
Просто когда у вас коммиты в мейнлайн идут часто, то починка проблемы путем отката последнего коммита лишает нас очень маленького куска функциональности (плюс, проблема очень легко локализуется). А бранчи (которые ведут к редким коммитам в мейнлайн) банально умножают время.
Напомню: в вашем комментарии вы написали об «отсутствии гарантий», а не увеличении стоимости поддержки этих «гарантий».
Стало быть, никакого «отсутствия гарантий» нет?
Автоматические тесты можно запустить и после мерджа. И пофиксить все упавшие тесты.
Это в среднем дороже, потому что изменений вносится больше (если, конечно, мы не мержимся кажый час).
Стало быть, никакого «отсутствия гарантий» нет?
Если быть совсем точным, не «никакого отсутствия гарантий нет», а «эта проблема не является специфичной для бранчей».
Да, это в среднем дороже. И это расплата за «стабильный мейнлайн».
Именно. Из вашего пессимистичного комментария остался лишь аргумент «мерджить сложнее», о котором и так все знали :-)
Вопрос: к чему было разводить пафос на тему чтения книги?
ps: книгу я читал ;-P
Если быть совсем точным
Именно. Из вашего пессимистичного комментария остался лишь аргумент «мерджить сложнее», о котором и так все знали :-)
Вопрос: к чему было разводить пафос на тему чтения книги?
ps: книгу я читал ;-P
Да, это в среднем дороже. И это расплата за «стабильный мейнлайн».
Мейнлайн стабилен в любом случае.
Мейнлайн стабилен в любом случае.
Не совсем. У вас нет песочницы для экспериментов и временного кода.
Плюс в идеологии с фичабранчами вы получаете более простой способ управления фичами — когда какую релизить, и релизить ли вообще.
Но так или иначе — ветка себя исчерпала, продолжения я у неё не вижу (и вообще пошёл спать :-) )
1. Никто не запрещает синхронизировать ветки с mainline, как только в mainline попадают законченные изменения. Перед мержем с mainline никто не запрещает сначала синхронизироваться с оной и прогнать тесты.
2. Любой существенный функционал или рефакторинг не выполнишь за день, частые коммиты таких работ в mainline дестабилизирует его на срок до окончания разработки этого функционала или окончания рефакторинга. Откат последнего коммита в середине работы может привести к тому, что в mainline будет полуготовый функционал, что негативно сказывается на стабильности mainline.
3. Никто не запрещает интегрироваться между ветками, чтобы не накапливался эффект отложенной интеграции, если этот эффект способен вызвать big bang merge.
4. Использование веток позволяет осуществлять параллельную разработку, что позволяет, заплатив определенную цену, обойти ограничения реального мира — например одновременную пост-релиз поддержку и добавление новых фич.
5. Еще раз повторю что обмениваться лучше законченными изменениями но при этом коммитить часто — при работе mainline-only это проблематично.
2. Любой существенный функционал или рефакторинг не выполнишь за день, частые коммиты таких работ в mainline дестабилизирует его на срок до окончания разработки этого функционала или окончания рефакторинга. Откат последнего коммита в середине работы может привести к тому, что в mainline будет полуготовый функционал, что негативно сказывается на стабильности mainline.
3. Никто не запрещает интегрироваться между ветками, чтобы не накапливался эффект отложенной интеграции, если этот эффект способен вызвать big bang merge.
4. Использование веток позволяет осуществлять параллельную разработку, что позволяет, заплатив определенную цену, обойти ограничения реального мира — например одновременную пост-релиз поддержку и добавление новых фич.
5. Еще раз повторю что обмениваться лучше законченными изменениями но при этом коммитить часто — при работе mainline-only это проблематично.
Никто не запрещает синхронизировать ветки с mainline, как только в mainline попадают законченные изменения. Перед мержем с mainline никто не запрещает сначала синхронизироваться с оной и прогнать тесты.
Никто не запрещает интегрироваться между ветками, чтобы не накапливался эффект отложенной интеграции, если этот эффект способен вызвать big bang merge.
Никто не мешает, но очень мало кто делает. Собственно, я об этом и говорю — административный ресурс.
Любой существенный функционал или рефакторинг не выполнишь за день, частые коммиты таких работ в mainline дестабилизирует его на срок до окончания разработки этого функционала или окончания рефакторинга.
Еще раз повторю что обмениваться лучше законченными изменениями но при этом коммитить часто — при работе mainline-only это проблематично.
Маленькие шаги и feature hiding.
Использование веток позволяет осуществлять параллельную разработку, что позволяет, заплатив определенную цену, обойти ограничения реального мира — например одновременную пост-релиз поддержку и добавление новых фич.
Работа на мейнлайне это тоже позволяет.
Коммиты в главную ветку обычно запрещены, разрешены только прямая интеграция (создание веток релизов) и обратная интеграция (слияние веток разработки с главной веткой после окончания цикла разработки).
Главная ветка используется командой QA для непрерывного тестирования и всегда стабильна. Обратная интеграция из веток с релизами возможна только для горячих обновлений — это исправление критических багов прямо на ветке релиза с последующим слиянием ветки обратно с главной.
Главная ветка используется командой QA для непрерывного тестирования и всегда стабильна. Обратная интеграция из веток с релизами возможна только для горячих обновлений — это исправление критических багов прямо на ветке релиза с последующим слиянием ветки обратно с главной.
К сожалению, в такой ситуации фраза «всегда стабильна» — это самообман.
Это не самообман. Стабильным считается состояние когда программа не содержит багов, которые ранее возникали. Мы же, программисты, знаем что баги есть всегда, просто тестировщик или пользователь не нашел условий для их обнаружения. Поэтому если Вы построили тесты, которые были написаны по мотивам найденных ранее багов пользователями или тестировщиками, то когда тесты будут успешно пройдены это даст Вам возможность говорить: «продукт стабильно работает»
Стабильным считается состояние когда программа не содержит багов, которые ранее возникали.
Это откуда такое определение?
(исходя из него нетестированная программа — стабильна)
Поэтому если Вы построили тесты, которые были написаны по мотивам найденных ранее багов пользователями или тестировщиками, то когда тесты будут успешно пройдены это даст Вам возможность говорить: «продукт стабильно работает»
И вы считаете, что мейнлайн (в который разрешено интегрироваться только после окончания разработки) будет всегда успешно проходить эти тесты?
>>Это откуда такое определение?
Тестированием на работе занимаюсь. Поэтому интересоваться «стабильностью» мне по штату положено.
>>будет всегда успешно проходить эти тесты?
К этому надо стремиться и тесты как раз и пишутся для того чтобы получить ответ «Насколько стабилен транк?».
Транк должен находиться в таком состоянии, чтобы в любой момент из него можно было собрать билд для выдачи обновленного продукта. Он может быть развален только при merge с какой-либо фичей или багфиксом.
На практике бывает все куда сложнее, но и там стараются придерживаться того что стабильная ветка это для пользователей, а не разработчиков. Пример из мира OpenSource проект FreeBSD:
current — это тип ветки для разработчиков. Если в эту ветку суются «среднячки» то на форумах появляется очень много «После обновления до… перестало....».
releng_9, releng_8 — это стабильные ветки. Это промежуточное решение между «самым последним словом технической мысли» и «самое стабильное на данный момент». В стабильные вносятся комиты только тогда, когда они обкатаны в current-ветке и код для мержа просмотрен не одним разработчиком и баги маловероятны, хоть и возможны.
releng_9_0, releng_9_1 и др. — это релизные ветки. В них вносятся комиты только с уровнем blocker, critical и security.
Тестированием на работе занимаюсь. Поэтому интересоваться «стабильностью» мне по штату положено.
>>будет всегда успешно проходить эти тесты?
К этому надо стремиться и тесты как раз и пишутся для того чтобы получить ответ «Насколько стабилен транк?».
Транк должен находиться в таком состоянии, чтобы в любой момент из него можно было собрать билд для выдачи обновленного продукта. Он может быть развален только при merge с какой-либо фичей или багфиксом.
На практике бывает все куда сложнее, но и там стараются придерживаться того что стабильная ветка это для пользователей, а не разработчиков. Пример из мира OpenSource проект FreeBSD:
current — это тип ветки для разработчиков. Если в эту ветку суются «среднячки» то на форумах появляется очень много «После обновления до… перестало....».
releng_9, releng_8 — это стабильные ветки. Это промежуточное решение между «самым последним словом технической мысли» и «самое стабильное на данный момент». В стабильные вносятся комиты только тогда, когда они обкатаны в current-ветке и код для мержа просмотрен не одним разработчиком и баги маловероятны, хоть и возможны.
releng_9_0, releng_9_1 и др. — это релизные ветки. В них вносятся комиты только с уровнем blocker, critical и security.
Тестированием на работе занимаюсь. Поэтому интересоваться «стабильностью» мне по штату положено.
Тем не менее, откуда именно такое определение?
Он может быть развален только при merge с какой-либо фичей или багфиксом.
Вот об этом моменте и речь. У вас сразу после мержа (коммита) проходят все тесты? Всегда?
>>Тем не менее, откуда именно такое определение?
Этот термин в голове сам появляется после года тестирования. Рекомендую почитать книгу Коннера про тестирование
>>У вас сразу после мержа (коммита) проходят все тесты?
А какую Вы решаете задачу? Вам же главное положить в «центральное место исходников» такое, чтобы все было хорошо. Так? Вот и делайте 'hg push' в это место, только тогда, когда станет зеленым! Поясню мысль на примере использования Mercurial:
1) клонируем репозитарий hg clone
2) hg pulll vasya-feature-repositary-url.. Забираем новые комиты от Васи
3) hg up default -> hg merge vasya-feature -> hg ci -m «merge with vasya-feature». Мержим комиты Васи с тем что у нас в папке после п.1
4) Тестируем, если что-то красное сообщаем Васе
5) hg pull vasya-feature-repositary-url. Забираем новые комиты после фиксов от Васи
6) Повторяем п. 2 — п. 5 столько раз пока не станет зеленым
п.2 и п.6 повторяем с любым другим разработчиком
Работая с Меркуриал Вы работаете со своей локальной папкой! Мержите только в нее, комитите тоже только в нее, даже когда сети нет.
А когда вы решили что default стал «зеленым», только тогда:
hg push general-default-repositary-url
Основное допущение: general-default-repositary-url это репозитарий для «скачивания» всеми, но заливать должны только «тестировщики» или ответственные за фичу, которые смогут гаррантировать что их мержи не развалят, которые все что нужно сделали на своих локальных машинах или отдали URL-ы на репозитарии со своих машин, чтобы тестировщики их забрали и протестировали.
Этот термин в голове сам появляется после года тестирования. Рекомендую почитать книгу Коннера про тестирование
>>У вас сразу после мержа (коммита) проходят все тесты?
А какую Вы решаете задачу? Вам же главное положить в «центральное место исходников» такое, чтобы все было хорошо. Так? Вот и делайте 'hg push' в это место, только тогда, когда станет зеленым! Поясню мысль на примере использования Mercurial:
1) клонируем репозитарий hg clone
2) hg pulll vasya-feature-repositary-url.. Забираем новые комиты от Васи
3) hg up default -> hg merge vasya-feature -> hg ci -m «merge with vasya-feature». Мержим комиты Васи с тем что у нас в папке после п.1
4) Тестируем, если что-то красное сообщаем Васе
5) hg pull vasya-feature-repositary-url. Забираем новые комиты после фиксов от Васи
6) Повторяем п. 2 — п. 5 столько раз пока не станет зеленым
п.2 и п.6 повторяем с любым другим разработчиком
Работая с Меркуриал Вы работаете со своей локальной папкой! Мержите только в нее, комитите тоже только в нее, даже когда сети нет.
А когда вы решили что default стал «зеленым», только тогда:
hg push general-default-repositary-url
Основное допущение: general-default-repositary-url это репозитарий для «скачивания» всеми, но заливать должны только «тестировщики» или ответственные за фичу, которые смогут гаррантировать что их мержи не развалят, которые все что нужно сделали на своих локальных машинах или отдали URL-ы на репозитарии со своих машин, чтобы тестировщики их забрали и протестировали.
Этот термин в голове сам появляется после года тестирования. Рекомендую почитать книгу Коннера про тестирование
Понимаете ли, в чем дело — термин «стабильный» используется не только тестировщиками, но еще и разработчиками, менеджерами проектов и так далее. И там он имеет другое значение.
Основное допущение: general-default-repositary-url это репозитарий для «скачивания» всеми, но заливать должны только «тестировщики» или ответственные за фичу, которые смогут гаррантировать что их мержи не развалят, которые все что нужно сделали на своих локальных машинах или отдали URL-ы на репозитарии со своих машин, чтобы тестировщики их забрали и протестировали.
Это допущение невыполнимо.
Понимаете ли, в чем дело. Рано или поздно в транке все равно будет мерж, который нужно будет тестировать. Чем сложнее проект, тем чаще это будет происходить. И никакое тестирование на локальной машине не поможет, потому что за время этого тестирования (а оно долгое, потому что тестируется весь код) в транк положили что-то еще, и по факту все равно будет новый мерж.
>>термин «стабильный»
Он один на всех! Он не может быть понятым по разному, а если понимается по разному значит команда о чем-то внутри себя не до конца договорилась.
Напишите, пожалуйста, по-подробнее о том как этот термин, стабильность, может иметь другое значение для тестировщика и разработчика или руководителя проектов?! Очень интересно.
>>Понимаете ли, в чем дело. Рано или поздно в транке все равно будет мерж, который нужно будет тестировать.
Ваш страх комита и мержа основан на том что он лежит «сверху» и его тут же после комита может взять и забрать себе любой из разработчиков. Вы вероятно используете рудиментарную SVN и пора бы уже пробовать новые способы работы к примеру Git или Mercurial
Еще раз, страх этого «проблемного комита или мержа» пропадает, только тогда, когда после него есть другие комиты, которые фиксят проблемный комит или мерж.
Выше я уже написал о том как именно сделать так, чтобы всем стало доступным состояние исходников которое по прежнему «зеленое».
Вам всего лишь нужно положить в центральный репозитарий с исходниками «новая фича возможно с багами » + «набор комитов которые фиксят баги, которые нашлись в результате тестов». Все! На верху будет та ревизия кода, которая проходит тесты.
Попытаюсь пояснить мысль еще раз:
1) Путем hg clone вы работаете со своей рабочей Локальной на вашем ноутбуке папке!
2) С вашего Ноутбука в центральный репозитарий все изменения попадут только после того как вы сделаете hg push. ( Но вы можете его не делать до тех пор пока не приведете в состояние когда проходят тесты)
3) Возможно вы не знаете, но Git, Mercurial делают комиты не в центральный «в сети» сервер исходников, а в локальную на Вашем ноутбуке папку.
4) Ваши комиты, никак, никаким образом, никакой магией не попадут в центральный репозитарий до тех пор, пока вы не сделаете «hg push»
Он один на всех! Он не может быть понятым по разному, а если понимается по разному значит команда о чем-то внутри себя не до конца договорилась.
Напишите, пожалуйста, по-подробнее о том как этот термин, стабильность, может иметь другое значение для тестировщика и разработчика или руководителя проектов?! Очень интересно.
>>Понимаете ли, в чем дело. Рано или поздно в транке все равно будет мерж, который нужно будет тестировать.
Ваш страх комита и мержа основан на том что он лежит «сверху» и его тут же после комита может взять и забрать себе любой из разработчиков. Вы вероятно используете рудиментарную SVN и пора бы уже пробовать новые способы работы к примеру Git или Mercurial
Еще раз, страх этого «проблемного комита или мержа» пропадает, только тогда, когда после него есть другие комиты, которые фиксят проблемный комит или мерж.
Выше я уже написал о том как именно сделать так, чтобы всем стало доступным состояние исходников которое по прежнему «зеленое».
Вам всего лишь нужно положить в центральный репозитарий с исходниками «новая фича возможно с багами » + «набор комитов которые фиксят баги, которые нашлись в результате тестов». Все! На верху будет та ревизия кода, которая проходит тесты.
Попытаюсь пояснить мысль еще раз:
1) Путем hg clone вы работаете со своей рабочей Локальной на вашем ноутбуке папке!
2) С вашего Ноутбука в центральный репозитарий все изменения попадут только после того как вы сделаете hg push. ( Но вы можете его не делать до тех пор пока не приведете в состояние когда проходят тесты)
3) Возможно вы не знаете, но Git, Mercurial делают комиты не в центральный «в сети» сервер исходников, а в локальную на Вашем ноутбуке папку.
4) Ваши комиты, никак, никаким образом, никакой магией не попадут в центральный репозитарий до тех пор, пока вы не сделаете «hg push»
Напишите, пожалуйста, по-подробнее о том как этот термин, стабильность, может иметь другое значение для тестировщика и разработчика или руководителя проектов?!
Я хотел сказать, что есть команды, в которых это слово имеет другое значение.
Все! На верху будет та ревизия кода, которая проходит тесты.
… и не включает изменения соседних разработчиков, которые забыли смержить.
Попытаюсь пояснить мысль еще раз:
Спасибо, я в курсе, как работает DVCS. К сожалению проблемы «очень большой проект, который нельзя протестировать на ноутбуке» они не решаеют.
Ваши комиты, никак, никаким образом, никакой магией не попадут в центральный репозитарий до тех пор, пока вы не сделаете «hg push»
Вот только после того, как я сделаю
hg push случится одно из двух: либо в центральном репозитории будет мерж с изменениями других разработчиков (следовательно, возможные ошибки), либо мой коммит не будет включать изменения других разработчиков (=они пропадут).
Скажите, а как вы с одним мэйнлайном, без бранчей, делаете CD для двух разных клиентов?
Поясните свой вопрос, пожалуйста. Вы имеете в виду, что для двух клиентов зачем-то нужно выкатывать разные версии кода?
Да, именно так. Для двух клиентов надо выкадывать не сильно, но различающиеся версии.
Ну, если вкратце, есть два решения:
(а) выделяем общий код отдельно (как инфраструктуру), он живет на своем мейнлайне, код клиентов по отношению к нему находится downstream
(б) делаем два бранча и плачем о стоимости интеграции
Впрочем, «две несильно различающиеся версии» — это всегда «плачем о стоимости интеграции».
(а) выделяем общий код отдельно (как инфраструктуру), он живет на своем мейнлайне, код клиентов по отношению к нему находится downstream
(б) делаем два бранча и плачем о стоимости интеграции
Впрочем, «две несильно различающиеся версии» — это всегда «плачем о стоимости интеграции».
Что значит «плачем о стоимости интеграции»? Почему вы думаете, что эта интеграция
а) будет дорогой
б) вообще нужна
а) будет дорогой
б) вообще нужна
Если она (интеграция) не нужна, то не нужны и бранчи.
А дорогой она будет ровно потому, что «мелкие изменения» (если они не локализованы в модуль) расползаются по всему проекту, и, как следствие, имеют непредсказуемый импакт (то есть привет сквозному ретесту).
А если можно локализовать изменения для клиента в модуль (как мы пытаемся делать), то все становится проще, и никаких бранчей уже не требует.
А дорогой она будет ровно потому, что «мелкие изменения» (если они не локализованы в модуль) расползаются по всему проекту, и, как следствие, имеют непредсказуемый импакт (то есть привет сквозному ретесту).
А если можно локализовать изменения для клиента в модуль (как мы пытаемся делать), то все становится проще, и никаких бранчей уже не требует.
Ну вот пример, котрый вы просили.
Вам нужно релизить два продукта, имеющих один codebase, но различающиеся в маленькой части. Как вы будете делать это без бранчей?
Вам нужно релизить два продукта, имеющих один codebase, но различающиеся в маленькой части. Как вы будете делать это без бранчей?
Я тоже только что ответил на этот вопрос: по возможности я постараюсь избежать бранчей, изолировав эту маленькую часть в отдельный компонент. Это решение обычно лучше и с архитектурной точки зрения.
Если мне это не удастся — я буду делать бранчи, но стараться рассматривать их как даунстрим.
Если мне это не удастся — я буду делать бранчи, но стараться рассматривать их как даунстрим.
А как вы будете контролировать совместимость этих отдельных компонент и основного продукта? Версионировать их будете отдельно или вместе?
А ещё у вас 10 клиентов, из которых 8 обновляются, а два — не обновляются, потому что у них такая политика. И как вы будете делать багфиксы для тех двух оставшихся клинетов, один из которых брендирован, а второй приносит 50% прибыли?
А ещё у вас 10 клиентов, из которых 8 обновляются, а два — не обновляются, потому что у них такая политика. И как вы будете делать багфиксы для тех двух оставшихся клинетов, один из которых брендирован, а второй приносит 50% прибыли?
А как вы будете контролировать совместимость этих отдельных компонент и основного продукта? Версионировать их будете отдельно или вместе?
Эти решения не отличаются между бранчами и компонентами.
А ещё у вас 10 клиентов, из которых 8 обновляются, а два — не обновляются, потому что у них такая политика.
Не обновляются — не получают багфиксов. Тут же все просто.
Вы реально этого не понимаете? О каких «крупных проектах» вы говорили в своих других комментариях?
Пример:
Команда выпустила продукт версии 1.0 и там есть супер фича №1. В магазин пришел покупатель и купил эту версию продукта. Прошло время и работа команды продвинулась так далеко вперед и сделали фичу №2, фичу №3 и др. фичи. Другими словами они выпустили версию продукта 2.0.
Вдруг, внезапно, неожиданно: покупатель, тот самый, что купил версию 1.0 и купил ровно из-за фичи №1, вдруг находит багу в этой фиче №1.
Что делать с таким покупателем?
Варианты:
1) Предложить купить версию 2.0, в которой эта бага не повторяется? На что он может справедливо ответить: «Так мне 1.0 достаточно, а новые фичи мне не нужны!».
2) Выслать версию 2.0 бесплатно. Как вариант, но это себе в убыток, но так делают и это достаточно распространенная практика
3) Откатиться на состояние исходников по версии 1.0 и поправить багу, выпустить обновленный 1.0.1, выслать это покупателю.
есть и др. варианты, но эти более распространены. Но п.3, который достаточно распространен вынуждает производителя выдавать несколько билдов.
Пример:
Команда выпустила продукт версии 1.0 и там есть супер фича №1. В магазин пришел покупатель и купил эту версию продукта. Прошло время и работа команды продвинулась так далеко вперед и сделали фичу №2, фичу №3 и др. фичи. Другими словами они выпустили версию продукта 2.0.
Вдруг, внезапно, неожиданно: покупатель, тот самый, что купил версию 1.0 и купил ровно из-за фичи №1, вдруг находит багу в этой фиче №1.
Что делать с таким покупателем?
Варианты:
1) Предложить купить версию 2.0, в которой эта бага не повторяется? На что он может справедливо ответить: «Так мне 1.0 достаточно, а новые фичи мне не нужны!».
2) Выслать версию 2.0 бесплатно. Как вариант, но это себе в убыток, но так делают и это достаточно распространенная практика
3) Откатиться на состояние исходников по версии 1.0 и поправить багу, выпустить обновленный 1.0.1, выслать это покупателю.
есть и др. варианты, но эти более распространены. Но п.3, который достаточно распространен вынуждает производителя выдавать несколько билдов.
Да достаточно слова «брендинг». Выпустили вы для партнера брендированную версию: все то же самое, но картинки другие.
Вы сейчас говорите о продукте (коробке). Для продуктов CD применим хуже (хотя и все равно применим). Я же говорил о заказной разработке, где, по факту, нет понятия «версия».
Ну и да, надо понимать, что мало «откатиться на состояние исходников». По факту нужно полностью поднять ландшафт под 1.0, с полным ретестом. Так что тут бранчи уже сами по себе мало значат.
И да, branch-per-release CD не противоречит никак, потому что критичные баги фиксятся в релизных бранчах и немедленно прокидываются в мейнлайн.
Ну и да, надо понимать, что мало «откатиться на состояние исходников». По факту нужно полностью поднять ландшафт под 1.0, с полным ретестом. Так что тут бранчи уже сами по себе мало значат.
И да, branch-per-release CD не противоречит никак, потому что критичные баги фиксятся в релизных бранчах и немедленно прокидываются в мейнлайн.
Я уже написал ниже, что вы почему-то спорите о деталях, не различая главного — жизненного цикла продукта. И делаете это очень воинственно.
Это как говорить, что утюг лучше стиральной машины, аргументируя тем, что после стиралки вещи мятые.
Но вообще спасибо за этот спор — по дороге на работу пришла идея статьи на эту тему. Напишу до весны.
Это как говорить, что утюг лучше стиральной машины, аргументируя тем, что после стиралки вещи мятые.
Но вообще спасибо за этот спор — по дороге на работу пришла идея статьи на эту тему. Напишу до весны.
Я как раз хорошо представляю себе жизненный цикл продукта (хотя, несомненно, жизненный цикл решения я себе представляю лучше).
(чистый) CD все-таки лучше всего подходит для сервисов и решений, и только потом — для продуктов. Но его идеология «интегрируйтесь как можно чаще» часто показывает себя выгодной.
(чистый) CD все-таки лучше всего подходит для сервисов и решений, и только потом — для продуктов. Но его идеология «интегрируйтесь как можно чаще» часто показывает себя выгодной.
Проще говоря, бранчи жизнеспособны только тогда, когда у вас есть административный ресурс, заставляющий всех мержиться не реже раза в день.
Это сложный вопрос, но мне кажется что примеры разработки open-source проектов говорят нам об обратном. Можно далеко не ходить и рассмотреть то, как появился Git и какая модель используется для разработки Linux.
Это сложный вопрос, но мне кажется что примеры разработки open-source проектов говорят нам об обратном. Можно далеко не ходить и рассмотреть то, как появился Git и какая модель используется для разработки Linux.
Я сужу с позиции разработки конкретных заказных проектов со сроками. Там, к сожалению, опыт open-source не очень веселит.
Ваш спор бессмысленный, т.к. и бранчинг, и CD хороши по своему. Вопрос лишь в масштабируемости.
Предложенный Вами способ хорош для маленьких проектов на несколько человек. Там действительно не нужен оверхед на регулярный мердж. Но вот с масштабированием у этого способа не очень. Если разрабатывать что-то типа ядра Linux, то без бранчинга никуда. Просто нужно понять, где та критическая величина проекта, после которой бранчинг будет уместен.
Предложенный Вами способ хорош для маленьких проектов на несколько человек. Там действительно не нужен оверхед на регулярный мердж. Но вот с масштабированием у этого способа не очень. Если разрабатывать что-то типа ядра Linux, то без бранчинга никуда. Просто нужно понять, где та критическая величина проекта, после которой бранчинг будет уместен.
Просто нужно понять, где та критическая величина проекта, после которой бранчинг будет уместен.
У вас нет ощущения, что после какой-то критической величины оверхед на мерж может быть выше, чем стоимость разработки? Я с таким сталкивался.
О чем эта статья? Хотя наверно для начинающих кто еще слабо знаком с этим но уже использовал, будет полезно в качестве укрепления.
Статья про основы использования бранчинга. Целью было описать базовое применение и познакомить с overhead'ом/зависимостями при активном использовании веток. Естественно, использовать нужно только то, что работает и вариантов эффективно применять ветвление намного больше.
Вот если бы тут было реально про оверхед то да. Оверхед это когда каждый день начинается с разрешения конфликтов после мержа. И тут нужны примеры, без примеров и чужого или своего опыта, понять какой оверхед это может принести невозможно.
Семантические конфликты не являются специфичными исключительно для бранчинга и будут везде, где более одного разработчика работает над одним и тем же набором файлов. И например DVCS (Git, Mercurial, etc) хранят полную историю коммитов (в отличие от многих централизованных систем), что облегает процесс мержа.
Мое субьективное ощущение от представления
1) того сколько надо будет сидеть с merge tool чтобы поддерживать эту стратегию
2) того, сколько версий надо будет проверять QA (добавим к этому стоймость квалификации QA чтобы хорошо разбирались в ветках)
3) проблемность Continuous Integration
… довольно неприрятно. Мне кажется такой паттерн больше подходит для OpenSource проектов, где каждый берет свою ветку, разрабатывает функциональность и предлагает ее ответсвенному за коммиты, а стоимость QA более абстрактна. Тем более скорее CI там будет приоритетом ниже, чем в бизнес решении.
Но вообще мысль и статья интересная, спасибо.
1) того сколько надо будет сидеть с merge tool чтобы поддерживать эту стратегию
2) того, сколько версий надо будет проверять QA (добавим к этому стоймость квалификации QA чтобы хорошо разбирались в ветках)
3) проблемность Continuous Integration
… довольно неприрятно. Мне кажется такой паттерн больше подходит для OpenSource проектов, где каждый берет свою ветку, разрабатывает функциональность и предлагает ее ответсвенному за коммиты, а стоимость QA более абстрактна. Тем более скорее CI там будет приоритетом ниже, чем в бизнес решении.
Но вообще мысль и статья интересная, спасибо.
1. Я бы сказал, что это зависит от того, какой системой контроля версий исходного кода вы пользуетесь. В Perforce, конечно, будут проблемы, а вот в Git — всё довольно гладко проходит (почти всегда автоматичесуий мёрдж с минимальной работой программиста).
2. QA тестируют только главную ветку (master/HEAD/production)
3. Сборка CI идёт только для главной ветки (master/HEAD/production)
2. QA тестируют только главную ветку (master/HEAD/production)
3. Сборка CI идёт только для главной ветки (master/HEAD/production)
По пунктам 1 и 2 упомянут механический и интеллектуальный overhead при использовании веток. Каждая новая ветка не бесплатна и добавляет сложность в процесс. Ветки позволяют обойти ограничение реального мира на то, что трудно одновременно стабилизировать и разрабатывать. Тем не менее количество веток должно быть сведено к необходимому минимуму именно по причинам накладных расходов на их поддержку.
По пункту 3 я не считаю что ветки являются препятствием для CI, это упомянуто. Впринципе для того чтобы собирать нужную ревизию необходимо просто обновить рабочую копию, на которой собирается билд на нее, все остальное одинаково для всех веток. Грамотный билд инжиниринг поможет решить этот вопрос. Насколько просто это реализовать зависит от используемой инфрастурктуры.
По пункту 3 я не считаю что ветки являются препятствием для CI, это упомянуто. Впринципе для того чтобы собирать нужную ревизию необходимо просто обновить рабочую копию, на которой собирается билд на нее, все остальное одинаково для всех веток. Грамотный билд инжиниринг поможет решить этот вопрос. Насколько просто это реализовать зависит от используемой инфрастурктуры.
Про обмен только стабильными изменениями понравилось, но это требует определенной дисциплины от команды — каждый должен перепроверять, что его изменения действительно стабильны перед тем, как отдать их коллегам.
В зависимости между ветками забыли упамянуть рефакторинг. В реальных проектах он часто необходим и очень здорово усложняет мерж веток. Бороться с этим сложно. Можно отводить на рефакторинг отдельную фазу до разработки, но на практике заранее всего не угадаешь, что захочется переписать.
Вообще, даже кроме этого, мержить ветки практически всегда трудозатратно и лучшая практика тут, по моему опыту, сводить к минимуму время паралельной разработки, чтобы мержить все по горячим следам и минимум изменений. В идеале команда работает одновременно над одной фичей, с утра начинается работа над отдельными частями, вечером все мержится.
В зависимости между ветками забыли упамянуть рефакторинг. В реальных проектах он часто необходим и очень здорово усложняет мерж веток. Бороться с этим сложно. Можно отводить на рефакторинг отдельную фазу до разработки, но на практике заранее всего не угадаешь, что захочется переписать.
Вообще, даже кроме этого, мержить ветки практически всегда трудозатратно и лучшая практика тут, по моему опыту, сводить к минимуму время паралельной разработки, чтобы мержить все по горячим следам и минимум изменений. В идеале команда работает одновременно над одной фичей, с утра начинается работа над отдельными частями, вечером все мержится.
Коллеги, а давайте, если уж говорим по-русски, не использовать чудовищных слов типа «бранчинг», есть же нормальное слово «ветка» и не менее нормальное «ветвление», то же относится и к калькам фразеологизмов silver bullet, rocket science, etc.
По делу — в условиях скоростей веб-разработки классическая схема одна ветка на релиз, по-моему, не живет вообще, поскольку релизы, если под релизом понимать совокупность изменений, выкатываемую на продакшн, в вебе происходят иногда и больше раза в день, а заниматься по нескольку раз в день мержем веток не слишком продуктивно. Вариант «одна ветка для одного нового вида функциональности» хорошо живет для достаточно больших кусков функционала, для мелких допилов и багфиксов создавать ветки тоже смысла мало (разве что создавать раз в итерацию ветку только для бакфиксов, например). Интересно было бы почитать, какие схемы удобны с точки зрения минимизации количества времени, уходящего на работу с ветвлением.
По делу — в условиях скоростей веб-разработки классическая схема одна ветка на релиз, по-моему, не живет вообще, поскольку релизы, если под релизом понимать совокупность изменений, выкатываемую на продакшн, в вебе происходят иногда и больше раза в день, а заниматься по нескольку раз в день мержем веток не слишком продуктивно. Вариант «одна ветка для одного нового вида функциональности» хорошо живет для достаточно больших кусков функционала, для мелких допилов и багфиксов создавать ветки тоже смысла мало (разве что создавать раз в итерацию ветку только для бакфиксов, например). Интересно было бы почитать, какие схемы удобны с точки зрения минимизации количества времени, уходящего на работу с ветвлением.
Я бы посоветовал не забывать про функциональное строение команды, работающей над проектом, так как он — в идеале — имеет архитектуру с определенным стилем и чем лучше строение команды отвечает этому стилю, тем более производительным будет их труд. Это касается и числа конфликтов при слияниях.
К примеру, если речь идет о Web разработке и проект разрабатывается с использование MVC фреймворка, то желательно, чтобы был программист, который отвечал бы за слой Model и саму схему базы данных (в случае отсутствия DBA).
К примеру, если речь идет о Web разработке и проект разрабатывается с использование MVC фреймворка, то желательно, чтобы был программист, который отвечал бы за слой Model и саму схему базы данных (в случае отсутствия DBA).
>>чтобы был программист, который отвечал бы за слой Model
А если этот человек уйдет в отпуск\уволится? Лучше всего не программиста, а чтобы «роль знающего фичу». А уж эту роль по переменно должны исполнять несколько человек, чтобы не исчезновение конкретного программера не коснулось команду!
А если этот человек уйдет в отпуск\уволится? Лучше всего не программиста, а чтобы «роль знающего фичу». А уж эту роль по переменно должны исполнять несколько человек, чтобы не исчезновение конкретного программера не коснулось команду!
Такой риск есть, но как говориться незаменимых людей не бывает. Другой программист сможет подхватить его работу спустя некоторое время. В любом случае эффект от разделения труда будет покрывать все возможные последствия ухода того или иного члена команды.
Это, простите, какой же эффект?
Извините, но я Вас не понимаю.
В одной фразе:
>>то желательно, чтобы был программист, который отвечал бы за слой Model и саму схему базы данных (в случае отсутствия DBA).
Вы говорите, что нужно все в одного человека «всунуть».
А в другой:
>>В любом случае эффект от разделения труда будет покрывать все возможные последствия ухода того или иного члена команды.
Тут Вы уже говорите, что разделение очень важно.
Как все же Ваша точка зрения?
В одной фразе:
>>то желательно, чтобы был программист, который отвечал бы за слой Model и саму схему базы данных (в случае отсутствия DBA).
Вы говорите, что нужно все в одного человека «всунуть».
А в другой:
>>В любом случае эффект от разделения труда будет покрывать все возможные последствия ухода того или иного члена команды.
Тут Вы уже говорите, что разделение очень важно.
Как все же Ваша точка зрения?
Я сторонник такого подхода, когда функциональное строение команды соотвествует архитектуре проекта над которым она работает. Такой подход будет предполагать взаимодействие между членам команды, аналогичное взаимодействию между функциональными частями в архитектуре проекта.
Никто не говорил про «всовывать» все в одного человека. Как раз-таки наобарот, когда нет разделения труда отдельным разработчикам приходиться заниматься всем понемногу — это плохо.
2 lair — эффект от разделения труда. Капитализм наглядно показал его преимущество.
Никто не говорил про «всовывать» все в одного человека. Как раз-таки наобарот, когда нет разделения труда отдельным разработчикам приходиться заниматься всем понемногу — это плохо.
2 lair — эффект от разделения труда. Капитализм наглядно показал его преимущество.
Вообще-то в этом случае вы имеете бутылочное горлышко в виде этого программиста; когда у вас много функциональности одновременно в разработке, это начинает реально тормозить.
Статья правильная и нужная. Секретов она особых не содержит, но новичкам будет полезно знать, как может быть организован процесс разработки и поддержки ПО.
Отлично! Очень практичная статья, касающаяся практически любой команды разработчиков.
Каждый раз, когда появляется такая статья, появляются бранчинг-срачи. А всё из-за чего? Статья написана с середины. Стратегии бранчинга и вообще CM и CI являются продолжением жизненного цикла конкретного проекта. А жизненный цикл у разных проектов разный.
И вот уважаемый lair садится в лужу, применяя концепции CD туда, куда их применять нельзя.
И вот уважаемый lair садится в лужу, применяя концепции CD туда, куда их применять нельзя.
Sign up to leave a comment.
Основы использования бранчинга для параллельной разработки