Gitlab как собрать статистика по выходу релизов

Обновление «Управление IT-отделом 8» от 11.12.2020 релиз 3.1.8.1

Дополнение к обновлению 3.1.8.0
Дополнение к обновлению 3.1.7.9
Дополнение к обновлению 3.1.7.8
Дополнение к обновлению 3.1.7.7
Дополнение к обновлению 3.1.7.6
Дополнение к обновлению 3.1.7.5
Дополнение к обновлению 3.1.7.4
Дополнение к обновлению 3.1.7.3
Дополнение к обновлению 3.1.7.2
Дополнение к обновлению 3.1.7.1
Дополнение к обновлению 3.1.7.0

Внимание! Статьи для ознакомления

• Метод Любищева по мотивам книги Даниила Гранина «Эта странная жизнь»
• Учет расходных материалов для оргтехники
• Собственная авторизация и выход из нее в личном кабинете

Новый функционал

• В обработке «Мастер регистрации» изменены иконки типов данных. Теперь, для каждого типа своя иконка для более удобного поиска.
• При добавлении/изменении страниц в личном кабинете появилась возможность просматривать используемые параметры, а также вставлять их в тело алгоритма или в шаблон страницы HTML.
• Реализована возможность собственной страницы авторизации пользователей и выхода из нее в личном кабинете. Добавлена настройка со страницей авторизации и страницей переадресации после авторизации.
• Изменена иконка личного кабинета.
• В форме списка документа «Задание» добавлено отображение не просмотренных заданий, в которых произошли изменения или добавлен новый комментарий. Такие задания теперь отображаются «жирным» шрифтом.
• В форму списка документа «Задание» добавлена кнопка «Установить просмотрено всем» для пометки всех не просмотренных заданий просмотренными.

Изменения

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

Исправление ошибок

• Исправлена ошибка при формировании клавиатуры Telegram, если пользователем Telegram указан сотрудник.
• В некоторых случаях, может появляться ошибка при анализе ошибочных получателей, которые создаются, когда программа не смогла отправить письмо.
• Исправлена ошибка сортировки по номеру, в форме списка документа «Задание», в веб-клиенте.
• Исправлена ошибка заполнения параметров «[Задание.Уважаемыйая]», «[Задание.НомерЧислом]», при формировании исходящего электронного письма на основании документа «Задание», с помощью шаблонов сообщений.
• В личном кабинете исправлена ошибка вывода изображений сотрудников, физических лиц, пользователей на странице с информацией о контакте в адресной книге.
• Исправлена ошибка отображения фотографий сотрудников в личном кабинете и в комментариях документа «Задание».
• В личном кабинете исправлена ошибка, которая иногда могла возникать если в теме задания добавляемого комментария были спец. символы HTML в теме задания.
• Исправлены орфографические ошибки.
• Исправлена ошибка бесконечной отправки неверно сформированного сообщения в Telegram.
• Исправлена ошибка загрузки картинки физического лица из Active Directory.
• Исправлена ошибка правил отбора физического лица в подсистеме правила событий.
• В отчетах при установленном контрагенте в списке выбора договоров раньше отображались все договора, которые есть в системе. Поведение изменено. Теперь, если выбран контрагент, то при выборе договора будут отображаться только те договора, которые подчиненны организации и контрагенту.

Обновление устанавливается на версию 3.1.5.1, 3.1.6.1, 3.1.6.2, 3.1.7.0, 3.1.7.1, 3.1.7.2, 3.1.7.3, 3.1.7.4, 3.1.7.5, 3.1.7.6, 3.1.7.7, 3.1.7.8, 3.1.7.9, 3.1.8.0

Необходим сервер лицензирования версии 1.0.0.15

Барилко Виталий

Основатель и директор по развитию Софтонит. Практикующий руководитель разработки. Эксперт в области автоматизации техподдержки

Вышел GitLab 9.4: Связанные задачи и веб-мониторинг приложений

В GitLab 9.4 мы представляем связанные задачи, веб-мониторинг приложений, обновленную навигацию, групповые майлстоуны и многое другое!

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

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

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

Вдобавок к этому, мы добавляем простую и понятную интеграцию с Trello при помощи GitLab PowerUp для Trello.

Также, продолжая разговор об интеграции, в версию 9.4 входит новое приложение Slack для GitLab.

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

MVP этого месяца — Matt Gresko

Matt добавил поддержку учетных данных профиля EC2 при использовании кластеров elasticsearch AWS; ранее можно было использовать только статические данные IAM. Это сложная работа, которая значительно улучшает интеграцию GitLab с elasticsearch. Благодаря этим нововведениям, некоторые аспекты нашего Улучшенного глобального поиска настраиваются автоматически, когда GitLab запущен на AWS.

Matt также работал над изначальной имплементацией AWS. Спасибо, Matt!

Связанные задачи (EES, EEP)

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

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

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

Больше информации о связанных задачах в нашей документации

Обновленная навигация (CE, EES, EEP)

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

Для ее включения нажмите на иконку вашего профиля в правом верхнем углу экрана и выберите вариант Turn on new navigation.

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

Больше информации об обновлениях навигации в [нашей документации]

Веб-мониторинг приложений (CE, EES, EEP)

В GitLab 9.0 мы выпустили систему мониторинга производительности, интегрированную с развертыванием CI/CD, занимающуюся сбором статистики (использование процессора и памяти) развернутых на Kubernetes приложений. Это был успешный первый шаг, и теперь мы запускаем веб-мониторинг приложений, поддерживающий уже не только Kubernetes.

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

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

Больше информации о веб-мониторинге приложений в нашей документации

Секретные переменные группового уровня (CE, EES, EEP)

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

Благодаря введению секретных переменных группового уровня исчезает необходимость дублирования переменных между проектами: теперь достаточно ввести данные один раз, и у каждого проекта или подгруппы в группе автоматически откроется доступ к ним. Также эти данные легко обновлять: просто измените их в одном месте, и они автоматически обновятся для всех проектов.

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

Переменные в расписаниях конвейеров (CE, EES, EEP)

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

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

Больше информации о переменных в расписаниях конвейеров в нашей документации

Секретные переменные для сред (EEP)

Использование переменных для определения значений, используемых при развертывании на определенные конкретные среды зачастую является правильным решением. Поскольку для разных сред (например, staging и production) могут потребоваться различные значения переменных для выполнения одного и того же задания (например, название приложения), важно создать прямую связь между некоторыми переменными и соответствующей средой.

В GitLab 9.4 для решения этой задачи добавлены секретные переменные для сред; теперь разработчики могут уточнять, какие среды получат определенную переменную. Можно даже включать динамические среды, к примеру, review/ . Так что теперь можно с легкостью проводить развертывание на различные среды.

Больше информации о секретных переменных для сред в нашей документации

GitLab Power-Up для Trello (CE, EES, EEP)

Пользуетесь одновременно Trello и GitLab? Теперь это стало еще проще благодаря новому GitLab Power-Up! Для его подключения в Trello перейдите в раздел Power-Ups и найдите Power-Up GitLab . После настройки вы сможете прикреплять мерж-реквесты GitLab прямо к карточкам Trello.

В Trello вам понадобится настроить ваш домен, например gitlab.com/api/v4 для GitLab.com, а также добавить ваш персональный токен.

Больше информации о GitLab Power-Up для Trello в нашей документации

Приложение GitLab Slack для GitLab (CE, EES, EEP)

GitLab уже глубоко связан с Slack (и Mattermost, Microsoft Teams и HipChat), но у нас до сих пор не было приложения в директории приложения Slack. Теперь оно у нас есть! Интегрировать Slack в ваши проекты на GitLab.com стало гораздо проще.

Вы можете настроить интеграцию с приложением из настроек проекта в GitLab (Settings > Integrations). Скоро это также будет доступно из директории самого Slack. Вместе с Slack мы работаем над тем, чтобы убедиться, что приватные инстансы будут способны использовать одно и то же приложение Slack в ближайшем будущем. И, конечно, приватные инстансы можно интегрировать с Slack вручную по шагам, описанным в документации.

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

Улучшенная локализацию (CE, EES, EEP)

Мы постепенно ускоряемся с локализацией GitLab. Большое спасибо участникам нашего комьюнити, которые посодействовали в добавлении дополнительных языков — китайского, французского, японского и бразильского португальского. Огромное спасибо Huang Tao за постоянный вклад в это дело!

В GitLab 9.4 мы добавили локализацию поддержки для страницы коммитов.

Подробнее о локализации в нашем гайде

Групповые майлстоуны (CE, EES, EEP)

Майлстоуны — одна из основных частей отслеживания задач. Их часто используют, чтобы отмечать спринты (35 неделя), релизы (версия 9.4) или категорию (бэклог) задач и мерж-реквестов. Часто майлстоуны охватывают несколько проектов: у вас есть возможность быстро создавать майлстоуны для нескольких проектов сразу. Теперь еще лучше: мы добавили возможность создавать групповые майлстоуны.

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

Чтобы создать групповой майлстоун, перейдите в вашу группу, нажмите Issues, а потомMilestones.

Улучшения GitLab Geo (EEP)

• GitLab Geo теперь поддерживает слоты репликации PostgreSQL, чтобы предотвратить рассинхронизацию вторичных нодов Geo с первичными. Как именно использовать это в первичных нодах — смотрите в документации.
• Мы повысили производительность репликации данных Git с помощью добавления дополнительных параллельных операций клонирования.
• Geo теперь поставляется с исходной версией курсора лога событий, который позволяет использовать вторичный трек, когда нужно обновить репозиторий Git. В будущем мы запретим использовать системные хуки Geo.

Хранение объектов для артефактов CI (EEP)

Компании продолжают внедрять CI/CD по всей организации, и их хранилища артефактов тоже растут. В GitLab 9.4 вы сможете перемещать существующие артефакты CI в Amazon S3, чтобы освободить дополнительное локальное пространство и эффективно и надежно сохранять сколько угодно артефактов. Сейчас эту операцию нужно проводить каждый раз, когда вы захотите переместить ваши локальные артефакты в S3, но в следующей итерации это будет происходить автоматически, и все новые артефакты будут сохраняться в хранилище объектов сразу после их создания — никаких миграций вручную.

Расширенная настройка Docker для CI/CD (CE, EES, EEP)

В GitLab 9.4 появились новые улучшенные опции настройки для .gitlab-ci.yml . Они дают более гибко настраивать образы Docker, которые вы хотите использовать для ваших конвейеров. Чтобы воспользоваться этими возможностями, вам потребуется версия GitLab Runner 9.4 или выше.

Теперь вы сможете определить для вашего образа Docker специальную точку входа ( entrypoint ), чтобы переопределить ту, которая используется по умолчанию. Ниже приведен пример настройки точки входа для /bin/sh — это сделает образ подходящим для работ GitLab CI без дополнительных модификаций:

image: name: super/sql:experimental entrypoint: ["/bin/sh"] 

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

services: - name: super/sql:latest command: ["/usr/bin/super-sql", "run"] alias: super-sql-1 - name: super/sql:latest alias: super-sql-2 

Безопасность: добавили SSL проверку сертификата LDAP (CE, EES, EEP)

Мы добавили поддержку верификации сертификата LDAP через SSL. По умолчанию эта опция будет отключена, чтобы обеспечить обратную совместимость до выхода GitLab 9.5. Кроме того, чтобы упростить настройку безопасного соединения, вы теперь можете определить файл сертификата CA и версию SSL. Названия способов шифрования ssl и tls превратились в simple_tls и start_tls соответственно.

Настраиваемый путь для настроек CI/CD (CE, EES, EEP)

GitLab определяет настройки CI/CD в YAML файле .gitlab-ci.yml , расположенном в корне репозитория. Бывают случаи, когда вам нужно определить другую локацию для определения ваших конвейеров — например, когда вы зеркалируете SVN репозиторий и не можете хранить файлы в корне проекта.

Начиная с версии GitLab 9.4, вы сможете определять специальный путь в Settings > Pipelines, по которому будут считываться настройки CI/CD — вместо .gitlab-ci.yml по умолчанию. Переменная под названием $CI_CONFIG_PATH доступна для работ, которым нужен доступ к текущей локации настроек.

Новая политика кэширования для настройки CI/CD (CE, EES, EEP)

По умолчанию процесс кэширования заключается в скачивании файлов, их выполнении и повторной загрузки в конце. Любые изменения в рамках этого процесса будут сохраняться для следующих запусков. Это называется политикой кэширования pull-push.

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

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

Грядущее подписание пакетов Omnibus (CE, EES, EEP)

Начиная со следующего релиза 22 августа мы будем подписывать все новые пакеты. Наряду с подписанным пакетом 9.5.0 мы также будем предоставлять подписанные версии двух последних релизов (9.4 и 9.3).

Подписание пакетов добавляет уверенности в том, что файлы .deb и .rpm , необходимые для установки GitLab, не были кем-либо изменены.

GitLab Runner 9.4 (CE, EES, EEP)

Также в этом релизе мы выпустили GitLab Runner 9.4.

Самые важные изменения:

• Улучшения поддержки разделов Kubernetes (мерж-реквест и мерж-реквест)
• Поддержка политик кэширования в файле .gitlab-ci.yml (мерж-реквест)
• Расширенная настройка Docker в файле .gitlab-ci.yml (мерж-реквест)
• В команде unregister добавилась опция —all (мерж-реквест)
• Переключение на Go 1.8 (мерж-реквест)

Полный список изменений смотрите в CHANGELOG GitLab Runner

GitLab для начинающих: как и для чего используется

В материале подробно разбираем, что такое GitLab, для чего используется, чем отличается от аналогов и как с ним работать.

Что такое GitLab

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

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

Для чего нужен GitLab

GitLab имеет множество возможностей, основные из них представлены ниже.

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

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

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

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

Можно персонально настраивать модель приемки качества, тестировать код в автоматическим режиме и назначать изменения в среды тестирования для каждой версии кода.

Сборка
Репозиторий контейнеров GitLab дает возможность создавать безопасное хранилище кастомных образов контейнеров Docker. Причем для этого не придется задействовать дополнительные инструменты — возможности скачивания и загрузки образов внедрены в среду управления репозиторием Git по умолчанию.

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

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

В качестве сервиса с предварительно настроенными шаблонами приложений для разработки можно использовать GitLab CE Virtual Appliance.

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

Git, GitLab и GitHub

Каждому разработчику важно знать и понимать, чем отличаются и схожи Git, GitLab и GitHub.

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

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

Оба сервиса предназначены для использования группами разработчиков, поэтому многие функции и возможности GitHub и GitLab дублируются. Вместе с тем, есть и отличия:

• В GitLab реализована встроенная бесплатная непрерывная интеграция. В GitHub есть инструмент Actions. Он позволяет запускать бесплатные непрерывные интеграции в публичных репозиториях, а что касается частных репозиториев — стоимость указана здесь.
• GitLab задействует Kubernetes для беспроблемного развертывания. В GitHub встроенной платформы развертывания нет.
• В GitLab есть бесплатные репозитории частного формата для проектов, имеющих открытый исходный код. В GitHub такого нет.

Подробнее о том, чем еще отличается GitLab, можно прочитать на официальном сайте веб-приложения.

Еще одним решением для разработки является Cloud Container Engine от SberCloud — сервис для автоматизации развертывания, масштабирования и управления приложениями в высокопроизводительных кластерах Kubernetes. Он обеспечивает высокую производительность, корпоративную надежность и безопасность, а также открытость и совместимость.

Калькулятор виртуальных машин

Виртуальная машина+диск от 96 копеек/час

Как пользоваться GitLab

Рассмотрим основные этапы работы с GitLab:

Создание аккаунта

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

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

Создание репозитория

Для создания нового проекта надо нажать на значок «+» по центру экрана и выбрать соответствующий пункт.

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

После указания всех данных и нажатия на кнопку «Create repo», репозиторий будет создан, а на его странице будет доступен стартовый набор действий.

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

Загрузка файлов проекта

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

SSH-ключи

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

• открывается терминал и выполняется «ssh-keygen»;
• указывается путь к файлу для сохранения ключа.

После этого создается два файла — закрытый и открытый. Для создания ключей нужен открытый. Его нужно открыть в текстовом редакторе и скопировать содержимое в буфер обмена. Затем нужно перейти в GitLab и выбрать «Настройки» (Settings). В меню настроек в пункте «SSH Keys» в поле «Key» надо вставить скопированный ранее текст и сохранить изменения. Далее нужно перейти в репозиторий и нажать на кнопку «Clone». После этого нужно вернуться к локальному репозиторию, удалить адрес https и добавить ssh. На этом настройка SSH-ключей будет завершена.

Ветки репозитория

По умолчанию в репозитории GitLab предусмотрена только одна ветка — master(main). При этом для реализации вспомогательных функций отдельные этапы разработки можно выносить в независимые ветки. В веб-интерфейсе сервиса ветки отображаются слева, что упрощает переход между ними. Ветки создаются в пару кликов — нужно выбрать «+» по центру экрана и нажать «New branch». Кроме того, после обновления изменений в репозитории в GitLab отображаются и новые ветки, созданные в Git. Все операции с ветками можно выполнять через настройки.

Слияние веток

В ветках разрабатывается функциональность, поэтому может потребоваться их перенос — для этого предназначены запросы слияния («Merge request gitlab»). Для использования этой возможности в интерфейсе GitLab нужно нажать кнопку «Create merge request», задать описание «Merge Request», выбрать исходную и целевые ветки. После одобрения запроса на слияние надо нажать на кнопку «Merge». В результате файлы ветки преемника будут заменены файлами из ветки источника.

Добавление пользователей

В GitLab можно добавлять неограниченное количество разработчиков даже к приватным репозиториям. Чтобы сделать это, надо перейти в меню «Настройки» (Settings) и выбрать пункт «Участники» (Members). В этом пункте в поле «Выбрать участника для приглашения» (Select members to invite) надо указать адрес электронной почты пользователя или его никнейм. Перед отправкой приглашения также указывается уровень доступа. Для добавления надо нажать «Добавить в проект» (Add to project).

Удаление проекта

Для удаления проекта нужно перейти в «Настройки» (Settings) -> «Главные» (General) -> «Продвинутые» (Advanced) и выбрать пункт «Удалить проект» (Remove Project). Перед удалением проекта потребуется ввести его имя.

Возможные проблемы

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

1. Ошибка при выполнении pull-запросов. Причиной может быть длительная фаза SSH-аутентификации или низкая скорость обработки запросов. Решается перенастройкой репозиториев.
2. Ошибка при входе. Может появляться после некорректного введения логина и пароля учетной записи. Решается удалением данных через панель управления.
3. Ошибка при запуске. Система может указывать на отсутствие GitLab-серверов по заявленным IP-адресам. Причиной проблемы может быть неверное введение команды запуска, использование динамического IP или ошибки при назначении порта. Решается перенастройкой.

Итог

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

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

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

Gitlab — это великолепный веб-инструмент, который можно использовать для разработки проектов любого размера и сложности. Каждый разработчик или компания может найти в Gitlab для себя подход, который сделает разработку более надежной, качественной и быстрой. Я считаю, что Gitlab CI, разграничение ролей, автоматическое тестирование и мониторинг незаменимы для разработки в командах и оценки эффективности Кирилл Шеховцов Технический лидер в SberCloud.

Источники

1. Что такое GitLab, как и для чего он используется
2. GitLab и GitHub: в чем различия?
3. GitLab
4. GitLab vs GitHub

Запросите бесплатную консультацию по вашему проекту

Вышел релиз GitLab 12.0 с визуальными ревью и списком зависимостей

GitLab 12.0 — важный шаг на нашем пути к созданию универсального подхода DevSecOps, поддерживающий нашу миссию «каждый может внести вклад».

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

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

Визуальные ревью

Приложения для ревью в GitLab — отличный инструмент для всех (от операторов и тестировщиков до владельцев бизнеса) для оценки и подтверждения изменений перед их выпуском в продакшн.

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

Список зависимостей проекта

Проекты часто включают немало индивидуальных компонентов, что может привести к уязвимостям. Часто специалистам по безопасности и соответствию стандартам нужно знать все компоненты, подключенные к проекту.

Теперь список зависимостей проекта доступен в одном удобном месте.

Ограничение доступа по IP-адресам

Некоторые организации ограничивают доступ к своим репозиториям по определенным IP-адресам. С релизом GitLab 12.0 вы можете запретить доступ к данным на GitLab не с разрешенных IP-адресов.

MVP этого месяца — Wolphin

Wolphin сделал в GitLab 12.0 очень важную фичу: поддержку множественных extends в CI GitLab. Эта мощная функциональность стала еще более удобной!

Огромное спасибо за этот вклад, Wolphin!

Основные фичи релиза GitLab 12.0

Визуальные ревью

(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”

У пользователей GitLab есть возможность автоматически создавать приложения для ревью для каждого мерж-реквеста (в русской локализации GitLab «запрос на слияние»). Благодаря этому каждый может следить за изменениями в дизайне или UX.

В релизе 12.0 мы расширяем возможность обсуждать эти изменения с помощью инструментов визуального ревью прямо в приложении для ревью. Благодаря небольшому сниппету дизайнеры, менеджеры продукта и другие важные члены команды смогут быстро предоставить обратную связь по мерж-реквесту, не покидая приложение.

Список зависимостей проекта

Теперь список зависимостей проекта (или BOM — Bill of Materials) доступен в левом боковом меню.

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

Ограничение доступа по IP-адресам

Организации, в которых требуется строгий контроль доступа к своим ресурсам, теперь могут ограничивать доступ указанными IP-адресами, что может быть особенно удобно при использовании VPN. Вы можете настроить ограничения по трафику вне указанной подсети на уровне группы через интерфейс GitLab как в пользовательских экземплярах, так и на GitLab.com. Это поможет вам защищать самый ценный код вашей организации.

Синхронизация файлов с веб-терминалом

С релизом 12.0 изменения, сделанные в Web IDE, будут автоматически синхронизироваться с веб-терминалом, так что вы сможете протестировать их в терминале перед отправкой в проект. Это поможет новым участникам быстрее начинать работу и просматривать, редактировать и тестировать проект без установки локальных зависимостей.

Обратите внимание, что на GitLab.com интерактивные веб-терминалы работают только с частными обработчиками заданий (private runner).

Интеграция Git для JupyterHub

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”

Развертывание JupyterHub через интеграцию GitLab с Kubernetes помогает быстрее начать работу с блокнотами Jupyter, которые можно использовать для создания и обмена документами с «живым» кодом, графиками и перечнями задач (runbook).

Начиная с релиза GitLab 12.0 расширение Git для JupyterLab настраивается автоматически при установке JupyterHub на ваш кластер Kubernetes. Эта интеграция позволяет целиком контролировать версии ваших блокнотов и выполнение команд Git в Jupyter; команды Git могут быть вызваны через левую панель или с помощью командной строки Jupyter.

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

Поддержка множественных extends в .gitlab-ci.yml

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”

Ключевое слово extends помогает пользователям поддерживать их код для CI/CD GitLab аккуратным. Продвинутые пользователи часто используют это ключевое слово для переиспользования частых секций кода CI/CD; наши команды тоже используют его для самого GitLab и для улучшения Auto DevOps.

В релизе 12.0 мы рады добавить улучшение, которое внес Wolphin — теперь в рамках одного задания может быть несколько блоков extends , и благодаря этому вы сможете дальше улучшать свои конфигурации для CI.

Цепочки последовательных мерж-реквестов

Вместе с релизом 12.0 мы представляем новый способ поддерживать ваши master-ветки и ветки релизов «зелеными»: цепочки мерж-реквестов. Цепочки последовательных мерж-реквестов основываются на конвейерах (в русской локализации GitLab «сборочные линии») по результатам мерж-реквеста и дают возможность последовательно запускать такие конвейеры.

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

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

Сворачиваемые логи заданий

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”

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

Разработка этой фичи началась со вклада Matthias van de Meent. Спасибо, Matthias!

Разные электронные адреса для уведомлений от групп

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”

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

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

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

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

Добавление причины при отклонении уязвимостей

При отклонении уязвимости, обнаруженной нашими сканерами, теперь в отдельном поле можно подробно описать причину отклонения.

Это позволит командам по обеспечению безопасности и разработчикам делать ревью истории и разбираться в причинах отсутствия исправлений.

Работа с разрешениями пользователей только через LDAP

Организации, работающие с LDAP, обычно синхронизируют его с GitLab для управления разрешениями.

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

Предотвращение удаления проектов не-админами

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

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

GitLab Insights

GitLab Insights, представленные в GitLab Ultimate 11.9 как подключаемая фича, теперь общедоступны в GitLab Ultimate 12.0.

Настраивайте Insights, которые важны для ваших проектов, для поиска данных, таких как чистота сортировки, созданные/закрытые тикеты за выбранный период, среднее время принятия мерж-реквестов и многое другое.

Email-уведомления для неудачных сборок на master

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”

Интеграция с сервисом Pipeline Emails позволяет пользователям создавать уведомления на email нескольким получателям при удачном и неудачном завершении сборки.

В GitLab 12.0 мы добавили опцию для отправления уведомления о неудачной сборке только на ветке проекта, установленной по умолчанию (например, master ).

Спасибо Peter Marko за эту фичу!

Улучшенная поддержка передачи переменных в конвейеры на уровень ниже

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”

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

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

Более быстрое создание клонов для всех новых проектов в GitLab CI/CD

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Verify”

Начиная с GitLab 8.9 наши CI/CD поддерживали небольшие git-клоны через переменную GIT_DEPTH в определении задания.

В GitLab 12.0 мы добавили возможность задавать глубину клона на уровне проекта, позволяя maintainers (в русской локализации GitLab «сопровождающие») проекта при желании устанавливать создание небольшого клона по умолчанию. Создать такой git-клон быстрее, чем каждый раз клонировать весь репозиторий. Если ваши задания CI/CD работают на сборку последней версии, зачастую достаточно небольшого клона.

Кроме того, в GitLab 12.0 новые проекты, созданные в GitLab, будут по умолчанию иметь глубину клона GIT_DEPTH равную 50 . Это поможет пользователям быстрее производить клонирование и сборку в GitLab CI/CD, в то же время позволяя продвинутым пользователям изменять эту настройку при необходимости для разных видов сценариев использования CI/CD.

Задание прокси для зависимостей по умолчанию для всей группы

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

В GitLab 12.0 мы подключили эту фичу по умолчанию на уровне группы.

Шаблон Maven теперь автоматически делает пуш в Maven Repository

Java-разработчикам нужен простой способ производить сборку зависимостей и управлять ими при работе с конвейерами GitLab CI/CD.

В GitLab 12.0 мы изменили стандартный шаблон Maven.gitlab-ci.yml так, чтобы пользователям было проще загружать свои Java-зависимости и управлять ими через конвейеры GitLab CI/CD в репозитории Maven.

Удаление тегов из реестра контейнера через API

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Package”

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

В GitLab 12.0 мы обновили модель разрешений, чтобы позволить разработчикам удалять теги.

Дедупликация объектов git (бета-версия)

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”

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

В GitLab 12.0 дедупликация объекта может быть включена администраторами инстанса при помощи подключаемой фичи object_pools . Когда фича включена, при создании ветвления также будет создан пул объектов и будет использован objects/info/alternates для уменьшения требований к хранилищу.

Дедупликация объектов требует, чтобы родительский проект и текущий проект использовали хэшированное хранилище. Существующие ветвления пока не перемещаются в пулы объектов автоматически. Информацию по обновлениям смотрите здесь: gitaly#1560.

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

Дедупликация объектов появилась на GitLab.com 30 мая 2019, но пока она по умолчанию выключена для пользовательских инстансов из-за предупреждения о дупликации битовой карты (bitmap) при извлечении. Эта задача была решена в версии 12.0, но нам не хватило времени, чтобы подключить эту функциональность к выходу этого релиза.

Включили кэширование хэша битовой карты Git для ускорения переупаковки

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Create”

В GitLab 12.0, при перепаковке репозиториев Git, кэш хэша битовой карты будет сохранен в его индексе. Кэширование ускоряет перепаковку, особенно при использовании дельта-островов.

Обратите внимание, что версии JGit до 3.5.0 несовместимы с этой фичей.

Проверка учетных данных Kubernetes, предоставленных при создании кластера

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”

Ручное добавление кластера Kubernetes требует ручного ввода большого количества данных, что легко приводит к ошибкам. Для эффективного выявления проблем с доступом и разрешениями при добавлении кластера вручную интеграция с Kubernetes теперь будет проверять доступность URL-адреса API, а также действительность токена кластера и сертификата CA.

Если что-то пойдет не так, появятся соответствующие предупреждения.

Использование бессерверной архитектуры GitLab с существующими установками Knative

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Configure”

До этого релиза бессерверные функции GitLab (GitLab Serverless) можно было использовать только при установке Knative через GitLab. С GitLab 12.0 существующие установки Knative теперь могут использовать GitLab Serverless. Просто добавьте существующий кластер вручную, потом добавьте соответствующие бессерверные шаблоны в ваш проект, и GitLab доделает все остальное.

Это значит, что теперь вы можете использовать GitLab Serverless с размещенными предложениями Knative, такими как Cloud Run on GKE от Google или размещенный сервис Knative от IBM.

Ссылка и доступ к конференции Zoom из тикета

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”

В GitLab 12.0 мы упростили сотрудничество с товарищами по команде по тикету посредством группового звонка в Zoom. Вставьте ссылку на встречу Zoom в описание тикета. GitLab обнаружит ссылку и отобразит кнопку «Присоединиться к встрече» в верхней части под заголовком, отображая ее для всех работающих над тикетом.

Ссылка на внешние панели мониторинга из панелей управления окружением

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Monitor”

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

Уведомления о лимитах для общих обработчиков заданий CI на GitLab.com

(FREE, BRONZE, SILVER, GOLD)

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

Добавили возможность запрашивать эпики в GraphQL

API GraphQL позволяет пользователям запрашивать именно те данные, которые им нужны, что дает возможность получать все необходимые данные в ограниченном количестве запросов.

В этом релизе GitLab теперь поддерживает возможность запрашивать эпики (в русской локализации GitLab «цели») в API GraphQL.

API тикетов теперь выдает статистику завершения задачи

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”

Пользователи могут определять задачи в тикетах, и эта информация отображается во всем приложении. В GitLab 12.0 пользователи смогут получать информацию о ходе выполнения задачи через API.

Новый дизайн обсуждения по темам

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”

Наш существующий дизайн для обсуждения мерж-реквестов и тикетов включал в себя множество рамок и границ, часто затрудняя отслеживание разговора.

В GitLab 12.0 мы провели редизайн для улучшения удобства обсуждений.

Дополнительная статистика из API тикетов

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: “Plan”

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

Улучшения системных заметок для добавления и удаления отношений эпиков

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

Добавление и удаление вложенных эпиков с помощью быстрых действий.

Раньше вложенные эпики нельзя было добавить или удалить с помощью быстрых действий. С GitLab 12.0 стало возможным добавлять и удалять вложенные эпики с помощью команд быстрых действий /child_epic и /remove_child_epic .

Больше не требуется Docker в Docker для DAST

Для Dynamic Application Security Testing (DAST) больше не требуется использование Docker. В результате образ DAST Docker (3 ГБ) теперь будет кэшироваться в Runners.

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

GitLab Runner 12.0

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)

Мы также выпускаем обновление обработчика заданий GitLab 12.0! GitLab Runner — проект с открытым исходным кодом, который используется для выполнения заданий CI/CD и отправки результатов обратно в GitLab.

Самые важные изменения:

• Поддержка Docker Credentials helper
• Добавили конфигурацию access_level для обработчиков заданий при регистрации
• Разрешили настройку контекста безопасности подов из Kubernetes Executor
• Сделали PowerShell оболочкой по умолчанию для новых зарегистрированных Windows shell executors
• Поддержка настройки томов Docker под Windows

Как упоминалось в предыдущих статьях, в версии GitLab Runner 12.0 мы также убрали несколько ранее устаревших (deprecated) вещей:

• Удалили устаревшую команду clone/fetch
• Удалили устаревшую стратегию git clean
• Удалили поддержку устаревшей настройки metrics_server
• Удалили поддержку устаревшей конфигурации точки входа для K8S
• Удалили поддержку устаревшей конфигурации кэша S3
• Удалили поддержку устаревших дистрибутивов
• Удалили старые команды для вспомогательных образов Docker

Список всех изменений можно найти в CHANGELOG для GitLab Runner.

Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 12.0 released with Visual Reviews and Dependency List.

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