Комментарии 20
У нас из-за специфики продукта с подобным подходом есть одна проблема. Билд занимает 3-4 часа, smoke тесты ещё примерно час. Если в течение дня сделать хотя бы 4-5 коммитов, то всё это растянется очень надолго. Какие есть общепринятые практики или советы на этот случай? Пока из идей только запускать сборки не по коммитам, а настроить регулярные билды по расписанию (раз в день или в неделю, например, неважно).
Дроби и оптимизируй.
Ну это же не про CI вопрос, а про то как вы вообще разрабатываете.
Разработчик поправил пару строчек кода и дальше ждёт 3-4 часа чтобы как-то увидеть не допустил ли он опечатку? Есть подозрение что нет.
Вот и с CI то же самое. Инкрементальные билды, или проект на части надо резать и тестировать отдельные изменения.
Ну а полный ребилдолл уже конечно как-то по расписанию по ночам или ближе к релизу, или как у вас это происходит обычно.
Это вопрос как раз про CI, а именно про то, как его правильно применять в подобной ситуации. У разработчика есть возможность вручную сделать неполный билд всего за 10-15 минут, на котором можно проверить частично какую-то ограниченную функциональность. Но это ручное девелоперское тестирование и оно происходит до коммита (вы же не заливаете непротестированный код), и тестируются в основном непосредственные изменения. Цель же CI в большей степени (в моём личном понимании) — регрессионное тестирование, то есть проверить, что косвенно ничего не поломалось в других местах. Это разные задачи, и они решаются разными методами и инструментами. В силу специфики продукта (не просто билд какого-то кода, но ещё упаковка кучи стороннего контента, который менеджится другими людьми и командами независимо, а потом интегрируется воедино), внешних зависимостей очень много и сломаться может не только по причине бага в коде. И проверить продукт в целом и быть уверенным в том, что он работоспособен, можно только после полного билда в том виде, в котором будут билдиться официальные пакеты.
P.S. Я прекрасно понимаю, что процессы в описаной мной картине далеко неидеальны, и принцип "разделяй и влавствуй" верный, но давайте оставим это за пределами данного обсуждения и примем как данность :) Очень часто имеем то, что имеем, а переделать с нуля возможности и ресурсов у бизнеса просто нет, но улучшить малой кровью что-то жизненно необходимо. CI в общем правильная штука.
Вы имеете в виду "до мерджа в основную ветку"?
Да, в этом контексте можете так понимать. Имелось в виду, что до того, как этот код будет доступен другим разработчикам / билд-системам, настроенным под официальные билды. Под основной веткой тут может быть мастер или релизные бранчи, неважно.
Меня искренне радует ваш оптимизм :-)
Ну это скорее не оптимизм, а реализм :-) Любые задачи в жизни приходится рассматривать не только с точки зрения того, как оно должно быть в идеальном мире, а больше с точки зрения того, что у нас есть вагон и маленькая тележка других задач с разными приоритетами, майлстоунами, а ресурсы не резиновые, к сожалению. Приходится искать компромиссы и думать, что можно применить в краткосрочной перспективе, а что заложить на будущее. У меня вопрос был именно про первое, поскольку со вторым всё более-менее очевидно :)
Плюс: быстро
Минус: может пропустить баг из-за того, что предыдущие тесты поменяли окружение.
Частично можно компенсировать, если переподнимать стейджинг автоматически каждой ночью.
Инкрементальные билды + отдельно настроенное тестирование для бранча. То есть разработчик, когда только создает ветку для какой-то своей новой фичи/исправления баги, заранее конфигурирует, какие тесты будут для нее запускаться. Если тесты сгруппировать сообразно каким-то внутренним частям, то это ускорит тестирование и уменьшит ложные срабатывания.
А ещё можно оптимизировать сборку, потому что если нет способа получить возможность посмотреть на продукт через 15-20 минут после внесения изменения, то возникает очень много других проблем. Соответственно, кроме дроблений и инкрементальных билдов, можно посмотреть распределенную сборку, выделить под нее побыстрее железо, держать собранными самые "долгие" компоненты. Да и вообще проанализировать, что там конкретно занимает эти 4 часа, потому что зачастую из-за плохо настроенной сборки время возрастает многократно.
Инкрементальные билды + отдельно настроенное тестирование для бранча. То есть разработчик, когда только создает ветку для какой-то своей новой фичи/исправления баги, заранее конфигурирует, какие тесты будут для нее запускаться. Если тесты сгруппировать сообразно каким-то внутренним частям, то это ускорит тестирование и уменьшит ложные срабатывания.
Вот это интересно, спасибо!
А ещё можно оптимизировать сборку, потому что если нет способа получить возможность посмотреть на продукт через 15-20 минут после внесения изменения, то возникает очень много других проблем. Соответственно, кроме дроблений и инкрементальных билдов, можно посмотреть распределенную сборку, выделить под нее побыстрее железо, держать собранными самые "долгие" компоненты. Да и вообще проанализировать, что там конкретно занимает эти 4 часа, потому что зачастую из-за плохо настроенной сборки время возрастает многократно.
Снова всё сводится к тому, что надо ускорять сборку, а это и так понятно. В этом направлении и работаем, нет ничего принципиально нерешаемого здесь, в данном конкретном случае есть даже реальные mid-term планы, как это сократить до ~1-2 часов, всё не так уж плохо, в дальнейшем можно и ещё что-то придумать) Задавая вопрос, я больше рассчитывал поразмышлять над тем, как использовать CI, имея длительные и тяжелые билды как данность, с которой приходится жить и мириться) Такие проекты бывают, и не всегда есть возможность их ускорить, а CI был бы полезен. Сократить время билда тем или иным образом до приемлемого уровня и свести задачу к привычной — вариант, без сомнения, правильный, верный, очевидный и прямолинейный, тут никто не спорит) Просто иногда может получиться, что это невозможно (читай "экономически невыгодно") сделать в силу каких-то объективных причин в разумное время и без чрезмерного усложнения, которое потом выльется в огромную стоимость поддержки. В общем, предлагаю направить мысли в другую сторону))) Кому-то может быть полезно)
Ну вот еще раз скажу, вопрос у вас не про CI, а про то как вы проект собираете. CI — это просто автоматический билд-инженер, которые делает ровно то, что мог бы сделать разработчик, только ему лень делать это на каждый чих, а CI понятие "лень" неведомо.
Т.е. если у вас разработчик руками после изменения прогоняет только некоторый сабсет тестов — то же самое должен делать и CI.
CI — это не абы какая магия. С переменным успехом он прекрасно заменяется хуком в гите (не надо так делать конечно).
Я правильно понял что проблема в том что сборки запускаются последовательно и при 4 коммитах надо ждать 12 часов чтобы дождаться результата проверок?
Если проблему я понял правильно — самым простым я вижу решение запускать сборки параллельно.
Те же 3 часа после коммита всё равно пройдёт до получения результата, но несколько проверок могут идти одновременно и время ожидания между ними не будет суммироваться.
Только токены лучше задавать не прямо в travis.yml а через переменные окружения в настройках Тревиса для репозитория. Чтоб не уплыли.
Из явных минусов представленного подхода — Ваш API ключ Heroku будет лежать в открытом репозитории. После прохождения туториала, я настоятельно рекомендую Вам его обновить. Для реальных проектов ключи определяются через encrypted variables, подробнее Вы можете ознакомиться с этим здесь.
это практика разработки программного обеспечения, которая заключается в слиянии рабочих копий в общую основную ветвь разработки несколько раз в день...
Вот как раз слияние то при CI совершенно не обязательно. И тот же травис умеет например как отдельные ветки так и PR и иже с ними "исполнять".
CI помогает написать сценарий для автоматической "сборки", и исполнить его многократно на "чистой" системе, с компиляцией под разные компиляторы (например gcc/clang), исполнением на разных версиях интерпретаторах (python2.x, python3.x, pypy и т.д.), прогоном тест-кейсов (для разных целевых параметров), проверкой покрытия кода (aka code-coverage) и еще кучей всего — чего разработчик и/или тестер желают на него навесить (например сборкой чего-нибудь с опцией типа "mem-debug" для проверки на memory leaks после исполнения тестов, или проверкой на подключение к "чужому" коду, если то модульно и т.д.).
Особливо дотошные товарищи умудряются даже проверку скорости исполнения (сравнение результатов до/после) воткнуть.
Собственно слияние рабочих копий в общую основную ветвь — это, ИМХО, совершенно вторично здесь.
# get previous best results:
wget .../my-srv/my-url/best-results.txt
# measure previous:
git checkout %{previous}%
my-prog-perf-tests > before.txt
# measure current:
git checkout %{current}%
my-prog-perf-tests > after.txt
# create diff's between both versions:
diff -u before.txt after.txt > test-perf.diff
diff -u best-results.txt after.txt > test-perf-rel-best.diffПолучаем что-нибудь вида test-perf.diff, ну и дальше травим это какому-нибудь анализатору:
# analyze:
my-perf-analyser -best best-results.txt -prev 1 < test-perf.diff > analysis.txt
my-perf-analyser -best best-results.txt < test-perf-rel-best.diff >> analysis.txt
# out in log of CI:
cat analysis.txt
# out the best-results back to the server:
curl -F "file=@best-results.txt;filename=best-results" .../my-srv/my-urlНа самом деле вариантов очень и очень много...
Continuous Integration для новичков