Gitlab com на русском

Ключевые фичи в GitLab 16

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

GitLab 16.1 представляет совершенно новую навигацию! Сейчас её могут включить все пользователи. Чтобы начать пользоваться новой навигацией, кликните на свой аватар в верхнем правом углу и нажмите на переключатель Новая навигация (New navigation).

Эта навигация была разработана, чтобы решить три основных проблемы, на которые больше всего жаловались пользователи: навигация по GitLab может быть перегруженной, бывает сложно продолжить навигацию после перерыва в работе, и нет возможности настроить навигацию под себя.

В новой навигации появилась простая и удобная левая боковая панель, на которой вы можете:

Мы гордимся нашей улучшенной навигацией и с нетерпением ждём ваших отзывов. Посмотрите полный список изменений и прочитайте наши посты в блоге о проектировании и дизайне новой навигации.

Мы будем рады, если вы попробуете новую навигацию и поделитесь своим опытом в этом тикете. Мы уже разбираем поступающую обратную связь и со временем планируем убрать переключатель фичи и сделать эту навигацию основной.

Документация о левой боковой панели GitLab и оригинальный эпик.

Визуализация ресурсов Kubernetes в GitLab

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Deploy

Как проверить статус приложений, запущенных на ваших кластерах Kubernetes? Страницы статуса конвейера (в русской локализации GitLab «сборочная линия») и окружения дают информацию о последних запущенных развёртываниях. Однако, в предыдущих версиях GitLab не хватало информации об их состоянии. В GitLab 16.1 у вас появляется возможность просматривать информацию об основных ресурсах ваших развёртываний.

Эта фича работает со всеми подключёнными кластерами Kubernetes. Не важно, развёртываете ли вы свои приложения через интеграцию с CI/CD или через GitOps. Чтобы сделать эту фичу ещё полезнее для пользователей Flux, в тикете 391581 предлагается поддержка статуса синхронизации окружения.

Документация о панели информации Kubernetes и оригинальный тикет.

Сервисные аккаунты

(Доступно в планах SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

Существует множество сценариев, в которых может быть необходима аутентификация не-человека в аккаунте пользователя. Ранее в зависимости от желаемого уровня доступа можно было использовать личные токены доступа, проекта или группы, чтобы удовлетворить эту потребность. Эти токены работали не идеально, так как они всё равно были привязаны к человеку (личные токены) или к роли, у которой может быть излишне высокий уровень доступа (токены групп и проектов).

Сервисные аккаунты не привязаны к конкретному человеку и более универсальны в настройке уровня доступа. Создание сервисных аккаунтов и управление ими пока что возможно только через API GitLab. Поддержка графического интерфейса разрабатывается в эпике 9965.

Документация по сервисным аккаунтам и оригинальный эпик.

GitLab Dedicated вышел в общий доступ

(Доступно в плане SaaS: ULTIMATE) Направление: Платформы

GitLab Dedicated — это управляемое однопользовательское SaaS-развёртывание нашей платформы DevSecOps, разработанной для решения проблем клиентов со строгими требованиями к безопасности.

Такие пользователи ранее не могли использовать GitLab SaaS из-за необходимости соблюдать строгие ограничения, например изоляцию данных. С GitLab Dedicated организации смогут получить доступ ко всем возможностям платформы DevSecOps, включая более быстрые релизы, улучшенную безопасность и повышение продуктивности разработчиков, в то же время соблюдая требования к безопасности, такие как локализация и изоляция данных, коммуникация в локальных сетях.

Документация по GitLab Dedicated и страница, посвящённая GitLab Dedicated.

Управление артефактами заданий со страницы артефактов

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

Пользователи с ролью не ниже мейнтейнера (в русской локализации GitLab «сопровождающий») также смогут использовать этот интерфейс, чтобы удалять артефакты. Вы можете удалять отдельные артефакты или до 100 артефактов за раз выбирая их вручную, либо выбрав опцию Выбрать все (Select all) наверху страницы.

Документация по странице артефактов, тикет по расширению таблицы с данными об артефактах, тикет по удалению артефактов, тикет по групповому удалению артефактов, тикет по групповому выбору для удаления артефактов.

Улучшенный список переменных CI/CD

Переменные CI/CD являются ключевой частью всех конвейеров и могут быть определены во многих местах, включая настройки проекта и группы. В качестве подготовки к внесению больших изменений, которые помогут пользователям интуитивно переходить между переменными в разных иерархиях, мы начинаем с того, что улучшаем удобство и функциональность списка переменных.

Документация по определению переменных CI/CD через графический интерфейс GitLab и оригинальный тикет.

Другие улучшения в GitLab 16

Верификация домена выполняет в GitLab множество целей. Ранее, чтобы верифицировать домен, вам приходилось заполнять форму GitLab Pages, даже если вы верифицировали домен для других целей.

Теперь верификация домена находится на уровне группы. Также она стала более понятной и удобной, что значительно упрощает верификацию ваших доменов.

Документация по настройке верифицированного домена и оригинальный тикет.

Восстановление пароля через любой подтверждённый адрес почты

Теперь, если вы забыли свой пароль от GitLab, вы сможете восстановить его по почте с любого подтверждённого адреса. Ранее для восстановления пароля мог использоваться только основной почтовый адрес. Это усложняло процесс восстановления для пользователей, у которых не было доступа к основной почте.

Документация по изменению пароля в GitLab и оригинальный тикет.

Ограничение удаления аккаунтов

(Доступно в планах self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

Администраторы смогут предотвращать удаление пользователями своих аккаунтов через новую настройку ограничений. Если эта настройка включена, пользователи больше не смогут удалить свой аккаунт, что поможет сохранить ценную информацию, связанную с аккаунтом.

Документация по ограничению удаления аккаунтов и оригинальный тикет.

Передача информации SCIM через API

API пользователей теперь возвращает для пользователя информацию SCIM. Ранее эта информация была доступна через графический интерфейс, но не через API.

Документация по API пользователей и оригинальный тикет.

Просмотр отчёта о уязвимостях как настраиваемое разрешение

(Доступно в планах SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage

Возможность просматривать отчёт об уязвимостях теперь выделена в отдельное разрешение, что позволяет администраторам и владельцам групп GitLab создавать специальную роль с этим разрешением. Ранее просмотр отчёта об уязвимостях был разрешен только пользователям с уровнем доступа разработчиков и выше. Теперь любой пользователь сможет делать это, если им назначена специальная роль, у которой есть это разрешение.

Документация по настраиваемым ролям и оригинальный эпик.

Настройка директории статических файлов в GitLab Pages

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Plan

Теперь вы можете задавать для директории статических файлов в GitLab Pages произвольное имя (по умолчанию public). Это упростит работу в Pages с популярными статическими фреймворками, такими как Next.js, Astro или Eleventy, освобождая от необходимости изменять папку при их настройке.

Документация по настройке папки GitLab Pages по умолчанию и оригинальный эпик.

Генерация списков изменений из GitLab CLI

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

Списки изменений генерируются автоматически на основе коммитов проекта. Их может быть сложно автоматизировать и просматривать, а взаимодействовать с ними можно было только через GitLab API.

Начиная с релиза GitLab CLI 1.30.0 вы сможете генерировать списки изменений прямо из CLI. Команда glab changelog generate упрощает просмотр, автоматизацию и публикацию списков изменений.

Спасибо Michael Mead за эту фичу!

Документация по спискам изменений и оригинальный тикет.

Конечная точка для настройки области доступа токена заданий CI/CD

В GitLab 16.0 изменилась область доступа токена заданий CI/CD по умолчанию (CI_JOB_TOKEN) для всех новых проектов. Это повысило безопасность новых проектов, но также добавило дополнительный шаг для пользователей, которые создавали проекты автоматически. Эта автоматизация иногда требовала настройки области доступа токена, что могло быть сделано через GraphQL или вручную через графический интерфейс, но не через REST API.

Чтобы сделать эту настройку доступной также через REST API, Gerardo Navarro добавил в версии 16.1 новую конечную точку для контроля области видимости токена заданий. Эта настройка доступна всем пользователям с уровнем доступа мейнтейнера или выше. Спасибо Gerardo за эту потрясающую фичу!

Документация по токенам доступа CI/CD и оригинальный тикет.

Объединение обработчиков заданий с одинаковыми настройками

Новый способ создания обработчика заданий позволяет вам повторно использовать его настройки для сценариев, когда вам необходимо зарегистрировать несколько обработчиков заданий с одинаковыми возможностями. Обработчики, зарегистрированные с одинаковым токеном аутентификации, имеют одинаковые настройки и сгруппированы в новом представлении для детального просмотра.

Документация по повторному использованию настроек обработчика заданий и оригинальный тикет.

Шаблон ссылки на тикет службы поддержки для электронных писем

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Monitor

Документация по службе поддержки и оригинальный тикет.

Автоматический ответ на слитые секретные ключи Google Cloud

(Доступно в плане SaaS ULTIMATE) Стадия цикла DevOps: Secure

Мы интегрировали поиск секретных ключей с Google Cloud для лучшей защиты пользователей, которые используют GitLab для разработки приложений в Google Cloud. Теперь, если организация отправляет данные Google Cloud в публичном проекте на GitLab.com, GitLab может автоматически защитить аккаунты организации, работая совместно с Google Cloud.

Поиск секретных ключей ищет три типа уязвимостей, определяемых Google Cloud:

Публично слитые секретные ключи отправляются в Google Cloud после того, как они обнаружены. Google Cloud проверяет факт утечки, а затем работает над защитой данных аккаунта клиента от неправомерного использования.

Эта интеграция автоматически включена для проектов, в которых активирован поиск секретных ключей на GitLab.com. Сканирование на поиск секретных ключей доступно для всех планов GitLab, но автоматический ответ на слитые данные пока доступен только для планов Ultimate.

Больше деталей об этой фиче можно найти в нашем блоге.

Документация по автоматическому ответу на слитые секретные ключи и оригинальный тикет.

Обновления анализатора качества кода

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure

Анализатор качества кода (GitLab Code Quality) поддерживает интеграцию инструментов, которые вы уже используете, а также предлагает шаблон CI/CD для запуска системы сканирования CodeClimate. Мы опубликовали следующие обновления для анализатора на основе CodeClimate с релизом 16.1:

Посмотрите подробности в списке изменений.

Если вы используете шаблон Code Quality под управлением GitLab (Code-Quality.gitlab-ci.yml), вы получите эти обновления автоматически.

Описание изменений Code Quality в предыдущих релизах вы можете найти в последнем обновлении.

Документация по Code Quality и оригинальный тикет.

Настройки общего набора правил в SAST, сканировании IaC и обнаружении секретных ключей

(Доступно в планах SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure

Теперь вы можете установить переменную CI/CD, чтобы в нескольких проектах использовать одни и те же настройки наборов правил для SAST, сканирования IaC или обнаружения секретных ключей.

Совместное использование набора правил может помочь вам:

Дальнейшие улучшения в этой области обсуждаются в этом тикете.

Документация по настройке наборов правил SAST и оригинальный тикет.

Пропуск проектов при резервном копировании

(Доступно в планах self-managed: FREE, PREMIUM, ULTIMATE) Системы

Встроенный инструмент бэкапа и восстановления теперь позволяет пропускать определённые репозитории. Задача Rake принимает список путей групп или проектов, разделённых запятыми, которые будут пропущены во время резервного копирования или восстановления с помощью новой переменной окружения SKIP_REPOSITORIES_PATHS. Так можно пропускать, например, устаревшие или архивные проекты, которые не меняются со временем, экономя как время за счёт ускорения выполнения резервного копирования, так и место за счёт отсутствия этих данных в файле резервной копии. Спасибо Yuri Konotopov за этот вклад!

Документация по настройкам резервного копирования и оригинальный тикет.

Geo верифицирует репозитории дизайна

(Доступно в планах self-managed: PREMIUM, ULTIMATE) Системы

При добавлении дизайна в тикет создаётся или обновляется Git-репозиторий дизайна, а также создаётся объект LFS и директория для макетов. Geo уже проверяет объекты LFS и выгрузки, а теперь он проверяет и репозитории дизайна. Теперь, когда все базовые данные управления дизайном (Design Management) проверены, ваши проектные данные гарантированно не будут повреждены при передаче или хранении. Если Geo используется как часть стратегии аварийного восстановления, это защитит вас от потери данных.

Документация по администрированию Geo.

Более подробная информация о завершённом импорте проекта из GitHub

По завершении импорта проекта GitHub GitLab ранее показывал простую сводку импорта. Однако он не показывал, ни те сущности GitHub, которые не удалось импортировать, ни ошибки, вызвавшие сбои импорта. Поэтому было трудно решить, достаточно ли хорошо прошёл импорт.

В этом релизе мы расширили сводку импорта, включив в неё список сущностей GitHub, которые не были импортированы. Когда это возможно, туда добавляется прямая ссылка на эти сущности на GitHub. Также GitLab показывает ошибку для каждого сбоя. Это поможет вам понять, насколько хорошо сработал импорт, и устранить неполадки.

Документация по проверке статуса импорта с GitHub и оригинальный тикет.

Значение личного токена доступа last_used теперь обновляется чаще

Значение last_used для личных токенов доступа (PAT) ранее обновлялось каждые 24 часа. Теперь оно обновляется каждые 10 минут. Это повышает видимость использования PAT и снижает риск в случае компрометации PAT, поскольку вредоносную активность можно быстрее заметить.

Спасибо Jacob Torrey за этот вклад!

Документация по личным токенам доступа и оригинальный тикет.

Повторное внедрение поддержки OmniAuth Shibboleth

(Доступно в планах self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

Мы вновь внедрили в GitLab поддержку Shibboleth OmniAuth. Ранее она была удалена в GitLab 15.9 из-за отсутствия поддержки со стороны разработчиков. Благодаря щедрому вкладу сообщества от lukaskoenen, взявшего на себя эту поддержку, omniauth-shibboleth-redux теперь поддерживается в инстансах GitLab с самостоятельным управлением.
Документация по интеграции Shibboleth и оригинальный тикет.

Выбор доступа администратора для личных токенов доступа в режиме администратора

Спасибо Jonas Wälter, Diego Louzán и Andreas Deicha за эту фичу!

Добавили описание к загрузке дизайна

Ранее при загрузке дизайна не было возможности добавить метаданные, объясняющие назначение этого дизайна. Мы добавили текстовое поле в качестве описания, чтобы пользователи могли понять общую картину.

Документация по добавлению дизайна в тикет и оригинальный эпик.

Комментарий ко всему файлу в мерж-реквестах

Документация по добавлению комментариев к файлу в мерж-реквесте и оригинальный тикет.

Улучшение пользовательского интерфейса конвейеров и заданий CI/CD

Одной из наиболее используемых фич GitLab является CI/CD. В версии 16.1 мы сосредоточились на повышении удобства использования и улучшении представления CI/CD конвейеров и списков заданий, а также страницы с подробной информацией о конвейере. Теперь найти нужную информацию стало ещё проще. Если у вас есть замечания по поводу этих изменений, напишите в нашем тикете обратной связи.

Документация по настройкам конвейера и оригинальный тикет.

Использование needs в rules.

Ключевое слово needs определяет зависимость между заданиями, которую вы можете использовать для установки заданий на выполнение вне очереди. В этом релизе мы добавили возможность определять эту зависимость для некоторых условий в rules. Когда условие соответствует правилу, конфигурация needs из правила используется вместо конфигурации needs из задания. Это может ускорить конвейер, основанный на определённых вами условиях, когда задание может быть запущено раньше обычного. Вы также можете использовать эту фичу, чтобы заставить задание дождаться завершения более раннего задания перед запуском, — теперь у вас есть более гибкие опции needs!

Документация по использованию needs в rules и оригинальный тикет.

Увеличение хранилища для обработчиков заданий GitLab SaaS на Linux

(Доступно в планах SaaS: PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

После недавнего увеличения количества vCPU и RAM в наших обработчиках заданий GitLab.com SaaS для Linux, мы также увеличили размер хранилища для типов машин medium и large.

Теперь вы можете легко создавать, тестировать и разворачивать большие приложения, для которых иногда требуется безопасное окружение обработчиков заданий GitLab для Linux, полностью интегрированное с GitLab CI/CD.

Документация по обработчикам заданий GitLab для Linux и оригинальный тикет.

Установка пакетов npm из вашей группы или подгруппы

(Доступно в планах SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package

Вы уже можете использовать реестр пакетов вашего проекта для публикации и установки пакетов npm. Вы просто аутентифицируетесь с помощью токена доступа (personal, job, deploy или project) и начинаете публиковать пакеты в своём проекте GitLab.

Это отлично работает, если проектов у вас немного. К сожалению, если их много, может оказаться, что приходится добавлять десятки или даже сотни различных источников. Обычно команды в крупных организациях публикуют пакеты в реестре пакетов своего проекта вместе с исходным кодом и конвейерами. Одновременно им необходимо иметь возможность легко устанавливать зависимости из других проектов в рамках групп и подгрупп своей организации.

Чтобы упростить обмен пакетами между проектами, теперь вы можете устанавливать пакеты из своей группы — больше не надо будет помнить, какой пакет находится в каком проекте. Используя токен аутентификации по вашему выбору, вы можете установить любой из пакетов npm группы после добавления вашей группы в качестве источника пакетов npm.

Документация по установке пакетов npm на уровне группы и оригинальный тикет.

Внешний пользователь отображается как автор комментария в тикетах службы поддержки

Документация по работе службы поддержки и оригинальный тикет.

Более ясное руководство и лучшее покрытие для правил SAST

Мы обновили правила SAST на GitLab, чтобы:

Эти улучшения — часть сотрудничества между командами статического анализа и исследования уязвимостей GitLab по улучшению наборов правил статического анализа. Мы будем рады любым отзывам о правилах по умолчанию для SAST, обнаружения секретных ключей и сканирования IaC в эпике 8170.

Более подробно изменения в правилах GitLab SAST описаны в списке изменений. Начиная с версии GitLab 16.1, проект sast-rules является единым источником всех управляемых GitLab правил, используемых в анализаторе SAST на основе Semgrep.

Документация по анализаторам SAST и оригинальный тикет.

Обновления анализатора SAST

Статическое тестирование безопасности приложений (SAST) в GitLab включает в себя множество анализаторов безопасности, активно управляемых, поддерживаемых и обновляемых командой статического анализа GitLab. Мы опубликовали следующие обновления в релизе 16.1:

Если вы используете шаблон SAST под управлением GitLab, (SAST.gitlab-ci.yml) и у вас GitLab 16.0 или выше, вы получите эти обновления автоматически. Чтобы оставаться на определённой версии любого анализатора и предотвратить автоматические обновления, вы можете закрепить его версию.

Предыдущие изменения смотрите в обновлениях за прошлый месяц.

Блокирование мерж-реквестов при проверках подтверждений правил безопасности, когда есть недействительные правила

(Доступно в планах SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Govern

Правила безопасности и соответствия требованиям позволяют организациям объединить программы безопасности и управления из разнородных проектов. Для наших клиентов очень важно, чтобы изменения, влияющие на правила, не нарушали безопасность. С этим обновлением недействительные правила будут блокировать мерж-реквесты, пока не будут устранены все недействительные правила в любых правилах результатов сканирования.

Документация по недействительным правилам подтверждения мерж-реквестов и оригинальный тикет.

Geo добавляет фильтрацию по статусу репликации для всех компонентов

В Geo появилась фильтрация по статусу репликации во всех компонентах, управляемых его автоматизированной платформой. Теперь элементы в представлениях деталей репликации можно фильтровать по статусам «В процессе» (“In progress”), «Сбой» (“Failed”) и «Синхронизировано» (“Synced”), что упрощает и ускоряет поиск данных, которые не удаётся синхронизировать.

Документация по администрированию Geo и оригинальный тикет.

Полный текст релиза и инструкции по обновлению и установке вы можете найти в оригинальном англоязычном посте GitLab 16.1 released with all new navigation.

Над переводом с английского работали maryartkey, ainoneko, cattidourden и rishavant.

▍ Образ GitLab на VPS

Образ GitLab выбирается на этапе заказа сервера или сразу из маркетплейса:

Образ включает последнюю версию GitLab Enterprise Edition (EE), сейчас это 13.4.2 на операционной системе CentOS 8.

В дополнение к установленному программному обеспечению на образе GitLab активирован Firewall и разрешён только SSH (порт 22, LIMITED), HTTP (порт 80).

На официальном сайте GitLab также есть документация по установке и поддержке своего инстанса GitLab на разных системах:

• Debian 10, 11,
• AlmaLinux 8,
• CentOS 7,
• Amazon Linux 2,

Поддерживаются также установки на Kubernetes при помощи конфигураций GitLab Helm и GitLab Operator. Можно установить инстанс GitLab не только на своём сервере, но и у любого крупного облачного провайдера, да вообще на любой системе из образа Docker.

Вся инфраструктура компании GitLab и её фирменный SaaS размещается на мощностях Google Cloud. Кстати, это интересный пример компании с капитализацией в миллиарды долларов, у которой даже нет центрального офиса. Все её сотрудники работают удалённо, а все серверы находятся в облаке. Вот что такое корпорация в эпоху киберпанка.

Поздравляю!

Вы осуществили имплементацию непрерывной поставки(CD) при помощи GitLab начиная с задач с канбан-доской и завершая метриками.

️ Базовая настройка управления проектом на GitLab. com

В этой части мы создадим сам проект в GitLab и задачи над которыми будем работать в дальнейшем, а также настроим Kanban-доску для визуализации состояния проекта.

Создание проекта в GitLab

Мы будем использовать GitLab.com в качестве инсталляции GitLab чтобы избежать хлопот по установке и настройке локальной версии.

! Если у вас ещё нет учётной записи на GitLab.com, зайдите на https://gitlab.com и заведите её.

GitLab позволяет нам создать проект просто выполнив push в удалённый репозиторий.

! Воспользуемся для этого следующей командой:

Эта команда создаст приватный проект с именем gitlab-cd-react внутри вашей учётной записи на GitLab.com.

Далее мы настроим канбан-доску, а заодно создадим несколько задач чтобы было вокруг чего строить дальнейшую работу и о чём собирать статистику.

️ Создание задач и настройка доски

Давайте начнём с создания задачи.

! Кликните Issues в левом меню, затем нажмите одну из кнопок New Issue в основной области. Откроется форма создания задачи. Укажите в качестве заголовка «Создать задания для туториала».
В описании укажите следующий текст

Да, именно эти вещи мы и будем делать в дальнейшем. Оставьте остальные значения по умолчанию. Нажмите кнопку Submit issue.

Обратите внимание, что список с пробелами в квадратных скобках вначале элементов был распознан как чеклист, а отдельные его элементы как задачи. GitLab, как и многие другие платформы, использует Markdown в качестве языка разметки.

! Назначьте задачу Создать задания для туториала на себя. Для этого нажмите ссылку Edit в панели с надписью 0 Assignees справа на странице редактирования задачи.

Поздравляю, теперь вы — исполнитель. На самом деле на этом этапе задача может быть назначена любому члену команды но т.к. по сути ничего не изменится, мы не будем плодить пользователей.

! Давайте теперь на самом деле создадим все задачи, перечисленные в описании нашей первой задачи. Укажите только заголовки, остальные поля оставьте по умолчанию. Вы можете «ставить галочки» в описании задачи Создать задания для туториала как по мере создания задач, так и все сразу когда закончите.

Существуют разные способы создавать задачи, при создании задач по списку найдите и используйте хотя бы 3 разных способа. В итоге у вас должно получиться 6 задач.

Наш процесс работы

Под процессом работы(workflow) обычно подразумевается порядок этапов, которые задача проходит для того чтобы считаться выполненной. В Continuuos Delivery, Kanban и DevOps задача движется через некую последовательности состояний либо вперёд, либо может быть возвращена на один из предыдущих этапов.

Это подразумевает линеаризованные value streams. Про value streams можно почитать тут. Превращение порой затейливой диаграммы переходов в последовательность состояний является иногда очень сложной управленческой задачей, решение которой выходит за границы этой статьи.

Мы будем использовать простую последовательность состояний

Вначале задача оказывается в состоянии Open. Затем она затягивается(pull) в работу разработчикам в стадию Dev. После того, как работа завершена, происходит передача задачи в стадию Dev: done.

Зачем нам нужна эта дополнительная стадия? Дело в том что в Lean, на котором основаны все методологии типа CD, Kanban и DevOps, следующий этап(work center) затягивает задачи когда он готов в отличие от методологий где задачи передаются в следующий этап предыдущим. Это позволяет отслеживать задачи которые находятся в стадии ожидания, а накопление задач в стадии ожидания позволяет нам понять, где в нашем «конвейере» «бутылочное горлышко».

Итак, затем задача затягивается в этап QA где работают специалисты по качеству и автотесты, а «выпускники» QA считаются настолько хорошими что развёртываются непосредственно на продуктив.

«Ну так же не бывает, это же чих-пых — и в продакшн, должны же быть другие среды типа Staging в процессе!» — скажете вы. Я совершенно согласен, но тут мы используем максимально простой в реализации и для понимания конвейер чтобы меньше отвлекаться от GitLab и не закопаться где-нибудь в дебрях Kubernetes.

️ Настройка меток

Для организации задач GitLab использует метки(labels). Они как теги и позволяют искать, фильтровать и отображать задачи в разных местах в зависимости от наличия той или иной метки. Давайте заведём сами метки

Названия меток тут полностью произвольные и никакого особого смысла с точки зрения GitLab в них нет.

! Когда закончите, назначьте задачу Создать метки статус Closed.

Теперь всё готово для настройки Kanban-доски.

В GitLab есть Kanban-доски. Они позволяют отображать разные задачи в соответствии с их метками. Несмотря на название они могут быть использованы не только для реализации Kanban, но и Scrum а также других методологий. У нас же уже создана задача для этого.

! Назначьте эту задачу на себя.

Если вы создали их в другом порядке, вы можете изменить порядок, перетаскивая списки «за заголовки».

Таким образом мы указываем что начали работать над этой задаче. Обратите внимание что у задачи появилась новая метка Dev.

! Так как всю работу мы уже сделали, переведите задачу в столбец Dev: done.

Мы приближаемся к стадии QA. Постарайтесь внутренне ощутить себя тестировщиком, подумайте какие разработчики неблагонадёжные люди, и, опционально, разберите при помощи отвёртки небольшой бытовой прибор.

! Затем переведите задачу в стадию QA. Тут можете несколько раз поперетаскивать задачу из столбца в столбец туда-сюда. Кстати, такие приключения порой и происходят с задачами на данном этапе. В процессе у задачи будет появляться метка нового столбца и исчезать метка предыдущего столбца. В конце концов оставьте задачу в столбце Closed и обратите внимание что в результате этого действия она была закрыта.

Метрики CI/CD в GitLab

В процессе командной работы полезно собирать статистику чтобы понимать повышается ли продуктивность или падает. Способы оценки производительности могут быть совсем разными в зависимости от характера работы и типа проекта или продукта.

Например, веб-студия может иметь «типовые» задачи типа отрисовки макета в рамках стандартного пакета услуг, предлагаемого клиенту. Agile стартап же может находиться в стадии когда концепция продукта меняется вместе с растущим пониманием потребностей клиента и рынка, и задачи могут быть трудно предсказуемы и часто уникальны. Вместе с тем, можно выделить чисто технические показатели производительности вроде одного из основных для DevOps времени вывода новой фичи на рынок (time to market, TTM) или просто длительности той или иной стадии. Отслеживать динамику таких показателей может быть очень полезно: за достаточно длительный период времени это позволяет понять как изменяется производительность.

Хорошей новостью является то что GitLab имеет функционал сбора этой статистики. Давайте с этим функционалом познакомимся.

! Кликните на Analytics. По умолчанию откроется раздел Value stream. В Lean вообще и в DevOps в частности считается что задачи несут в конечном итоге некоторую пользу для конечного заказчика. И движение таких полезных задач, от стадии формулирования через все этапы работы до того момента когда результаты становятся доступны заказчику называется value stream.

Основные средние величины по этапам:

Если вы сложите длительность Issue, Plan, Code, Review и Staging, вы и получите примерно то самое заветное время для вывода на рынок (TTM).

Наверху страницы в также увидите некие агрегатные показатели по проекту за выбранный период времени.

▍ Ценовая политика GitLab

«Корпоративная» лицензия Enterprise Edition отличается от общественной Community Edition главным образом двумя параметрами:

Посмотрим, чем отличается GitLab на своём хостинге (условно бесплатный) от платной подписки GitLab. Сравним конкретные цены с официального сайта. Первый план — абсолютно бесплатный фримиум GitLab, второй — образ Gitlab на VPS, третий — GitLab Premium ($19 в месяц).

Примечание. Для образа GitLab на своём VPS рекомендуется сервер со следующими минимальными характеристиками.

Хотя по умолчанию в маркетплейсе указан двухъядерный сервер с 4 ГБ RAM и SSD на 20 ГБ, но на этапе заказа эти характеристики можно изменить. Новые пользователи могут тестировать сервер в течение 3 дней бесплатно.

Нужно ещё добавить, что есть несколько проприетарных функций, которые доступны только на премиальном тарифе Ultimate и только на фирменном SaaS. Часть исходного кода GitLab остаётся в закрытой версии, то есть не выкладывается в опенсорс.

Вероятно, для некоторых компаний и разработчиков будет достаточно лимитов GitLab Free. Однако чтобы не ограничивать себя по лимитам и не рисковать блокировкой услуги со стороны провайдера, можно мигрировать на свой сервер Enterprise Edition. Если же нужна техподдержка и дополнительные функции — выбрать настоящую фирменную версию от GitLab, хотя это обойдётся несколько дороже.

GitWeb довольно-таки прост.
Если вам нужен более современный, полнофункциональный Git-сервер, есть несколько решений с открытым исходным кодом, которые можно использовать.
Так как GitLab это один из самых популярных, мы рассмотрим его установку и использование в качестве примера.
Это немного сложнее, чем GitWeb, и скорее всего потребует больше обслуживания, но и функциональность гораздо богаче.

GitLab — это веб-приложение на основе базы данных, так что его установка немного сложней, чем у некоторых других серверов Git.
К счастью, этот процесс хорошо документирован и поддерживается.
GitLab настоятельно рекомендует установить GitLab на ваш сервер через официальный пакет Omnibus GitLab.

Другие варианты установки:

Администрирование

Пользователи в GitLab — это учётные записи, соответствующие людям.
Пользовательские учётные записи не очень сложны; в основном это набор персональной информации, прикреплённый к имени.
У каждого пользователя есть пространство имён, логически группирующее проекты данного пользователя.
Если у пользователя jane есть проект project, адрес этого проекта будет http://server/jane/project.

Рисунок 51. Экран управления пользователями GitLab

«Разрушение» («Destroying») пользователя, с другой стороны, полностью удаляет его из базы данных и файловой системы.
Все проекты и данные в его пространстве имен удаляются, как и все принадлежащие ему группы.
Конечно, этим более постоянным и разрушительным действием пользуются реже.

Группы GitLab — это коллекция проектов с указанием того, как пользователи получают к ним доступ.
Каждая группа имеет пространство имён проектов (так же как и пользователи), так что если в группе training есть проект materials, его адрес будет http://server/training/materials.

Рисунок 52. Экран управления группами GitLab

Каждая группа связана с пользователями, каждый из которых имеет уровень доступа к проектам группы и к самой группе.
Он разнится от «Гостя» («Guest», только проблемы и чат) до «Владельца» («Owner», полный контроль над группой, её членами и проектами).
Типы разрешений слишком обширны, чтобы перечислять их здесь, но на экране управления GitLab есть полезная ссылка с описанием.

Проекты

Проект GitLab примерно соответствует одному git-репозиторию.
Каждый проект принадлежит одному пространству имён, групповому или пользовательскому.
Если проект принадлежит пользователю, владелец контролирует, кто имеет доступ к проекту; если проект принадлежит группе, действуют групповые уровни доступа для пользователей.

Каждый проект также имеет уровень видимости, который контролирует, кто имеет доступ на чтение страниц проекта или репозитория.
Если проект Приватный (Private), владелец должен явно дать доступ на чтение отдельным пользователям.
Внутренний (Internal) проект виден любому вошедшему пользователю GitLab, а Публичный (Public) проект видим всем.
Это относится как к доступу git fetch, так и к доступу к проекту через веб-интерфейс.

Хуки

GitLab включает поддержку хуков (перехватчиков, hooks) на уровне проектов и всей системы.
В обоих случаях, когда происходит некоторое событие, сервер GitLab выполняет запрос HTTP POST с осмысленным JSON-содержанием.
Это отличный способ соединить ваши git-репозитории и инсталляцию GitLab с автоматикой инфраструктуры разработки, такой как сервера непрерывной интеграции, комнаты чатов или инструменты деплоя.

Базовое использование

Первое, чего вы захотите от GitLab, это создать новый проект.
Это достигается нажатием иконки «+» на панели инструментов.
Будут запрошены имя проекта, пространство имён, которому он должен принадлежать, и уровень видимости.
Большинство из этих настроек можно потом изменить через интерфейс настроек.
Нажмите «Создать проект» («Create Project»), чтобы закончить.

Когда проект создан, вы, наверное, захотите соединить его с локальным git-репозиторием.
Каждый проект может быть доступен через HTTPS или SSH, каждый из которых может быть использован для указания удалённого репозитория.
Адреса (URL) видимы наверху домашней страницы проекта.
Для существующего локального репозитория, следующая команда создаст удалённый репозиторий с именем gitlab и размещением на сервере:

$ git remote add gitlab https://server/namespace/project.git

Если у вас нет локального репозитория, можно просто сделать его:

$ git clone https://server/namespace/project.git

Веб-интерфейс даёт доступ к нескольким полезным видам самого репозитория.
Домашняя страница каждого проекта показывает недавнюю активность, а ссылки наверху ведут на список файлов проекта и журнала коммитов.

Совместная работа

Самый простой метод совместной работы над проектом GitLab — это выдача другому пользователю прямого доступа на запись (push) в git-репозитории.
Вы можете добавить пользователя в проект в разделе «Участники» («Members») настроек проекта, указав уровень доступа (уровни доступа кратко обсуждались в Группы).
Получая уровень доступа «Разработчик» («Developer») или выше, пользователь может беспрепятственно отсылать свои коммиты и ветки непосредственно в репозиторий.

Другой, более разобщённый способ совместной работы — использование запросов на слияние (merge requests).
Эта возможность позволяет любому пользователю, который видит проект, вносить свой вклад подконтрольным способом.
Пользователи с прямым доступом могут просто создать ветку, отослать в неё коммиты и открыть запрос на слияние из их ветки обратно в master или любую другую ветку.
Пользователи без доступа на запись могут «форкнуть» репозиторий («fork», создать собственную копию), отправить коммиты в эту копию и открыть запрос на слияние из их форка обратно в основной проект.
Эта модель позволяет владельцу полностью контролировать, что попадает в репозиторий и когда, принимая помощь от недоверенных пользователей.

Запросы на слияние и проблемы (issues) это основные единицы долгоживущих дискуссий в GitLab.
Каждый запрос на слияние допускает построчное обсуждение предлагаемого изменения (поддерживая облегчённое рецензирование кода), равно как и общее обсуждение.
И те и другие могут присваиваться пользователям или организовываться в вехи (milestones).

Мы в основном сосредоточились на частях GitLab, связанных с git, но это — довольно зрелая система, и она предоставляет много других возможностей, помогающих вашей команде работать совместно, например вики-страницы для проектов и инструменты поддержки системы.
Одно из преимуществ GitLab в том, что, однажды запустив и настроив сервер, вам редко придётся изменять конфигурацию или заходить на него по SSH; большинство административных и пользовательских действий можно выполнять через веб-браузер.