В этой статье я покажу, как быстро развернуть среду для сборки, тестирования и публикации приложений используя платформу OpenShift на примере PHP проекта. Использовать буду OpenShift online, но всё это же можно развернуть и на собственных серверах или в VirtualBox (есть готовая сборка). Git-сервером для хранения и версионирования кода будет Bitbucket.
Читать полностью »
Jenkins Pipeline Plugin очень удобная штука, чтобы организовать у себя непрерывную доставку ПО (Continuous Delivery). Плагин даёт возможность разбить доставку ПО до конечного потребителя на стадии (stage), каждой из которых можно управлять (на каком узле, что и как нужно сделать) и, в конечном счёте, визуализировать процесс доставки. Вкупе с Blueocean plugin всё это выглядит очень вкусно. В реальной же жизни подчас оказывается так, что кроме Jenkins-а есть ещё и другие системы, которые участвуют в этом процессе (workflow), и встаёт вопрос — как их интегрировать с имеющимися решениями. Примером тут может служить Jira, в которой есть некий issue падающий на тестировщика, прокликивающего интерфейс (ну или совершающего другую полезную работу), и только после его благословения, наш артефакт имеет право двигаться дальше в сторону ожидающего его клиента.
Так какие у нас есть варианты реализации?
Наша команда разрабатывает кроссплатформенное ядро приложений, которое должно собираться на Windows под Visual Studio 2015, Linux с gcc 4.9+, MacOS, iOS, Android и Windows Phone 8.1+. Для автоматической проверки кода на Jenkins настроены сборки под все требуемые конфигурации. Задача сборок отловить код, который не собирается на одной или нескольких из платформ или не проходит юнит-тесты и не дать ему попасть к командам конечных приложений до внесения соответствующих исправлений. Такой процесс CI позволяет разработчику локально использовать удобную ему операционную систему и среду разработки, будь то Visual Studio, XCode, QtCreator или вообще vim + ninja, при этом не бояться, что его изменения не соберутся или будут валить тесты в другом окружении.
В идеальном мире красная сборка на Jenkins (именно он у нас используется в роли билдсервера) говорит о проблеме в коде. Увидев красный свет на висящем в углу комнаты мониторе, «дежурный за сборку» должен пойти и поправить найденную проблему. В реальности же причины падения билда могут быть самыми разными, например, обрыв соединения с нодой, на которой проходила компиляция, закончившееся место на диске или прилёт инопланетян. Такие ложные срабатывания отнимают лишнее время у команды, притупляют внимание и в целом снижают доверие к CI в команде. Историю борьбы с одной из таких проблем я хочу рассказать.
Читать полностью »
Итак, в нашей прошлой статье мы рассмотрели как можно быстро и просто настроить среду для тестирования плейбуков и ролей Ansible. Это всё, конечно, очень хорошо и удобно, но почему бы нам не автоматизировать весь процесс внесения изменений в инфраструктуру от написания плейбука до внесения изменений на сервера?
Напомню несколько условий, при которых мы будем выполнять тестирование конфигураций:
1. Вся конфигурация хранится в git-репозитории;
2. Jenkins периодически опрашивает git-репозиторий с нашими ролями/плейбуками на предмет внесённых изменений;
3. При появлении изменений Jenkins запускает job с тестированием конфигурации. Тесты состоят из двух этапов:
3.1 Kitchen-CI берёт обновленный код из репозитория, запускает полностью свежий docker-контейнер, заливает в них обновлённые плейбуки из репозитория и запускает Ansible локально, в docker-контейнере;
3.2 Если первый этап прошёл успешно, в docker-контейнере запускается serverspec и проверяет, корректно ли встала новая конфигурация;
4. Если в Kitchen-CI все тесты прошли успешно, то Jenkins инициирует заливку новой конфигурации.
В идеале, весь процесс от написания плейбука и коммита в репозиторий до внесения изменений на сервера, должен проходить без нашего участия. Сильно углубляться в установку Jenkins и подробно расписывать о пайплайнах в данной статье не планируется. Первое делается без проблем из стандартных репозиториев, а второе — сугубо индивидуальное.
Читать полностью »
Всем привет. Это продолжение статьи о том, как iOS-отдел компании Лайв Тайпинг внедрил методологию CI и развернул сервер для автоматизации сборок на Jenkins. Как мы и обещали, вторая часть посвящена тому, как получить основные метрики кода, заархивировать проект в .ipa и настроить взаимодействие со Slack.
Читать полностью »
Какие инструменты облачного тестинга используют в Яндексе? Как устроено тестирование в Badoo? Что представляет собой система автоматизированного frontend-тестирования в Wrike?
Пару недель назад наш Wrike Tech club собрал около 150 специалистов по тестированию, чтобы обсудить в питерском офисе компании насущные, вечные и, на первый взгляд, почти неразрешимые проблемы QA в больших (и не очень) проектах. Как и обещали, делимся видео и презентациями со встречи.
Хорошо, хорошо. Я не совсем «взломал Facebook». Я добился выполнение команды уровня операционной системы на одном из серверов Facebook.
Рассказ, как я это сделал.
Читать полностью »
Воодушевленный такой прекрасной идеей, как светофор, отображающий состояние билда, я решил, что нашей команде нужен такой же. Я не хотел руководствоваться прочитанными мною статьями, поскольку они используют слишком дорогие для меня решения. Поэтому, вооружившись идеей, я набросал очень приблизительный план работы для команды, а у себя в голове держал простые принципы, которым хочу следовать.
Под катом светофор из цветомузыки и пластиковых бутылок, USB модуль управления светофором на attiny2313 за доллар, а так же софт для опроса Jenkins и управления USB модулем на Node.js.
Читать полностью »
Днепропетровский офис DataArt принял первую встречу сообщества PHP-разработчиков. Перед презентациями гостей встречал мимимишный мопс Чупик — главный герой нашего видеоприглашения на встречу. Которая, кстати, собрала более полусотни девелоперов, которые с огромным удовольствием прослушали четыер доклада о РНР и как с ним жить.
Читать полностью »
Что происходит с кодом после того, как он написан? Во многих областях разработки ПО его жизнь только начинается. Например, в разработке для веба, приложение исполняется где-то на сервере. Значит, после написания кода встаёт задача интегрировать его в приложение и доставить на конечную машину. Именно этот процесс мы сегодня обсудим.
Данный текст предназначен широкому кругу разработчиков и рассчитан на тех, кто мало знаком с процессом выкладки кода. Так же этот текст может быть полезен тем, кто строит систему деплоймента и находится в поиске идей.
Статья написана на основе материалов внутреннего семинара компании Аори, и рассказывает о принципах деплоймента на примере процесса, построенного у нас.
Читать полностью »
