Вийшов GitLab 8.14

Уявіть, що ви робите рев'ю коду нової фічі. Крім якості коду вам також цікаво, як вона буде виглядати і працювати у вашому продукті і наскільки зручно буде її використовувати. Раніше вам довелося б перервати процес розробки на власній робочій машині, зробити checkout на проверяемую гілку, провести потрібні міграції БД і запустити всю робочу середу (development environment), необхідну для застосування. Тепер вам достатньо зайти в мерж-реквест цієї гілки на GitLab. Там буде посилання на вже працюючий додаток, розгорнуте в окремій середовищі.
Нарешті, рев'ю завершено, і ви даєте колезі зворотний зв'язок у чаті.
Замість того, щоб вирішувати, хто з вас піде заводити нову задачу в трекері, ви можете створити завдання і оцінити час на її розробку, не виходячи з чату. Аналітика циклу розробки (cycle analytics) відразу врахує цю оцінку і буде показувати вам весь шлях завдання до випуску на production, повідомляючи про можливі вузьких місцях.
Усе це і багато іншого можливо в новій версії GitLab 8.14. У ній з'явився облік робочого часу, додатки для рев'ю (Review Apps), команди чат (chat commands) і нові можливості аналітики циклу розробки.
MVP цього місяця — Toon Claes. Він реалізував кнопку для видалення відразу всіх гілок, смерженных
master
.
Дякую, Toon!
Облік часу, бета-версія (ЇЇ)
Облік часу, витраченого на завдання — непроста справа. Результати цього підрахунку потрібні як розробникам, які отримують погодинну оплату, так і керівникам, аналізує витрати ресурсів на завдання і проекти. Для обліку часу застосовується безліч інструментів, але зазвичай вони не інтегровані в процес розробки.
Облік часу (time tracking) в GitLab дозволяє фіксувати затрачений на виконання завдання час безпосередньо в процесі роботи.
З допомогою слеш-команди
/estimate
завданню призначається оцінка часу. Тією ж командою можна в будь-який момент змінити оцінку. Нагадаємо, що слеш-команди пишуться в описі завдання або у коментарях, виконуються при їх збереженні і не відображаються в отриманому тексті.
/estimate 6h

Після того як ви працювали над завданням якийсь час, ви можете врахувати його за допомогою команди
/spend
:
/spend 3h

Це буде відразу відображено в інтерфейсі:
Time Tracking Beta in GitLab 8.14
Облік часу буде доступний всім нашим клієнтам з Enterprise Edition в пробному режимі протягом періоду бета-тестування, після чого стане окремим платним продуктом.
Ми з нетерпінням чекаємо ваших пропозицій про те, як можна поліпшити облік часу, щоб він був вам корисний. Будь ласка, публікуйте їх в трекері задач або пишіть в коментарях до цієї статті.
Наприклад, ми думаємо про реалізацію звітів, API, урахування часу на дошках задач and і різних інших можливостей.
Документація на Time Tracking
Команди чату (експериментальна можливість)
Схоже, що за останні кілька років обговорення переїхали з переговорок в онлайн-чати. Чати допомагають спільній роботі, і саме в них народжуються нові ідеї. Це важлива частина концепції «від ідеї до реалізації» (idea-to-production), яку ми прагнемо реалізувати в GitLab. Команди чату пов'язують його з іншими можливостями GitLab: репозиторіями, трекером завдань і конвеєрами CI/CD.
Chat Commands in GitLab 8.14 with Mattermost
Зараз розробка команд чату пройшла всього одну ітерацію, але вже реалізована можливість швидко створювати і переглядати завдання. Ось приклад команди, яка створює завдання з заголовком і описом:
/gitlab issue create Поліпшити дошки завдань
Давайте зробимо дошки завдань ще краще!

Якщо включити ChatOps, можна використовувати чат для управління розгортанням на production (зрозуміло, для цього потрібна обліковий запис і відповідні права):
/gitlab deploy staging to production

В поточній ітерації підтримка команд чату реалізована для Mattermost, який поставляється в пакеті GitLab Omnibus. Найближчим часом буде додана підтримка для Slack. Набір команд поки що обмежений, але ми збираємося його розширити і будемо раді вашим відгукам.
За подробицями звертайтеся до документації по командам чату
Review Apps
Review Apps є новим словом у процедурі рев'ю коду. Замість простого перегляду коду Review Apps надає повноцінну середу, в якій запускається ваш додаток, з можливістю тестування і внесення змін на льоту.
Експериментальна підтримка Review Apps була опублікована в GitLab 8.12, в GitLab 8.13 була додана їх поліпшена версія, і ось, нарешті, з версією 8.14 поставляється повноцінна фінальна версія Review Apps.
Тепер додаток Review Apps автоматично запускається для кожної гілки і знищується при її видаленні. Ми використовуємо цю функціональність з офіційним блогом GitLab, і вона чудово себе показує. Можливості Review Apps настільки вражають, що ми написали про них окремий пост.
<a href="/2016/11/22/ introducing-review-apps/>Вступний пост про Review Apps


Документація по Review Apps
Події Cycle Analytics
З допомогою Cycle Analytics можна стежити за тим, як швидко ваші ідеї доходять до реалізації в отриманому продукті, а також де вони застряють на шляху. Для того, щоб додати наочності, тепер будуть відображатися останні події кожній стадії.
Improved Cycle Analytics in GitLab 8.14
Введення цієї функціональності дозволяє з легкістю відстежувати, що відбувається на кожній стадії, а також швидко виявляти й усувати причини уповільнення.
Документація по Cycle Analytics
Заборона мержа до закінчення рев'ю
Не варто проводити мерж коду до успішного проходження всіх тестів і закінчення рев'ю. У GitLab вже якийсь час існує можливість заборони мержа до проходження тестів, проте до останнього часу того ж самого можна було зробити щодо рев'ю коду.
Починаючи з GitLab 8.14 можна заборонити мерж коду до тих пір, поки всі обговорення в мерж-реквесте не будуть закриті. Тепер неможливо випадково упустити з уваги останні коментарі внизу сторінки (хоча для цього у нас є прекрасний віджет зверху); тільки перевірений і верифікований код потрапить у production.
Prevent merge until review is done in GitLab 8.14
Увімкніть цю опцію в налаштуваннях проекту.
Prevent merge until review is done in GitLab 8.14
Дякую Rodolfo Arruda за реалізацію цієї відмінною фічі!
Документація по обговорень мерж-реквестов
Видалення всіх смерженных гілок
Toon Claes реалізував, здавалося б, очевидну, однак чомусь досі відсутню фічу — єдину кнопку для видалення всіх смерженных гілок в GitLab.
При натисканні запитується підтвердження дії і, в разі згоди, запускається процес видалення гілок. Ця кнопка знаходиться у розділі Repository ➔ Branches.
Quickly delete all merged branches in GitLab 8.14
Це не призведе до видалення захищених гілок.
Дякую Toon Claes!
Підписка на групові мітки
У GitLab 8.13 були додані групові мітки, а з поточної версії з'явилася можливість підписатися на них. З допомогою цього можна отримувати повідомлення про події в масштабі груп. Наприклад, з'явилася можливість отримувати нотифікації при створенні нової задачі з міткою
customer
, в результаті чого можна легко відслідковувати всі завдання з такою міткою у всіх проектах в рамках однієї групи.
Поліпшені оповіщення про конвеєрах (pipelines) поштою
У разі падіння конвеєра (pipeline) вам буде надіслано лист, в якому міститься причина падіння. Так що тепер немає необхідності відразу лізти в логи, щоб зрозуміти, треба негайно збирати всю команду або достатньо просто перезапустити складання.
Better pipeline notifications in GitLab 8.14
Поліпшення інтеграції з JIRA
Ми знаємо, що багато хто з вас активно користуються JIRA. Ми багато працюємо над поліпшенням її інтеграції з GitLab. Нижче деякі зміни, які ми зробили в цьому релізі. Ми із задоволенням вислухаємо ваші пропозиції щодо інших поліпшень.
Читайте виправлення документацію щодо інтеграції з JIRA
Віддалені посилання, пов'язані з завданнями в JIRA
Ще простіше стала зв'язок задач JIRA з коммитами в GitLab. Коли ви згадуєте завдання JIRA в коммите або мерж-реквесте, в цю задачу додається зворотній посилання на комміт або реквест. Ви можете написати, що він
Fixes
завдання в JIRA або просто згадати її — будьте впевнені, всі посилання з'являться як треба.
Remote Issue Links to JIRA with GitLab 8.14
Мерж-реквест: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7413
«тихе» взаємодія GitLab і JIRA
Коли ви налаштовуєте інтеграцію JIRA і GitLab, за замовчуванням кожен комміт і мерж-реквест в GitLab, який посилається на завдання в JIRA, створює коментар у цій задачі в JIRA. Одні люди люблять бути в курсі всіх деталей події, інші віддають перевагу більш тиху роботу.
У GitLab 8.14 ви можете заборонити створення коментарів при зверненні до задачі в JIRA в коммите або мерж-реквесте.
Покращений вигляд
GitLab у версії 8.14 став красивішим і простіше у використанні. Нижче деякі зміни:
Тепер ви можете бачити, кого ви згадуєте:

Конвеєри та метаінформація для виглядають краще, ніж раніше:

Тепер ми показуємо інформацію про оточення (environment) на сторінці білду:

Конвеєри тепер показують, коли пропускаються конкретні збірки (builds):

Простіше дивитися, що залишилося в поточному конвеєрі:

Покращена доступність (accessibility)
Наші чудові команди UX і фронтенда багато працювали, щоб поліпшити доступність GitLab. Найбільш виділяються в цьому місяці зміни:
  • Ми додали кнопку «перейти до вмісту при натисканні Tab для переміщення по різних активним об'єктів на веб-сторінці… Це дозволить вам швидше дістатися до контенту і пропустити навігаційні частини.
  • Усі випадаючі меню, кнопки і anchors тепер візуально виділяються, коли ви переходите з ним за допомогою Табуляції.
  • Ми збільшили контраст між фоном і анкорами.
Ми завжди із задоволенням вислухаємо ваші пропозиції щодо покращення доступності GitLab.
Підтримка реєстрів приватних контейнерів у збірках GitLab CI
У GitLab 8.14 і GitLab Runner 1.8 ми поліпшили підтримку приватних образів Докера (private docker images).
Тепер ви можете використовувати приватні/захищені образи, які автоматично зберігаються у GitLab Container Registry без змін. GitLab буде посилати облікові дані реєстру з даними білду, а Runner буде використовувати їх для авторизації пулл-реквестов докера.
Також ви зможете використовувати захищену змінну
DOCKER_AUTH_CONFIG
щоб додати облікові дані для інших приватних реєстрів. Завдяки цьому ви можете використовувати будь-образ з будь-якого реєстру — публічного або приватного — до якого є доступ з хоста збірки, щоб цей образ став базою вашої збірки або сервісу, який вона використовує.
Runner 1.8 також виправляє механізм генерації аліасів з імені сервісу, коли реєстр доступний на нестандартному порту.
Ви можете почитати детальніше про підтримку реєстрів приватних контейнерів у документації конфігурації GitLab Runner.


Докладні release notes і інструкції по оновленню/установці можна прочитати в оригінальному англомовному пості: https://about.gitlab.com/2016/11/22/gitlab-8-14-released/
Переклад з англійської виконаний перекладацької артіллю «Надмозг і партнери», http://nadmosq.ru, над перекладом працювали nick_volynkin, rishavant і sgnl_05.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.