как делают continues integration на 100500 бранчей?
У команды лучше спроси, что она тестировать хочет. С дивана как минимум нужно тестировать мастера и бранчи, соответствующие пул реквестам.
лучше быть богатым но здоровым чем бедным но больным.
лучше всего покоммитное тестирование всех бранчей на любом числе машин где угодно.
лучше всего покоммитное тестирование всех бранчей на любом числе машин где угодно.
У нвс тестится после того как feature-ветка смерджена в основную (devel)
Ну скорей вопрос в том, имхо, новая парадигма бранчевания, принесенная гитом, не соответствует парадигме билд-систем. Твои "как минимум тестировать master и dev" — это как наименьшей кровью впихнуть неупихиваемое. А я спрашиваю, дошла ли мысль до правильного ответа уже?
У нас тесты прогоняются в ветке перед коммитом (зависит от лени разработчика). И автоматический хэлс-чек после коммита в мастер. Это уже делает скрипт на билд-сервере.
Например, тимсити поддерживает много бранчей: http://blog.jetbrains.com/teamcity/2013/02/automatically-bui...
то что гитовые бранчи сами подцепляются это хорошо. Правда есть один минус - параметры и
и билдстепы будут для всех веток одинаковые.
Мы на каждый релизный бранч заводим отдельную конфигурацию и там жестко гвоздями прибиваем имя бранча.
а в конфигурации, где куча бранчей - баним все релизные бранчи.
Но собрать еще полбеды - надо еще и развернуть это все дело. в badoo кажись на каждый коммит поднимается отдельный сервачок, доступный по уникальному адресу типа badoo-dev-45.com. У них ресурсов хватает и правок много
Мы у себя в мобилках стараемся тяжелые фичебранчи спускать в тестинг. Опять же дизайнер посмотрит чего и как.
тяжелый фичебранч - когда есть вероятность, что он окажется каким-то большим и сложным и может подвиснуть на следующий релиз (релизим раз в 2 недели где-то). мелочь всякую в develop фигачим сразу
и билдстепы будут для всех веток одинаковые.
Мы на каждый релизный бранч заводим отдельную конфигурацию и там жестко гвоздями прибиваем имя бранча.
а в конфигурации, где куча бранчей - баним все релизные бранчи.
Но собрать еще полбеды - надо еще и развернуть это все дело. в badoo кажись на каждый коммит поднимается отдельный сервачок, доступный по уникальному адресу типа badoo-dev-45.com. У них ресурсов хватает и правок много
Мы у себя в мобилках стараемся тяжелые фичебранчи спускать в тестинг. Опять же дизайнер посмотрит чего и как.
тяжелый фичебранч - когда есть вероятность, что он окажется каким-то большим и сложным и может подвиснуть на следующий релиз (релизим раз в 2 недели где-то). мелочь всякую в develop фигачим сразу
Мы на каждый релизный бранч заводим отдельную конфигурацию и там жестко гвоздями прибиваем имя бранча.Как вариант в корень дерева положить конфиг для CI — если бранч называется так-то то делать то-то
а в конфигурации, где куча бранчей - баним все релизные бранчи.
так-то оно да, но билдстепы удобно ввкл-выкл делать из тимсити. мы частенько пользуемся.
Continuous Integration - означает отсутствие бранчей. У тебя много патчей к одному и тому же HEAD.
Тестится каждый патч, который приходит на ревью, параллельно, до мерджа. это один из обязательных шагов ревью.
Тестится каждый патч, который приходит на ревью, параллельно, до мерджа. это один из обязательных шагов ревью.
Имхо, нет, не означает
надо еще и развернуть это все дело. в badoo кажись на каждый коммит поднимается отдельный сервачок, доступный по уникальному адресу типа badoo-dev-45.com.
про это я и спрашивал
Нет, означает
Смысл CI - избавиться от расходов на интеграцию. Эти расходы как раз возникают при наличии параллельно развивающихся бранчей. Чем дольше бранчи живут несмердженными - тем больше расходов. Поэтому в рамках CI предлагается минимизировать эти проблемы за счет минимизации времени жизни бранчей.
В Gerrit-based подходе, например, это приводит к вырождению бранчи до размера патчсета, получаем 100500 бранчей размером в один патч.
Если у тебя бранч долгоживущий, то ты просто не делаешь CI для проекта как целого. Хотя можешь конечно делать CI для конкретно этой бранчи, но это такой CI кривой на один глаз.
Смысл CI - избавиться от расходов на интеграцию. Эти расходы как раз возникают при наличии параллельно развивающихся бранчей. Чем дольше бранчи живут несмердженными - тем больше расходов. Поэтому в рамках CI предлагается минимизировать эти проблемы за счет минимизации времени жизни бранчей.
В Gerrit-based подходе, например, это приводит к вырождению бранчи до размера патчсета, получаем 100500 бранчей размером в один патч.
Если у тебя бранч долгоживущий, то ты просто не делаешь CI для проекта как целого. Хотя можешь конечно делать CI для конкретно этой бранчи, но это такой CI кривой на один глаз.
Оставить комментарий
Realist
Теперь все на гите и под каждую фишку новый бранч заводят. Как это все со стороны build&test правильно поддерживать? Типа девелоперы все тестят локально? Билдить любой бранч и выкладывать на тест их вперемежку? Под каждый бранч поднимать (автоматически) свои сервера на облаке?