Pull to refresh

Comments 9

Раньше тоже пользовался HipChat. Но столкнулся с проблемой, что на мобилках приложение не особо держится и вычищается. Из-за чего все уведомления пролетали мимо. Мы себе этого позволить не могли, так как в таких сообщениях могла содержаться очень важная на текущий момент информация. Что я только не делал (вроде там галочка была, чтобы он не терял соединение при сворачивании, но проблемы она не решала; это было давно, возможно, сейчас проблема исправлена). В итоге перешли в Slack. С тех пор таких проблем не наблюдалось.


Говоря про Bitbucket веб-хуки. Это хорошо, чтобы только уведомить сервер о том, что произошел пуш. И не более. У меня тоже происходила сборка по хуку, но продолжительность сборки была дольше, чем Bitbucket позволял мне, поэтому происходил timeout и еще две попытки, что запукало 3 сборки почти параллельно. Сейчас сделано так: веб-хук только записывает в файл, что произошло изменение (в моем случае пишет еще и в какую ветку, чтобы можно было собрать dev и release отдельно; у меня информация хранится в JSON массиве, чтобы если я запушил сразу в две ветки, прошло две независимых сборки). А по крону запускается ежеминутно скрипт, который и запускает сборку.


Сейчас в планах запуск тестов и сборку проекта перенести в Pipelines Это почти как CI, но попроще и интегрировано прямо в bitbucket. Там 50 минут в месяц бесплатно; для малых проектов хватит. Если хочется больше, то можно докупить 1000 минут за $10.

Да, битбакет выставляет таймаут запросу в 10 секунд. Когда порядка тысячи тестов в приложении, разумеется, тесты не успеют выполниться за такое время. Но на то у нас есть очереди, которые в laravel'е настриваются довольно легко. Забыл об этом упомянуть в статье, спасибо!
Я думал и даже пробывал настроить пайплайны, но, как вы сами сказали, бесплатное время билда — 50 минут. А билдить проект при каждом коммите, по крайней мере, у меня, в итоге займет на порядок больше времени в конце месяца.

Там есть кастомные настройки, которые можно запустить вручную. Там в этом плане все достаточно гибко.
Насколько я знаю, запускается он только на последний коммит и только так, как настроишь. У нас, например, ветка master для разработки, которая ни на что не влияет. Там особо не нужно ничего запускать. А вот ветка release уже предназначена для кода в продакшн. Вот там вот уже и запускать тесты, сборку и прочее.
Я хочу сначала попробовать сделать так, чтобы все запускалось через pipeline, но работало как раньше, через веб-хуки. Если времени хватит, то перейдем в pipeline полностью. Или если начальство не по-жадничает $10 в месяц на дополнительные минуты)

Не знал про кастомные настройки пайплайнов, дякую.
прочитав слово «самотестируемая» подумал про что-то из разряда model based testing. A на самом деле это просто DIY система CI. Тесты тут не генерируются сами. Но как инструкция для начинающих девопсов — полезно.
Интересно, но есть подозрение, что большую часть логики (в частности сработка при пуше на определенную ветку) можно было перенести в piplines гораздо меньшей кровью (с меньшим количеством кода и контроллеров, буквально в 10 строк). В gitlab-ci это точно есть, стоит думать что и у bitbucket в его pipelines. Логика интеграции лежала бы отдельно от логики приложения.

Что касается интеграции с чатом — думаю, тоже много готовых механизмов. А если нет — то можно было бы так же накрутить HipChatService в laravel в тестах.

Pipelines условно платная услуга. 50 минут в месяц может не хватить. Из этих соображений некоторые пилят свои велосипеды (как я и автор статьи).
Гитлаб хоть и бесплатный, но для него лучше купить второй сервер, чтобы сильно основной не нагружать. А, откровенно говоря, не все могут позволить себе иметь два сервера (как я и, возможно, автор статьи)


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

Только заметил, что она уже UNMANTAINED

Sign up to leave a comment.

Articles