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

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

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

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

Читати далі →

Як тестувати контейнери RoR з GitLab CI у контейнері

Чим гарний GitLab, так це тим, що будучи за габаритами слоном у посудній лавці, він вміє акуратно встановлюватися і майже завжди працює з коробки. Але погано вміє відновлюватися і дбати про себе, коли дуже прямі руки начебто моїх порушують звичне йому оточення. Не буду заглиблюватися в те, як мені вдавалося вбити його до стану, коли навіть видалення та встановлення з нуля не допомагає, але під уникнення черговий нескінченної епопеї з дебагом і перевстановлення сервера я виніс все це справа в Docker контейнер. Зручно — на робочій машині немає мільйона залежностей, примонтировал директорії для репозиторіїв, журнали та бази даних і все працює. Відновлення — перезаснувати контейнер і згодувати бекап (до речі, не забудьте перевірити свої бекапи, як свідчить досвід GitLab, це не зайве).

З іншого боку, є розроблювальна Rails додаток, яке на реальній машині тримає тільки код; Rails, gems, і все інше спочиває в Docker контейнері. Для своєї роботи вона використовує Redis і Postgres, кожен знаходиться на своєму контейнері. Для кожного контейнера примонтирована директорія, щоб важливі для додатка дані не залишалися всередині.



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

Читати далі →

Вийшов GitLab 8.15

В останньому релізі минулого року ми завершуємо наш Майстер-план і хочемо показати вам дещо цікаве з того, над чим ми працювали.

У GitLab 8.15 з'явилася фіча Auto Deploy – автоматизована налаштування розгортання і додатків для рев'ю (Review Apps). Для проекту на Ruby on Rails така настройка займе менше хвилини. Подивіться, як це працює, у відео на 1:42.
до того Ж, доступ до ваших середовищ (environments) став швидше і простіше: через термінал безпосередньо в GitLab (там же 5:18)
Ми хочемо дати кожному можливість використовувати всю міць контейнерів (containers), безперервної інтеграції і розгортання (continuous integration and deployment, скорочено CD/CI), додатків для рев'ю (review apps) і планувальників контейнерів (container schedulers). У GitLab 8.15 ми взяли на себе всю складну роботу по налаштуванню, і вся вона відбувається абсолютно прозоро. У демонстраційному відео ми налаштовуємо і розгортаємо Ruby-додаток з review apps, кількома середовищами і чатопсом (chatops, управління інфраструктурою через інтеграцію з чатом) на кластер Kubernetes приблизно за 12 хвилин. Без GitLab таке завдання зазвичай займає дні, якщо не тижні.
Для більшості з нас грудень — місяць свят і подарунків. GitLab теж отримав в подарунок багато нових фіч.

Читати далі →

RailsClub 2016: подкасти з Іваном Немытченко та Іллею Зыкиным

Привіт!

RailsClub 2016 зовсім трохи! Поки ми готуємо 600 пакетів роздатки, хочемо нагадати вам, що пора голосувати за Героїв Рубі всі подробиці тут) і ближче познайомити ще з двома нашими спікерами — Іллею Зыкиным (Toptal) та Іваном Немытченко (Gitlab). Наші товариші з RubyNoName подкасту записали з кожним з них по захоплюючому випуску-інтерв'ю.

Послухати можна на сайті подкасту (тут Іван, тут Ілля). А нижче розшифровуємо по фрагменту з кожної розмови.

Читати далі →

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

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


Читати далі →

Gitlab-CI і Ansible-lint



Всім привіт! Ми продовжуємо серію статей про DevOps і шукаємо найбільш ефективні способи керувати конфігурацією, ділячись з вами досвідом. минулих статтях ми розглядали, як вибудувати управління конфігурацією Ansible з допомогою Jenkins і Serverspec, а тепер по вашим проханням розглянемо, як організувати управління конфігурацією з допомогою GitLab-CI.

Ansible-lint — це утиліта для перевірки коректності синтаксису плейбука і стилю коду, яку можна інтегрувати в CI-сервіс. У нашому випадку ми впроваджуємо її в gitlab-ci для перевірки плейбуков на етапі прийняття Merge-Request і виставлення статусу перевірок.
GitLab (GitLab Community Edition) — це opensource-проект, менеджер git-репозиторіїв, спочатку разрабатывающийся як альтернатива платній корпоративної версії Github.

Читати далі →

Введення в GitLab CI

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


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

Читати далі →

GitLab Container Registry

У травні цього року вийшов реліз ГитЛаба 8.8. Частиною цього релізу запуск вбудованого Docker Container Registry. Нижче переклад травневої статті, присвяченій цьому.
Нещодавно нами був випущений GitLab версії 8.8, в якій підтримка CI стала ще краще. Тепер у GitLab можна будувати конвеєри (pipelines) для візуалізації збірок, тестів, розгортання і будь-яких інших етапів життєвого циклу вашого. Сьогодні ми представляємо вам наступний етап: GitLab Container Registry .
GitLab Container Registry — це безпечний приватний реєстру для образів (images) Docker, розроблений з допомогою ПЗ з відкритим кодом. GitLab Container Registry повністю інтегрований в GitLab.
Ключовими особливостями GitLab є безперервність процесу розробки і взаємна інтеграція різних елементів; ці принципи зберігаються і при роботі з нашим реєстром. Тепер за допомогою GitLab Container Registry ви можете використовувати ваші Docker-образи для GitLab CI, створювати спеціальні образи для окремих тегів і гілок, а також багато іншого.
Варто відзначити, що GitLab Container Registry є першим реєстром Docker, повністю інтегрованим в систему управління Git-репозиторіями. Крім того, GitLab Container Registry не потребує установки, так як є частиною GitLab 8.8; c його допомогою можна легко завантажувати і завантажувати образи на GitLab CI. І ще він безкоштовний.
Для того, щоб дізнатися, як включити використання GitLab Container Registry, зверніться до документації для адміністратора.

Читати далі →