Создание качественного ПО — непростой процесс. Во-первых, нужно решать бизнес-проблемы и писать качественный код. Однако, на этом сложности не заканчиваются: нужно еще удостовериться в том, что ваш код работает быстро, безопасно и надежно. Работа с кодом — это конвейер из множества этапов, таких как сборка, интеграция, тестирование, обеспечение безопасности, ревью, настройка и развертывание. На выполнение всех этих действий уходит много времени и сил.
Помимо предоставления возможностей совместной работы на публичных и приватных репозиториях, GitLab также упрощает весь процесс разработки при помощи обширного встроенного, а с этой версии — еще и автоматизированного, набора инструментов. Просто сделайте коммит своего кода, и Auto DevOps займется всем остальным. Auto DevOps — это заранее собранный полноценный CI/CD конвейер, который позволяет автоматизировать весь процесс поставки. Auto DevOps выходит в общий доступ (GA, General Availability) в GitLab 11.0.
Другие ключевые нововведения GitLab 11.0:
Для начала, давайте поподробнее пройдемся по этому списку.
Auto DevOps покрывает весь цикл поставки: Просто сделайте коммит вашего кода в GitLab и позвольте Auto DevOps заняться остальным: эта система проведет сборку, тестирование, проверку качества кода, безопасности и лицензий, пакетирование, тестирование производительности, развертывание и мониторинг вашего приложения.
«GitLab является ключевым компонентом в наших процессах разработки и поставки, благодаря чему мы увеличили нашу скорость поставки в четыре раза и серьезно упростили процесс совместной разработки в наших командах» — говорит Chris Hill, ведущий системный инженер информационно-развлекательного подразделения в Jaguar Land Rover.
«Мы очень довольны Auto DevOps, поскольку он позволяет нам сфокусироваться на написании кода и бизнес-процессах. Всем остальным занимается GitLab: автоматические сборки, тестирование, развертывание и даже мониторинг нашего приложения.»
Управление лицензиями (анализ компонентов ПО): Зачастую, программное обеспечение представляет собой сложное переплетение кода со сторонними компонентами (библиотеками, фреймворками и различными инструментами). Как правило, у каждого компонента имеются лицензионные ограничения и разрешения, которые нужно отслеживать и учитывать. В GitLab 11.0 мы добавляем функциональность Управления Лицензиями (анализа компонентов ПО). Она будет встроенной в мерж-реквесты, откуда вы сможете отслеживать лицензии ваших компонентов.
Безопасность: Мы продолжаем работу над улучшением встроенных возможностей безопасности GitLab. Теперь вы сможете находить уязвимости еще раньше при помощи встроенного статического и динамического тестирования приложений, а также сканирования зависимостей и контейнеров. Мы расширили зону покрытия статического тестирования безопасности приложений (SAST) — теперь оно поддерживается для Scala и .Net. Также мы добавили новые элементы в отчеты SAST, теперь они предоставят вам еще больше деталей.
Kubernetes: Мы продолжаем улучшать нашу интеграцию с Kubernetes и упрощать взаимодействие GitLab с этой системой. В данном релизе мы добавили несколько новых фич, самой интересной из которых является возможность просмотра логов пода Kubernetes прямо из доски развертывания GitLab.
GitLab Web IDE: Чем больше вы можете сделать не выходя из IDE, тем продуктивнее вы работаете. Теперь вы сможете просматривать конвейеры CI/CD прямо из IDE, благодаря чему вы сможете увидеть мгновенный отчет в случае неудачного выполнения конвейера. Кроме того, мы добавили возможность быстрого переключения на следующий мерж-реквест, что позволит вам создавать, улучшать или проводить ревью мерж-реквестов не выходя из IDE. Все это позволит вам быстро и эффективно участвовать во внесении изменений в код и их рецензировании.
Навигация по эпикам и дорожным картам: Для улучшенной визуализации прогресса эпиков и дорожных карт может быть полезно изменить масштаб графиков времени, что позволит получить более общий обзор и упрощает их планирование. Поэтому мы добавили такую возможность в их интерфейс навигации.
Виталий внес большой вклад в развитие GitLab и уже был назван MVP несколько раз в этом году. Для версии 11.0 он проделал серьезную работу по актуализации технической стороны GitLab: Виталий перевел большинство из оставшихся тестов Spinach на RSpec, а также вложил много сил в улучшение GitLab для Rails 5. Кроме того, после того, как мы приняли решение по добавлению функциональности сжатия и мержа коммитов (squash and merge) в GitLab Coer и GitLab.com free, Виталий взялся за эту работу и закончил ее к выходу этого релиза. Вот список всех задач, которые он выполнил для GitLab 11.0.
И снова спасибо, Виталий! Скоро вы получите очередную посылку с подарками!
Первая бета-версия Auto DevOps была добавлена в GitLab 10.0. А в GitLab 11.0 Auto DevOps выходит в общий доступ (Generally Available). Auto DevOps требует минимальной настройки и выполняет всю работу по вашему проекту от стадии сборки до продакшена и мониторинга.
Auto DevOps использует лучшие практики DevOps: он проводит настройку вашей сборки, тестирования, проверки качества кода, статического и динамического тестирования безопасности, сканирования зависимостей, управления лицензиями, сканирования контейнеров, Review Apps, тестирования производительности браузера, развертывания и мониторинга — все в одном приложении. Использование этой функциональности упрощает переход на DevOps новых команд, поскольку это позволяет начать работу с цельным функционирующим конвейером.
Auto DevOps позволяет разработчикам сфокусироваться на том, что наиболее важно для их организации — поставке качественного кода.
Наш обновленный гайд по быстрому началу работы с Auto Devops можно посмотреть тут.
Непрерывная интеграция (CI) является важным этапом поставки высококачественного ПО. Теперь вы сможете узнать статус CI текущего коммита просто посмотрев на окно статуса в левом нижнем углу Web IDE. Более того, справа вы сможете посмотреть на статус и логи каждой работы. Это упрощает работу над мерж-реквестами с неудачным прохождением CI, поскольку вы можете открыть на одном экране неудавшуюся работу и файл над которым вы работаете сейчас.
Ранее в таких ситуациях приходилось открывать несколько вкладок и переключаться между ними, а теперь вся необходимая информация доступна прямо в Web IDE. В будущем мы планируем добавить возможность предпросмотра и тестирования изменений перед коммитом.
Легко представить ситуацию, в которой один человек работает над множеством мерж-реквестов в нескольких проектах одновременно. Теперь вы сможете переключаться между своими (назначенными на вас и созданными вами) мерж-реквестами в один клик. Не важно, проводите ли вы ревью чужого мерж-реквеста или работаете над своим — благодаря этому нововведению вы сможете уделять больше времени коду и меньше поиску.
В реалиях современной разработки ПО большинство приложений используют сторонние компоненты для выполнения определенных функций; такой подход позволяет не начинать каждый проект с чистого листа. Поэтому так распространены third-party библиотеки, зачастую они напрямую поставляются сервисами управления пакетами вроде RubyGems и npm. Однако, при таком подходе нужно следить за тем, чтобы лицензии сторонних компонентов были совместимы с вашим приложением, ведь конфликтующие лицензии могут привести к юридическим проблемам.
Для решения таких проблем мы добавляем в GitLab 11.0 функциональность управления лицензиями. Она автоматически проходит по всем зависимостям в ваших проектах и агрегирует их лицензии. Новые лицензии отображаются в виджете мерж-реквеста перед тем, как они станут частью ветки main.
Если вы используете Auto DevOps, управление лицензиями автоматически включено для ваших проектов. Вы также можете включить эту функциональность вручную для кастомных определений .gitlab-ci.yml
.
Документация по управлению лицензиями
Грамотное управление пользовательскими данными — обязательное требование для крупных организаций. Зачастую для этих целей используется сервис идентификации (identity provider), который работает со всеми пользовательскими данными, поэтому мы добавили поддержку Security Assertion Markup Language (SAML) для групп.
Теперь владельцы групп смогут настроить сервис идентификации для группы и предоставлять пользователям единую ссылку авторизации (SSO). Благодаря этому появилась возможность проводить управление авторизацией и персональными данными на уровне групп, что может оказаться полезным в случаях, когда общий SAML инстанса не удовлетворяет всем требованиям группы.
Данное нововведение особенно полезно для групп GitLab.com, в которых теперь можно настраивать сервис идентификации для использования в энтерпрайзе.
Документация по SAML для групп
С выходом GitLab 10.0 мы провели серьезное обновление навигации, а в версии 11.0 мы добавляем несколько новых тем для нее. Теперь у вас есть еще больше возможностей для персонализации вашего взаимодействия с GitLab.
Мы добавили абсолютно новую красную тему, а также светлую версию для всех существующих тем.
Документация по настройкам профиля
При работе над масштабным нововведением разработчики зачастую пушат множество коммитов в рабочую ветку, причем количество этих коммитов может только возрасти в процессе ревью кода. Многие команды предпочитают проводить сжимать эти коммиты в один перед мержем с веткой master. Это позволяет поддерживать читаемость истории Git, что серьезно упростит ревью изменений кода в будущем.
Сжатие (squash) является частью функциональности git, так что разработчики могут выполнять эту команду на своем компьютере непосредственно перед мержем. Однако GitLab еще больше упрощает этот процесс: вы можете провести сжатие и мерж в один клик прямо из веб-интерфейса. Например, сопровождающие репозитория теперь могут сжимать коммиты, не обращаясь к автору изменений, что ускоряет и упрощает рабочий процесс.
Ранее эта функциональность была доступна только в GitLab Starter, GitLab.com Bronze и на более высоких уровнях. Однако, множество пользователей говорили нам, что такая возможность будет полезна для всех уровней подписки, поэтому теперь она выходит в открытый доступ и становится доступной в GitLab Core и GitLab.com Free!
Спасибо blackst0ne за его вклад в эту работу!
Документация по сжатию и мержу коммитов
На июньской WWDC Apple анонсировали интеграцию Xcode с GitLab, что несомненно упростит работу с проектами Xcode на хосте GitLab.
Теперь GitLab поддерживает клонирование проектов, содержащих файлы .xcodeproj
или .xcworkspace
по нажатию кнопки «Open in Xcode». При просмотре проектов Xcode в интерфейсе GitLab эта кнопка будет расположена рядом с Git URL для клонирования.
Документация по открытию проектов в Xcode
Поскольку нет никаких ограничений на даты начала и конца эпиков, мы решили добавить возможность нахождения эпиков по временным диапазонам.
В данном релизе мы добавляем функциональность диапазонов дат для дорожных карт. Теперь вы сможете искать эпики по кварталам, месяцам и неделям. Поиск по неделям может быть полезен для команд, сфокусированных на выпуске краткосрочных релизов, тогда как для глобального планирования деятельности компании лучше подойдут более крупные диапазоны.
Документация по диапазонам дат для дорожных карт
С целью повышения эффективности работы с GitLab, мы решили, что гостевые (Guest) посетители больше не будут занимать лимит пользователей инстанса Ultimate.
Благодаря тому, что гостей может быть сколько угодно, количество пользователей, участвующих в обсуждении разработки теперь тоже не ограничено. Гостям можно повышать уровень доступа, однако не забывайте о том, что тогда они начнут занимать лимит.
Также важно помнить, что в случаях, когда пользователь входит в инстанс, но не принадлежит ни к одной группе или проекту, он тоже считается гостем.
Документация по разрешениям для гостевых пользователей
Доски задач являются полезным инструментом для управления рабочими процессами: вы можете следить за перемещением задач между различными стадиями жизненного цикла при помощи списков меток.
В данном релизе мы добавляем списки исполнителей для досок задач. Такой список показывает задачи, назначенные на конкретного пользователя, что добавляет новые возможности для использования досок задач.
Теперь вы можете настроить доску задач для вашей команды, а затем добавить списки исполнителей для ее членов. Это позволит легко увидеть, кто и над какими задачами работает в команде. Такая функциональность может быть полезной как для менеджеров, которые занимаются распределением нагрузки, так и для рядовых пользователей, которые хотят сориентироваться в рабочем процессе.
Вы сможете даже добавлять списки меток и списки исполнителей на одну и ту же доску.
Документация по спискам исполнителей для досок задач
В этом релизе мы добавляем структуру подгрупп GitLab для майлстоунов. Теперь вы сможете назначить майлстоун проекта или группы, унаследованный от любой родительской группы, для любой задачи или мерж-реквеста.
То есть, если у вас есть высокоуровневая группа с набором майлстоунов, вы можете использовать те же самые майлстоуны для всех задач и мерж-реквестов во всех дочерних подгруппах. Это нововведение упрощает работу в организациях со сложной многоуровневой структурой подгрупп и проектов.
Более того, вы можете проводить фильтрацию по таким майлстоунам в групповых списках задач, что позволит находить нужные объекты на всех уровнях иерархии.
Запросы задач и мерж-реквестов в API теперь консистентны с веб-интерфейсом. То есть, когда вы запрашиваете определенную группу через API для задач и мерж-реквестов, вы получите результаты из всех дочерних проектов или подгрупп этой группы. Алгоритм работает по аналогии с просмотром тех же объектов в списках групп в веб-интерфейсе, что мы представили несколькими релизами ранее.
Раньше, при использовании Auto DevOps в частных или внутренних проектах, после завершения развертывания у Kubernetes не было доступа в регистр. Это не позволяло кластеру совершать повторные fetch-операции образа (для масштабируемости, работы с отказами и т.д.)
С GitLab 11.0 создается новый токен развертывания. Он предоставляет постоянный доступ к регистру, когда на приватных/внутренних проектах включен Auto DevOps. Это гарантирует, что кластер может выполнять необходимые операции, и уменьшит вероятность отказов.
Документация о токенах развертывания для Auto DevOps
Для одних приложений выгодно отправлять каждое изменение в продакшен сразу по его готовности. Для других может быть лучше собрать эти изменения в общем окружении для более тщательного тестирования. Раньше настроить стратегию развертывания для каждого проекта было возможно только с помощью специальных переменных, которые настраивались и использовались для каждого проекта по отдельности.
Начиная с GitLab 11.0, Auto DevOps позволяет настроить вашу стратегию развертывания в один клик. При подключении Auto DevOps для вашего проекта вы сможете определить, развертывать ли ваш проект автоматически сразу в продакшн, или его предварительно нужно автоматически развернуть в тестовое окружение, а уже затем — вручную — в продакшен. Возможность настроить это в один клик позволит вам меньше времени заниматься настройками развертывания и больше — кодить.
Документация по настройке развертывания с Auto DevOps
Часто нам бы хотелось выкатывать изменения на небольшую часть пользователей или серверов, чтобы оценить влияние этих изменений до развертывания на всем окружении. Раньше пользователям Auto DevOps для запуска канареечного развертывания приходилось делать явную (explicit) специализацию шаблона Auto DevOps и определять желаемое поведение.
Начиная с GitLab 11.0, пользователи смогут определять свою политику относительно канареечного развертывания с помощью переменной окружения CANARY_ENABLED
— быстро и без дополнительных настроек шаблона Auto DevOps.
Документация о политике развертывания для канареечных окружений
Подтверждения мерж-реквестов — давняя фича GitLab, которая принуждает команды делать ревью кода (или чего бы то ни было) в мерж-реквесте. Пока подтверждения не будет, мерж-реквест будет заблокирован для мержа.
До этого релиза подтверждения нужно было включать в настройках проекта. Чтобы упростить и оптимизировать эту фичу, теперь подтверждения будут включены для всех проектов GitLab (для планов Starter, Bronze и выше) по умолчанию.
В то же время, разумеется, мы не хотим замедлить процесс создания и мержа кода. Поэтому, когда пользователь создает проект, число необходимых подтверждений мерж-реквеста для этого проекта будет по умолчанию обнулено (как если бы подтверждения были выключены). По мере роста проекта пользователь и его команда смогут внедрять подтверждения, когда того требует рабочий процесс. Для этого нужно будет лишь изменить цифру подтверждений на ту, которая будет удовлетворять нуждам команды.
Документация о подтверждениях для мерж-реквестов
Создавать в GitLab кластеры Kubernetes теперь стало просто как никогда. В GitLab 11.0 значения полей «project» и «zones» автоматически загружаются из вашего аккаунта Google Kubernetes Engine (GKE) и для упрощения отображаются в виде списка. Раньше для создания кластера при использовании GKE нужно было вводить все эти данные вручную.
Упрощенный процесс создания кластера позволит быстро поднимать кластеры из GitLab и ускорит развертывание ваших приложений.
Документация по добавлению и созданию в GitLab нового кластера GKE
Когда один или несколько этапов Auto DevOps (юнит-тестирование, проверка качества кода и т.п.) не нужны в вашем приложении, было бы здорово настроить конвейер так, чтобы он запускался только на тех этапах, которые вам нужны.
Версия GitLab 11.0 дает возможность пропускать один или несколько этапов Auto DevOps с помощью переменных окружения. Это позволит вам использовать преимущества Auto DevOps даже тогда, когда не все его этапы подходят для ваших нужд.
Документация по переменным окружения для Auto DevOps
Git LFS помогает версионировать большие файлы с помощью Git за счет хранения их вне репозитория и ленивого скачивания их по мере необходимости — вместо клонирования.
При импорте проекта из GitHub, Bitbucket Cloud или использовании Git URL, GitLab теперь импортирует также и объекты LFS. За счет этого у вас получается полная копия репозитория, включая те самые объекты LFS. Ранее, объекты LFS не включались в импорт.
Документация по импорту проекта
В GitLab 11.0 мы добавили раздел Operations в панель навигации — эти фичи теперь проще и быстрее найти. В этом релизе Environments и Kubernetes переехали из CI/CD в Operations. В будущих релизах мы добавим туда еще несколько секций, например, метрики и логи.
Мы продолжаем делать наши инструменты безопасности для самых распространенных языков и фреймворков более доступными; как часть этого процесса мы непрерывно расширяем возможности системы статического тестирования безопасности приложений (SAST).
В GitLab 11.0 мы добавили поддержку двух новых языков: .NET и Scala. Если вы уже используете Auto DevOps или последнюю версию определения работы sast
в вашем файле .gitlab-ci.yml
, вам не нужно ничего менять в своих проектах.
Мы рады представить вам бета-версию облачной диаграммы GitLab Helm. Эта диаграмма основана на более облачной внутренней архитектуре с контейнером для каждого компонента GitLab и не требует общего хранилища данных. За счет этого повышается отказоустойчивость, масштабируемость и производительность GitLab на Kubernetes.
Документация по диаграмме GitLab Helm
JupyterHub — это многопользовательский сервис для легкой поддержки блокнотов внутри команды анализа данных. Блокноты Jupyter предлагают интерактивную программируемую среду, которая обычно используется для анализа данных, симуляции, визуализации и машинного обучения.
GitLab 11.0 умеет по одному клику разворачивать JupyterHub в интегрированный кластер Kubernetes — он автоматически настроен для использования GitLab для бесшовной аутентификации. Дополнительные возможности вроде HTTPS, фильтрации по группам и настраиваемых блокнотов будут добавлены в будущих релизах.
Документация по развертыванию JupyterHub
Вес задач в GitLab полезен для обозначения оценки усилий или каких-то других метрик, связанных с работой над задачей. Раньше вы могли назначать вес задачи только от 1 до 9 — но это ограничивало те команды, которые стремятся к более подробным оценкам.
Начиная с этого релиза, вес задачи может быть любым целым неотрицательным числом, от 0 до бесконечности. У вас больше нет ограничений по оценкам. Кроме того, графики выполнения задач автоматически учитывают новые значения веса, и ваша команда сможет сразу оценить преимущества расширенного диапазона.
GitLab позволят проводить активную асинхронную совместную работу и коммуникацию. Из-за возможности документировать идеи и обсуждать их в таком большом количестве мест, мы призываем к поддержанию единого источника правды в описании задачи или эпика.
Это ведет к тому, что описания часто обновляются. Порой — несколько раз за считанные минуты. Получается множество системных уведомлений о том, что описание обновилось. С этого релиза системные заметки об обновлениях описания в течение короткого промежутка времени будут объединяться в одну. Это уменьшит количество визуального шума и сделает немного проще навигацию по комментариям в GitLab. В следующем релизе мы добавим аналогичную функциональность в описания мерж-реквестов.
Разработчикам критически важна возможность просматривать логи для того, чтобы понимать, как ведет себя приложение, и отслеживать возможные проблемы. С этой версии просмотр логов проблемного пода доступен в один клик.
На странице Environments статусы подов каждого приложения отображаются с помощью досок развертывания. По наведению курсора на каждый из подов появляется полное название пода и его статус, а по клику — отображаются его логи.
В команде GitLab мы стараемся построить самостоятельную культуру. Поэтому даже в продукте GitLab мы ищем способы отразить ее.
Мы решили переименовать роль Master в роль Maintainer. Это уберет негативный контекст, который мог быть связан с термином «Master», и, в то же время, термин «Maintainer» легко понять. С каждым маленьким шагом мы развиваемся и как продукт, и вместе как индустрия.
Метки — очень мощный механизм GitLab. Команды продолжают создавать и использовать все больше меток, а мы стараемся сделать так, чтобы ими было легко управлять. В этом релизе мы почистили дизайн страниц списка меток, упростили интерфейс, сделав информацию более читаемой, и сделали интерфейсные фишки, чтобы можно было быстро управлять деталями конкретной метки.
Мы сделали небольшое изменение для атрибута ‘scope’ API задач, чтобы привести его в соответствие формату змеиного регистра (snake case). Атрибут ‘scope’ теперь использует значения переменных created_by_me
и assigned_to_me
. Начиная с GitLab 11.0 вам нужно использовать этот формат вместо предыдущего, в котором использовалось написание через дефис (kebab-case).
В GitLab 10.7 мы добавили поддержку выражений с переменными для ключевых слов only
и except
. Эти ключевые слова определяют, нужно ли создавать работу, когда переменная существует или имеет определенное значение.
В GitLab 11.0 мы расширили этот синтаксис: теперь доступны регулярные выражения. Вы сможете создавать гибкие определения, основанные на целом ряде параметров. Например, пропустить работу с определенным сообщением коммита.
Документация по поддержке регулярных выражений для выражений с переменными
В GitLab 10.6 мы добавили отображение IP адреса конкретного GitLab Runner в деталях веб-интерфейса. Это очень полезно для получения информации об инфраструктуре, управления ей и для отслеживания проблем.
С GitLab 11.0 мы также выдаем эту информацию по запросу API, так что теперь ее можно использовать в автоматизированных процессах.
За эту фичу спасибо Lars Greiss.
Документация по API GitLab Runner
Также с этим релизом мы выпускаем GitLab Runner версии 11.0. GitLab Runner — это проект с открытым исходным кодом, используемый для запуска работ CI/CD и пересылки результатов обратно в GitLab.
--paused
в команду gitlab-runner register
Полный список изменений вы найдете в CHANGELOG файле GitLab Runner.
Начиная с GitLab 11.0 пакет Omnibus GitLab будет проверять gitlab.rb
на устаревшие настройки до начала обновления. В случае, если устаревшие настройки обнаружатся, пакет отменит процесс обновления до внесения любых изменений. Это позволит существующим версиям продолжать корректно работать до тех пор, пока администратор не обновит проблемные настройки.
Документация по Omnibus GitLab
При запуске работ CI/CD для вашего проекта, иногда нужен способ отличить один запуск от другого. Для этой цели полезен уникальный идентификатор, который изменяется каждый раз, когда создается новый конвейер. Такая идентификатор уже был — для этого использовалась переменная окружения CI_PIPELINE_ID
. Но этот счетчик был один на весь инстанс GitLab, из-за чего он слишком быстро рос, угрожая проблемами с длинными номерами.
В GitLab 11.0 мы представляем другую переменную окружения: CI_PIPELINE_IID
. В ней содержится упоминание того, к какому проекту она относится. Это значит, что такой счетчик будет увеличиваться только тогда, когда создается новый запуск в конкретном проекте. Числа не будут расти так быстро, как в случае с предыдущим счетчиком, а разработчики смогут использовать эту переменную в процессе релиза — например, как часть номера версии.
Документация по предопределенным переменным CI/CD
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 11.0 released with Auto DevOps and License Management.
Над переводом с английского работали @rishavant и @sgnl_05.