Працюючи в многомодульном maven проекті, часто доводиться вносити зміни в кілька пов'язаних модулів одночасно. І якщо хочеться зібрати лише заторкнуті модулі, то на жаль maven не надає нічого автоматичного. Якщо трохи погуглити, то на stackoverflow можна знайти просте однорядкове рішення:
mvn install -amd -pl $(svn st | colrm 1 8 | sed 's /.* '| xargs echo | sed 's- -,:-g' | sed 's ^ : ')

На цьому можна було б і закінчити. Але мені хотілося більшого — чого конкретніше і як я цього добивався під катом.
Читати далі →



З допомогою VSTS можна автоматизувати розгортання та тестування програмного забезпечення в різних середовищах. Суть Continuous Integration полягає у виконанні частих автоматизованих збірок проекту для якнайшвидшого виявлення і вирішення інтеграційних проблем. Зокрема CI дозволяє автоматизувати регрессионное тестування додатків.

В якості ознайомлення з можливостями VSTS пропоную опублікувати і налаштувати Continuous Integration c Unit тестами простого UWP програми.

Читати далі →

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

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

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

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

Читати далі →

Як я базу в GIT закачував

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

В інших і зовсім приводить до засмічення бази сміттям з інших майданчиків і до помилок після «найпростішого мержа».

Знайомих з такими ситуаціями, критиків і знають точно, що я винайшов велосипед — запрошую під кат.

Читати далі →

Автоинкремент версій 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-айтем. — вперед, будемо винаходити свій велосипед!

Читати далі →

GitLab CI: Розгортання і середовища розгортання

У даній статті мова піде про історії успіху уявного новинного порталу, щасливим власником якого є ви. На щастя, ви вже зберігайте код проекту на GitLab.com і знаєте, що для тестування можна використовувати GitLab CI.
Тепер вам цікаво, можна піти далі і використовувати CI ще й для розгортання проекту, і якщо так, то які можливості відкриваються.
Щоб не прив'язуватися до якоїсь конкретної технології, припустимо, що ваше додаток є простим набором HTML-файлів, ніякого виконання коду на сервері, ніякої компіляції JS assets. Деплоить будемо на Amazon S3.
У автора немає мети дати рецепти для конкретної технології в цій статті. Навпаки, приклади коду максимально примітивні, щоб надто на них не зациклюватися. Сенс в тому щоб ви подивилися на фічі і принципи роботи GitLab CI в дії, а потім застосували їх для вашої технології.


Читати далі →

Введення в GitLab CI

Публікую переклад моєї статті з блогу ГитЛаба про те як почати використовувати CI. Інші переклади гитлабовских постів можна знайти на блозі компанії Softmart


Уявімо на секунду, що ви не знаєте нічого про концепції безперервної інтеграції (Continuous Integration — CI) і для чого вона потрібна. Або ви все це забули. У будь-якому випадку, почнемо з засад.
Уявіть, що ви працюєте над проектом, в якому вся кодова база складається з двох текстових файлів. Більш того, дуже важливо, щоб при конкатенації файлів в результаті завжди виходила фраза "Hello world." Якщо ця умова не виконується, вся команда позбавляється місячної зарплати. Так, все настільки серйозно.
Hello wolrd

Читати далі →

Gitlab-CI



Всім привіт.
У нас не так багато завдань, яким необхідний повноцінний CI. Деякий час ми використовували в якості CI-сервісу Jenkins. Там все досить очевидно, він простий і гнучкий у налаштуванні, має купу плагінів, але пару раз ми зіткнулися з OOM-вбивцями агентів на слабких машинах і вирішили розглянути в якості CI-сервісу Gitlab CI, тому що ми любимо експерименти і тим більше в коментарях до минулого нашої статті задавали таке питання.

Читати далі →

Maven vs Gradle? Це неправильна постановка питання

Написати, нарешті, цей пост мене змусила вже давня дискусія ось до цього посту на тему, яка час від часу спливає то там, то тут.

Я багато разів мав можливість переконатися, що далеко не всі однаково розуміють, у чому ж полягає декларативність vs процедурність тієї чи іншої системи складання. Основною перевагою інструменту складання часто вважається можливість писати алгоритми складання на зручному мовою. Потрібен DSL, нікуди без нього.

Читати далі →

Спільне використання checkstyle і gerrit

Преамбула

Якийсь час назад, вирішивши навести порядок в нашому коді, вибрали в якості системи контролю стилю код Checkstyle. Думаю, проект знайомий, в поданні не потребує. До цього в команді ми використовували загальний репозиторій, де зберігалися налаштування code styles, intentions для ідеї.

Додаючи проект checkstyle, ми в першу чергу мали на меті можливість перетворити помилки в оформленні стилю коду помилки збірки. Легким рухом руки checkstyle був підключений до кореневої pom проекту, розробники були ознайомлені з нововведенням, збірки на Teamcity навчилися перевіряти checkstyle перед комітом.

Та ось невдача: у наших рядах з'явився шкідник. Як ми з ним боролися — під катом.

Читати далі →