Вийшов GitLab 8.10

Всім привіт. В цей раз затримка з перекладом релізної поста вийшла всього 10 днів, і це радує.
Перекладом на цей раз займався chebureque, за що йому велика подяка!
Коротко: Збільшилася продуктивність, з'явилася захист від гілок змін з використанням масок, поліпшили відображення диффов, додали ручні дії CI, масову підписка на тікети, поліпшили підтримку Slack і додали більше емодзі.
Сам текст перекладу:


Основне завдання GitLab — дозволити вам як можна швидше пройти шлях від ідеї до готового до використання продукту. Кожен наш реліз направлений на те, щоб зробити цей шлях ще простіше, і версія 8.10 особливо досягла успіху в цьому!
GitLab 8.10 спрощує процеси рев'ю і мержа коду: тепер у вашому розпорядженні ще більш зручні диффы і додаткові фічі для захисту гілок від випадкових змін. А коли прийде час розгортання готового коду, ви зможете скористатися функцією ручних перевірок перед тим, як розгорнути ваш код одним кліком.
Наш липневий (MVP — Winnie! Він дуже допоміг нам, виправляючи помилки і наводячи порядок в нашому issue tracker-е.

Захист гілок від змін з використанням масок
Щоб убезпечити гілки від випадкового видалення або зміни, їх можна захищати. Цей механізм, серед іншого, дозволяє дозволяти або забороняти доступ до гілок на запис в залежності від прав користувачів — наприклад, можна не давати рядовим розробникам пушити або мержить у production — і release-гілки.
У Gitlab 8.10 тепер можна виставляти таку автоматичну захист з використанням масок, які будуть застосовуватися до імен гілок. Це значно спрощує роботу в репозиторіях з великою кількістю гілок.

Наприклад, якщо ви поставите на захист маску
release-*
, всі гілки, ім'я яких починається з
release-
, автоматично стануть захищеними. При розробці GitLab ми використовуємо цю фічу для захисту наших стабільних гілок, застосовуючи маску
*-stable
.

Мерж в захищені гілки
Як було сказано вище, опція захисту гілок дозволяє розмежовувати, хто може пушити у важливі гілки, а хто ні. За замовчуванням пуш і мерж в захищені гілки доступний тільки користувачам з дозволами
Master
і вище.
У попередніх версіях GitLab користувачам групи 'Developer' автоматично було дозволено пушити в захищені гілки. Починаючи з версії 8.10 ви можете незалежно давати членам групи
Developer
права окремо на пуш і окремо на мерж.

У цьому прикладі члени групи
Developer
може мержить мерж-реквесты, але не можуть безпосередньо пушити в зазначені гілки. Тобто ці гілки захищені від прямих пушей, але для прийняття мерж-реквеста в них не потрібно чекати користувача з високим рівнем дозволів. Зверніть увагу, що ця функціональність доступна тільки з веб-інтерфейсу і недоступна з командного рядка.
Сюди можна додати ще і функціональність підтверджень (approvals) з Enterprise Edition, яка дозволяє в обов'язковому порядку вимагати рев'ю від кількох людей перед прийняттям змін. У цьому випадку мерж-реквест повинен бути переглянутий кількома розробниками, але прийняти його тим не менш зможе будь-який користувач із групи
Developer

Детальніше про захищених гілках
Поліпшені дифы
незалежно від того, чи ви пишете код, робите код-рев'ю, або взагалі працюєте не з кодом, а з якимось іншим текстовим контентом, швидше за все вам доводиться багато працювати з диффами. Дуже бажано, щоб диффы працювали швидко і були зручними. У GitLab 8.10 диффы стали рендеритись значно швидше і навчилися декількох цікавих штук.
Більш зручні Side-by-Side Diffs
Ми поліпшили роботу side-by-side diffs, і тепер вони показують зміни в ще більш наочному вигляді.

Inlinе-диффы
Есл зміни зачіпають тільки частина рядка, ми покажемо вам саме її змінену порцію (а не рядок):

Схлапываемые диффы
Тепер ви можете схлапывать диффы, клікаючи на ім'я файлу. Це допоможе вам зручно переглядати зміни файл за файлом.

Великі диффы (> 10kb) завжди будуть показуватися схлопнутыми (але ви в будь-який момент можете розгорнути їх). Це повинно здорово допомогти, якщо вам постійно доводиться переглядати багато великих змін у великій кількості файлів
Ручні дії для запуску конвеєрних завдань (pipeline jobs)
Звичайно ж, ви вже налаштували конвеєр (pipeline) для Continuous Integration / Continuous Delivery? Використовувати такий автоматичний конвеєр для розгортання на production може бути не найкращою ідеєю. Автоматичне розгортання на staging — цілком нормальна практика, але перед перенесенням коду production краще все-таки провести хоча б кілька ручних тестів, щоб остаточно переконатися, що все працює нормально.
Тепер ви можете задавати активуються вручну умови для розгортання production. Опція
when: manual
додасть у веб-інтерфейс нове дія, яку потрібно буде активувати вручну — і конвеєр продовжить виконання тільки після цього ручної дії. Наприклад, ваш реліз-менеджер натисне цю кнопку після того, як вручну упевниться, що на staging все працює нормально. Будь-яка завдання (job) у вашому конвеєрі може бути позначена опцією
when: manual
.

Ці дії відображаються в середовищах (environments), щоб вам було простіше перекладати складання з staging у production.

Про системі CI/CD у GitLab
Оточення (environments) CI
Багаторядковий синтаксис для цитат у markdown
Якщо ви хочете позначити кілька рядків у вашому markdown-файлі як цитату, вам необов'язково приписувати до кожної рядку
>
. Тепер для цього є складний синтаксис:
>>>
Весь цей блок буде позначений як цитата.

Незалежно від кількості рядків у ньому.

Ура, товариші!
>>>

Детальніше про GitLab Flavored Markdown
Кілька точок монтування для репозиторіїв
Тепер ви можете розподілити дані ваших репозиторіїв за кількома точками монтування (mount points). Просто вкажіть всі необхідні mount points у файлі
gitlab.rb
:
git_data_dirs({
"default" => "/var/opt/gitlab/git-data",
"alternative" => "/mnt/nas/git-data"
})

Після цього в панелі адміністратора GitLab ви зможете вказувати, під якою точкою монтування потрібно зберігати кожен новий репозиторій.
Детальніше про множинні точки монтування
Масова підписка на тікети
Тепер ви можете підписуватися (і відписуватись) на велику кількість тікетів одночасно. Це корисно у випадках, якщо ви хочете з ходу пірнути в новий проект і бути в курсі всього і відразу, або навпаки, хочете побути в тиші від постійних email-повідомлень.

Індивідуальні рівні сповіщень для груп
У попередньої версії (8.9) ми додали індивідуальні оповіщення, щоб ви отримували повідомлення тільки про цікавлять вас проектних події.
У GitLab 8.10 ви можете керувати цими налаштуваннями для груп проектів, виставляючи однакові налаштування оповіщення відразу для декількох проектів (не забувайте, що індивідуальні налаштування проекту мають пріоритет над груповими).
Ticket-based Kerberos authentication (доступно тільки для Enterprise Edition)
До версії 8.10 користувачам GitLab, бажаючим використовувати аутентифікацію через Kerberos, доводилося вводити логін і пароль свого Kerberos-аккаунта на сторінці входу в GitLab. З версії 8.10 GitLab Enterprise Edition дозволяє користувачам Kerberos входити в GitLab без введення логіна і пароля — тепер достатньо просто натиснути на кнопку "Kerberos Spnego" на сторінці входу.
Це стало можливим завдяки новому OmniAuth-провайдера для SPNEGO-аутентифікації через Kerberos. Цей провайдер використовує напрацювання інституту ядерних досліджень CERN, за допомогою яких в GitLab стало можливо робити git clone з використанням ticket-based аутентифікації через Kerberos.
Якщо браузер користувача «розуміє» протокол Kerberos, а сам користувач має на своїй машині валідний Kerberos ticket, то браузер автоматично залягання в GitLab, нічого не питаючи користувача.
Докладна інформація про налаштування ticket-based аутентифікації через Kerberos для GitLab Enterprise Edition доступна в відповідному розділі документації.
В наступному релізі ми приберемо password-based аутентифікацію через Kerberos, так що якщо ви користуєтеся їй, ми рекомендуємо вам якомога швидше перейти на ticket-based варіант.
Підсвічування синтаксису
Підсвічування синтаксису в GitLab 8.10 стала ще краще.
Ми оновили rouge з версії 1.11.1 до 2.0.5, і в процесі цього оновлення додали нові лексеры і пофиксили кілька багів. Тепер у нас з'явилася підсвічування для Docker, F#, IDL, а вже була підсвічування для praat,
JavaScript, Java, C#, Shell, Liquid, Tulip, Markdown, Ruby, Python and YAML стала ще красивіше!
до Речі, тепер ви можете перевизначити «вгадування» мови для підсвічування і виставляти його явно за допомогою запису у файлі
.gitattributes
.
Усі подробиці — у відповідній документації.
Заборона на запит доступу
Тепер ви можете заборонити користувачам, що не входять в проект або групу, подавати заявки на вступ туди. За замовчуванням такі заявки можна.
Покращена інтеграція з Slack
GitLab тепер може сповіщати вас про різних проектних події через Slack — будь то коментар до тікети, створення нового мерж-реквеста або сломавшаяся складання.
Slack service тепер дозволяє вам налаштувати, в якій Slack-канал буде приходити повідомлення про кожну подію.

Детальніше про Slack Service можна почитати ось тут
Нові емодзі!
Ми оновилися до версії gemojione за 2016 рік, і тепер емодзі стало ще більше.

Чорні списки для доменних імен
Тепер можна вносити доменні імена в чорний список, і поштові адреси з цих доменів не зможуть реєструватися у вашому инстансе GitLab. Налаштування, пов'язані з чорним списком, знаходяться в панелі адміністратора.
Почитати про це можна тут
Увімкнення та вимкнення протоколів доступу для Git
Тепер ви можете незалежно управляти протоколами доступу до Git: ви можете дозволити доступ до сховища тільки через HTTP, тільки через SSH або одночасно через HTTP+SSH
Подробнее
Відображення відео в тексті
Якщо в тексті тікета, коментарю або мерж-реквеста міститься посилання на відео, то GitLab відобразить цей відеоролик прямо в тексті.
Детальніше про GitLab flavored markdown
Попередження (warnings) при складанні
Як ви знаєте, CI-конвеєр можна налаштувати таким чином, щоб помилки під час виконання якихось завдань (jobs) в ньому не вважалися фатальними. При виникненні таких помилок CI-конвеєр виводить попередження (warnings). У GitLab 8.10 ці попередження будуть видні вам в тому мерж-реквесте, який їх породив

Статистика використання (тільки для GitLab Enterprise edition)
Щоб краще зрозуміти, як саме клієнти використовують GitLab, 8.10 EE регулярно відправляє анонімну статистичну інформацію на сервер GitLab, Inc. Якщо ідея вам не по душі, вимкніть цю опцію на сторінці "Application settings" (на цій же сторінці ви видно, які дані будуть відправлені на наш сервер.

Поліпшення продуктивності
Від релізу до релізу GitLab стає краще і краще по всіх параметрах — і в тому числі і за швидкодією. У цьому місяці ми прискорили відображення тікетів в 2-2.5 рази і диффов на третину:


Для цікавляться — ось список значних змін у версії 8.10 і посилання на відповідні мерж-реквесты.
Backend
Frontend
Monitoring
Runner v1.4
З цього моменту runner-релізи будуть синхронізовані з щомісячними основними релізами GitLab. Зміни в цьому runner-релізі::
GitLab Mattermost 3.2
Разом з GitLab 8.10 поставляється і Gitlab Mattermost 3.2, відкритий аналог Slack.
У Mattermost 3.2 були додані німецька локалізація, нові emoji, покращене відображення гілок (threads), повноекранний пошуковий інтерфейс, інтеграцію з MS Exchange і XMPP, і багато іншого.
Крім того, у цієї версію Mattermost увійшли кілька security updates, тому ми настійно рекомендуємо оновитися на неї.
Інші зміни
Цей реліз включає в себе і багато інші поліпшення, включаючи різні security fixes. Повний список змін доступний Changelog.
Upgrade-барометр
Оновлення до GitLab 8.10 зажадає 15-30 хвилин даунтайма. В процесі оновлення будуть перейменовані кілька колонок в базі даних, і для коректного оновлення даних буде вироблено кілька міграцій. Щоб не пошкодити ваші дані в процесі міграції, інстанси GitLab буде зупинений на час оновлення.
Оновлення конфігурації Nginx
Умолчательня конфігурація Nginx для GitLab тепер перезаписує HTTP-заголовки 'Host' і 'X-Forwarded-Host'. Це додає додатковий рівень захисту від header injection attacks. Якщо ви ставили GitLab з исходников, то вам потрібно буде оновити конфігурацію Nginx. Якщо ви ставили GitLab з допомогою Omnibus, оновлення конфігурації відбудеться автоматично (якщо тільки ви не переопределили параметри 'Host' і 'X-Forwarded-Host' у файлі
gitlab.rb
).
Git Hooks перейменовані у Push Rules, а також старіння Git Hooks API
Те, що раніше називалося Git Hooks, тепер називається Push Rules. Крім того, Git Hooks API тепер позначений як застаріле (deprecated). Цей API буде повністю викинуть в GitLab 9.0, тому ми рекомендуємо вам якомога швидше перейти на Push Rules.
Детальніше про Push Rules
Типове поведінка при оновленні
Увага Інформація у цьому розділі релевантна у разі, якщо ви оновлюйтеся на GitLab 8.2 c попередньої версії. Якщо це не так, то прочитайте розділи «Upgrade-барометр» для всіх проміжних версій між поточної та 8.2.
Якщо ви оновлюйтеся з версії GitLab, меншою, ніж 8.0 і при цьому у вас включений CI, вам потрібно спочатку оновитися до 8.0.
За замовчуванням в процесі оновлення всі пакети Omnibus будуть зупинені, потім будуть прогнаны всі їх міграції, і тільки потім вони будуть запущені знову. Це поведінка не залежить від «розміру» оновлення. Змінити це повоедение можна, створивши файл
/etc/gitlab/skip-auto-migrations
.


Установка
Якщо ви встановлюєте GitLab з «нуля», прочитайте відповідний розділ: https://about.gitlab.com/installation/
Оновлення
Інструкції з оновлення: https://about.gitlab.com/update/
Enterprise Edition
GitLab Enterprise Edition включає в себе додаткові функції типу підтримки LDAP-груп, підтвердження (approvals) мерж-реквестов, блокування файлів і багато чого іншого. Детальну інформацію можна подивитися у описі GitLab EE.
GitLab EE доступний тільки за передплатою, подробиці і ціни можна подивитися ось тут.
Не вистачає часу на установку і настройку нового інструменту? У вартість передплати входять послуги з встановлення та оновлення GitLab на ваших серверах.
P. S. Якщо пропустили, то ось вам посилання на переклад поста про реліз 8.9
Джерело: Хабрахабр

0 коментарів

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