Добрый день, хаброчитатели.
Снова хочу поделиться с вами небольшими практическими наработками.
Совсем недавно в рамках одного проекта мне была поставлена задача подготовить для команды тестеров стандартное окружение для сборки и тестирования приложения (Jenkins + SVN + Maven).
Читать полностью »
Что такое Continuous Delivery многие уже, наверное, слышали неоднократно. Одним из ключевых моментов этого процесса является постороение Build Pipeline («трубопровод» от исполнителя к заказчику). А для этого нужно автоматизировать такие процессы как сборка проекта, его разворачивание на инфраструктуре, тестирование и т.д. Отличным инструментом для таких задач является Jenkins. 
Для автоматизации разворачивания приложения простейшим вариантом может быть запуск скриптов Jenkins-ом на хостах инфраструктуры по ssh. А что, если в парк из Linux-инстансов затесался один (или несколько) с Windows? Как деплоить на «вражеский» хост — смотри под катом.
Читать полностью »
В последнее время разработчики все чаще и чаще обращаются к нам с просьбами реализовать CI в Jelastic. Для чего же нужна непрерывная интеграция? Как правило, в проекте, где над разными частями разработчики трудятся независимо, стадия интеграции является заключительной и довольно трудоемкой, соответственно требует дополнительных затрат времени. Переход к непрерывной интеграции позволяет снизить эту трудоемкость, а так же обнаружить и устранить ошибки заранее, пока они еще не укоренились и не выросли в более серьезную проблему. Да действительно, если осуществлять контроль качества на протяжении всего процесса разработки, можно сэкономить и время, и деньги, и усилия, при одновременном повышении качества. Такой подход особенно полезен для крупных проектов с участием большого количества разработчиков.
Сегодня мы покажем, как можно реализовать непрерывную интеграцию в облаке Jelastic на простом примере с использованием Jenkins.Читать полностью »
Всем привет! Думаю у каждого, кто когда-либо настраивал Jenkins для работы с Git-ом возникала проблема генерации ключей на Node-ах.
В очередной раз когда мне этим пришлось заняться я оказался в нелёгкой ситуации — ssh доступа к серверу с Jenkins-ом и к его слейвам у меня не было и, соответственно, ключи я сгенерировать не мог. Но всё оказалось не так плохо.
Думаю, что все знают, что такое модульные тесты, все знают или, по крайней мере, слышали, что такое непрерывная интеграция, и многие программируют на C++. Но я столкнулся с тем, что в интернете не так много информации о том, как же это все объединить и заставить работать вместе. Эта статья является попыткой дать новичками пошаговую инструкцию, которая позволит сделать первый шаг в создании модульных тестов для C++ проектов и организовать покоммитный прогон модульных тестов при помощи CI сервера.
Внимание: много букв и скриншотов, половина из которых избыточны. Особенно для тех кто уже в теме.
В этой статье мы решили немного рассказать о средствах continuous integration (CI), которые используем в компании Дневник.ру, и поделиться небольшими наработками в этом направлении. Большая часть материала может показаться банальной рекламой выбранного движка CI или попыткой вызвать holy war (причем не один), но подобного не было в целях. Статья также не является путеводителем или описанием каких-либо фитч и может быть расценена как статья от кэпа – главное, чтобы она была интересна и вызвала дискуссию.
Я хочу рассказать о созданной нами системе автоматизированного тестирования. Система в моем понимании это не только код, но еще железо, процессы и люди.
Я отвечу на вопросы: Что тестируем? Кто этим занимается? Зачем это все происходит? Что у нас есть?
А затем расскажу как все работает: опишу круги тестирования — с первого по девятый.
Наш продукт — корпоративное web-приложение Service Desk, написано на java.
Я — лид группы автоматизированного тестирования; программисты код которых тестируем; ручные тестировщики, рутину которых мы искореняем; менеджеры верящие, что если тесты прошли, то все не так уж и плохо.
Цель моей группы — уберечь продукт от регрессионной спирали смерти.
Задача группы — необнаружение дефектов максимумом интересных способов с минимальных количеством ручного труда.
900 коротких и не очень сценариев использования приложения закодированых в тесты.
CI Jenkins на шести серверах, три СУБД, два семейства ОС и три браузера под которые пишем продукт.
Всем привет!
В этом посте мы хотим поделиться опытом создания автоматизированной системы сборки мобильных приложений, в нашем случае – игр для платформы iOS.
Мы столкнулись с необходимостью автоматизировать сборку и деплоймент на тестовые устройства, когда размер парка устройств превысил два десятка, а количество проектов, одновременно находящихся в QA достигло 30+. При таких объемах деплоймент билда на тестовые устройства с помощью “Build & Run” в XCode начал заметно затормаживать процесс прохождения QA. Было принято решение об автоматизации процесса сборки и заливки билдов на устройства.
Наша обновленная билд-система состоит из трех основных компонентов:
Процесс прохождения версии проекта от разработчиков до тестировщиков выглядит следующим образом:
В чем заключается основная задача системного администратора? Если выразить ее очень кратко, одним предложением? Еще лучше, одним словом?
Автоматизация.
Автоматизация бывает разных видов — управление пользователями и политиками (Active Directory), управление конфигурацией (Puppet) итд. Для автоматизации каких-то регулярных действий как в Windows, так и в Linux/Unix есть встроенные планировщики задач. Наверняка каждый администратор использует их ежедневно. Это же так удобно — написал скрипт, закинул в cron и забыл о нем.
Проблема в том, что забыть не получается.
Здравствуйте. Получил такое задание, в принципе все ясно из названия темы.
О том как я этого достиг, шаг за шагом, будет следующий пост.
Если что не так — критика приветствуется, это было так сказать исследовательское задание, и перед началом работы над ним у меня не было понятия о данном инструменте, зачем он и так д…
В процессе исследования многие вопросы прояснились.
Читать полностью »
