Версіонування артефактів складання Gradle використовуючи git імена тегів, бранчів і комітів

З переїздом з SVN на GIT і gitlab (плюс переїзд з Jenkins на Gitlab-CI, але його використання також згадаємо), постало питання версионирования одержуваних артефактів складання програми.

В SVN був усім звичний номер ревізії, монотонно збільшується з кожним комітом. Його було зручно додавати в номер версії, і це вирішувало більшість проблем. Але git звичайно надає безліч булочок, і варто переконувати керівництво і всі команду перевести проект на нього…
Зате довелося відбудувати заново процес версионирования одержуваних артефактів складання.

У підсумку зупинилися на дуже хорошому Gradle плагіні github.com/nemerosa/versioning, про його використанні я і збираюся розповісти.

Читати далі →

Перехід з CruiseControl.NET на Jenkins в команді розробників PVS-Studio

<img src=«habrastorage.org/getpro/habr/post_images/1bb/7a8/97e/1bb7a897e17c6d5626f949ad85534c73.png» alt=«Picture » 1" />
Зараз важко уявити розробку програмного забезпечення автоматизованих збірок проекту і тестування. Для мінімізації часових витрат на інтеграцію змін розробників в проект, існують різні готові рішення. У даній статті я розповім про заміну сервера безперервної інтеграції CruiseControl.NET на Jenkins в команді розробників PVS-Studio. А також про те, що нас до цього спонукало, які цілі ми переслідували і з якими проблемами зіткнулися.

Читати далі →

Автоинкремент версій pom.xml через Jenkinsfile

Рано чи пізно всі розробники Java вирішують дрібні завдання в області Continuos Integration. Не обійшла ця доля і мене. Перейнявся я проблемою автоматичного инкремента версій pom.xml при кожній ітерації складання проекту.

Дано: maven проект з декількома модулями, майстер pom.xml і Jenkins-сервер (все як у справжніх пацанів).

Потрібно: щоб при кожному коммите автоматично збирався проект в будь-якому бранчі, а в гілці develop проект не тільки збирався, але і инкрементился номер білду, який заданий третім числом у версії виду 1.0.100-SNAPSHOT.

Для автоматичної зборки Java-проекту в бранчах у нас використовується Jenkins-проект на основі модного нині Multibranch pipeline.

image

Суть цього workflow — періодично (наприклад, раз на хвилину), Multibranch pipeline запускається задача, яка визначає зміни в бранчах і запускає збірку для тих бранчів, в яких щось закоммитили. При цьому, як у справжніх пацанів, для складання бранчу використовується самий справжній Jenkinsfile. Трохи лікнепу: Jenkinsfile — це код на мові Groovy який визначає послідовність та інструкції по складанню проекту. Навіть придумали для цього спеціальний термін «pipeline as code». Здавалося, нічого начебто складного немає — через groovy-скрипт инкрементим номер версії, коммитим і запускаємо maven-складання. Але тут нарисовывается головна проблема — як запобігти наступні (нескінченні) складання після того, як ми оновили автоматом pom.xml? Так, у Jenkins-плагіні під назвою 'git' (той самий, який призначений для детекта змін в бранчах) є навіть спеціальна фіча — «Pooling ignores commit», але от невдача — вона не працює в Multibranch-pipeline. З цього приводу скаржилися багато користувачів і навіть завели спеціальний Jira-айтем. — вперед, будемо винаходити свій велосипед!

Читати далі →

Установка Jenkins і Bonobo Git Server під ОС Windows для складання Android додатків

Добрий день. Не маючи часу копатися в LinuxЗіткнувшись з пробілами інформації при пошуку по мережі інструкцій по установці і настройці під ОС Windows сервера безперервної складання Jenkins для додатків Android, Git сервера та їх інтеграції вирішив поділитися інформацією про те, що у мене вийшло.

Читати далі →

OpenShift + Jenkins + Bitbucket, безперервна інтеграція та публікація з коробки


У цій статті я покажу, як швидко розгорнути середовище для збірки, тестування і публікації додатків використовуючи платформу OpenShift на прикладі PHP проекту. Використовувати буду OpenShift online, але все це можна розгорнути і на власних серверах або в VirtualBox (є готова збірка). Git-сервером для зберігання і версионирования коду буде Bitbucket.


Читати далі →

Отримуємо управління назад у Jenkins Pipeline

Jenkins Pipeline Plugin дуже зручна штука, щоб організувати у себе безперервну доставку ПО (Continuous Delivery). Плагін дає можливість розбити доставку до кінцевого споживача на стадії (stage), кожній з яких можна керувати (на якому сайті, що і як потрібно зробити) і, в кінцевому рахунку, візуалізувати процес доставки. Укупі з Blueocean plugin все це виглядає дуже смачно. У реальному ж житті часом виявляється так, що крім Jenkins-а є ще й інші системи, які беруть участь у цьому процесі (workflow), та постає питання — як інтегрувати їх з наявними рішеннями. Прикладом тут може служити Jira, в якій є якийсь issue падаючий на тестувальника, прокликивающего інтерфейс (ну або здійснює іншу корисну роботу), і тільки після його благословення, наш артефакт має право рухатися далі в бік очікує його клієнта.
Так які у нас є варіанти реалізації?
Читати далі →

Боротьба з загадковими падіннями MSBuild на XamlTaskFactory

Наша команда розробляє багатоплатформовий ядро додатків, яке має збиратися на 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: тестуємо плейбуки (частина 2)

Отже, в нашій попередній статті ми розглянули як можна швидко і просто налаштувати середовище для тестування плейбуков і ролей Ansible. Це все, звичайно, дуже добре і зручно, але чому б нам не автоматизувати весь процес внесення змін в інфраструктуру від написання плейбука до внесення змін сервера?

image

Нагадаю кілька умов, при яких ми будемо виконувати тестування конфігурацій:

1. Вся конфігурація зберігається в git-репозиторії;
2. Jenkins періодично опитує git-репозиторій з нашими ролями/плейбуками на предмет внесених змін;
3. При появі змін Jenkins запускає job з тестуванням конфігурації. Тести складаються з двох етапів:
3.1 Kitchen-CI бере оновлений код з репозиторію, запускає повністю свіжий docker-контейнер, заливає в них оновлені плейбуки з репозиторію і запускає Ansible локально, в docker-контейнері;
3.2 Якщо перший етап пройшов успішно, у docker-контейнері запускається serverspec і перевіряє, чи коректно постала нова конфігурація;
4. Якщо в Kitchen-CI всі тести пройшли успішно, то Jenkins ініціює заливку нової конфігурації.

В ідеалі, весь процес від написання плейбука і коміта в репозиторій до внесення змін сервера, повинен проходити без нашої участі. Сильно заглиблюватися в установку Jenkins і докладно розписувати про пайплайнах в даній статті не планується. Перше робиться без проблем стандартних репозиторіїв, а друге — суто індивідуальне.

Читати далі →

Як побудувати грамотну систему тестування? Інсайти від QA-експертів: відео та презентації з митапа в Wrike

Які інструменти хмарного тестінгу використовують в Яндексі? Як влаштовано тестування в Badoo? Що являє собою система автоматизованого frontend-тестування в Wrike?



Пару тижнів тому наш Wrike Tech club зібрав близько 150 фахівців з тестування, щоб обговорити в пітерському офісі компании нагальні, вічні і, на перший погляд, майже нерозв'язні проблеми QA у великих (і не дуже) проектах. Як і обіцяли, ділимося відео та презентаціями з зустрічі.


Читати далі →

Автоматизація workflow невеликої команди розробки (Частина 2)

У попередній публікації я описував список продуктів і їх параметри, які необхідні для роботи нашої організації.

У цій статті я спробую описати, як ми використовуємо в щоденній роботі всього колективу розробки.

Протягом 4-х років у нас виробився такий формат команди розробки:
  • 1 Project Manager, він же Product Manager, він же Delivery Manager.
  • 4-5 програмістів
  • 1 Team lead
  • 3-4 QA
  • 1 Аналітик
  • 1 Техпис (іноді він же і аналітик в одній особі).
У підсумку команда розміром близько 10-11 осіб. Таких команд (осередків) у нас кілька.

Робота в основному в стилі стартапу, коли немає конкретної та детальної постановки. Дуже часто експерименти на кшталт «а давайте спробуємо так, подивимося що вийде» або «ви класно все зробили, але тепер треба все зовсім по-іншому».
За ці роки концепцію нашої роботи можна описати однією фразою — «стрімка зміна концепції».
Ясна річ, що застосувати в таких умовах різні методології ніяк не вдавалося.

Починав у цій системі я як програміст, потім Team lead, ну а тепер PM (DM). Тобто керую, повністю беру участь в проектуванні і іноді навіть пописываю. У часи мого програмування у мене був чудовий ПМ (виходець з тестувальників), яка підтримувала всі мої ідеї щодо автоматизації workflow. Навіть більше того, концептуально цей процес придуманий їй, а я вже зміг його технічно реалізувати і в деяких місцях вдосконалити.

Читати далі →