Введение в непрерывную поставку (CD) при помощи GitLab

Данный туториал позволит вам быстро прочувствовать как происходит командная работа с использованием GitLab. В целом, начать практиковать DevOps/CD с GitLab проще чем с использованием других продуктов потому что GitLab это решение "всё в одном".

В процессе этого туториала мы

• настроим базовое управления проектом на GitLab.com;
• создадим конвейер непрерывной поставки
• проведём несколько циклов работы с GitLab Flow
• изучим метрики CI/CD в GitLab

Желательны но необязательны базовые знания

• Git;
• Node.js;
• React;
• Docker;

Время от времени я буду просить вас что-то сделать. Такие моменты помечены значком "!". Пожалуйста выполняйте действия по мере чтения текста чтобы получить от данного туториала наибольшую пользу.

В оригинале места где требовалось что-то сделать были помечены эмодзи "молоток и гаечный ключ". Так как редактор habr'а вырезает эмодзи, я заменил эти эмодзи на "!".

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

Введение и знакомство с проектом

В качестве "подопытного кролика" мы будем использовать чуть модифицированный шаблонный проект, созданный утилитой create-react-app.

Почему React? Во-первых, это самая распространённая UI-библиотека на JavaScript, и многие читатели знакомы с ней. Во-вторых create-react-app даёт нам осмысленные стадии компиляции и тестирования которые уже реализованы за нас.

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

git clone https://github.com/ntaranov/gitlab-cd-react

! Перейдите в каталог локального репозитория

cd gitlab-cd-react

Должна отобразиться стандартная стартовая страница create-react-app.

Вы можете вместо этого этапа просто создать новое приложение при помощи create-react-app, но версия в репозитории содержит некоторые правки, и версии пакетов в коде в репозитории я тестировал.

! Установите npm пакеты локально, выполнив

npm install

Используйте npm ci если при выполнении npm install произойдёт ошибка

! Попробуйте "собрать" проект

npm run build

Обратите внимание, что в папке ./build появились соответствующие файлы, включая минифицированный JavaScript и CSS.

! Затем запустите тесты

npm run test -- --coverage --watchAll=false --forceExit

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

npm start

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

• централизованный репозиторий с
  
  • управлением полномочиями членов команды;
  • code review;
• багтрекер чтобы
  
  • планировать работу и
  • отслеживать прогресс;
• среду сборки с
  
  • автоматическим запуском конвейера непрерывной поставки в нужные моменты;
  • визуализацией статуса сборки;
  • хранением артефактов;
  • автоматическим оповещением о ключевых событиях;
  • автоматическим развёртыванием в разные среды;
• сбор метрик непрерывной доставки.

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

GitLab выделяется на общем фоне отсутствием ограничений на использование собственных job runners, однако некоторые довольно базовые "управленческие" и "корпоративные" фичи GitLab вроде обязательного утверждения merge request'ов входят в платные версии. Проектам с открытым кодом все фичи GitLab доступны бесплатно.

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

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

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

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

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

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

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

git push https://gitlab.com/<user name>/gitlab-cd-react

<user name> тут ваше имя пользователя на GitLab.com.

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

! Пожалуйста перейдите по адресу https://gitlab.com/<user name>/gitlab-cd-react.

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

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

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

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

Создайте задачи с заголовками, перечисленными в списке ниже.- [ ] Создать метки- [ ] Настроить доску- [ ] Создать конвейер непрерывной поставки- [ ] Провести несколько итераций GitLab Flow- [ ] Изучить метрики

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

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

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

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

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

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

! Закройте задачу Создать задания для туториала. Для этого можете в Issues -> List или Issues -> Board кликнуть на заголовок задачи и внутри формы редактирования задачи нажать на кнопку Close issue.

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

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

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

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

• Open
• Dev
• Dev: done
• QA
• Closed

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

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

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

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

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

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

! Откройте задачу Создать метки и назначьте его на себя. Выберите Issues -> Labels в левом меню, затем нажмите New label в правой части основной области. Заведите таким образом следующие 3 метки, выберите разные цвета на свой вкус.

• Dev
• Dev: done
• QA

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

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

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

Настройка доски

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

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

! Выберите Issues -> Boards в левом меню. Вы увидите доску по умолчанию. В ней уже будут колонки-списки Open и Closed. Нажмите Add list в правой верхней части основной области. Создайте по одному списку для каждой из созданных ранее меток

• Dev
• Dev: done
• QA

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

! На странице Issues -> Boards перетащите задачу Настроить доску мышкой из столбца Open в столбец Dev. Выделите задачу кликнув на часть карточки, не занятую текстом.

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

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

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

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

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

Конвейер непрерывной поставки

В этой секции мы реализуем непрерывную поставку(Continuous Delivery) средствами GitLab.

Построение конвейера непрерывной поставки в GitLab

Для того чтобы на самом деле выполнять код задач конвейеров, GitLab.com использует общие агенты (shared runners) которые реализуют docker executors. Если вы зарегистрируете свои собственные агенты, вам будет доступна куда большая гибкость в выборе сред сборки.

Давайте теперь сконструируем наш конвейер.

! Назначьте issue Создать конвейер непрерывной поставки и переведите его в статус Dev.

! Создадим конвейер непрерывной поставки(CI/CD pipeline). Для этого требуется создать файл .gitlab-ci.yaml.
На момент написания этой статьи это можно было сделать так.

1. Перейдите в проект gitlab-cd-react
2. Либо на странице Project overview / Details либо на странице Repository вы увидите файлы в вашем репозитории.
3. Выберите опцию New file как показано на скриншоте. Вас перенаправят на страницу создания файла.
   
4. В окне File name введите имя файла .gitlab-ci.yml, поле Template правее заполнится автоматически, появится ещё одно поле Apply a template. Ознакомьтесь с доступными опциями, попробуйте повыбирать разные варианты. В конце концов выберите Bash это просто шаблон с командами bash, мы будем использовать его в качестве отправной точки.

Давайте разберём полученный файл. Официальная документ по формату файла .gitlab-ci.yml находится тут.

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

image: busybox:latestbefore_script:  - echo "Before script section"  - echo "For example you might run an update here or install a build dependency"  - echo "Or perhaps you might print out some debugging details"after_script:  - echo "After script section"  - echo "For example you might do some cleanup here"build1:  stage: build  script:    - echo "Do your build here"test1:  stage: test  script:    - echo "Do a test here"    - echo "For example run a test suite"test2:  stage: test  script:    - echo "Do another parallel test here"    - echo "For example run a lint test"deploy1:  stage: deploy  script:    - echo "Do your deploy here"

Чтобы получить нужный нам конвейер чуть модифицируем этот файл.

image: busybox:latest

image задаёт какой образ docker будет использован для выполнения jobs сборки. По умолчанию GitLab использует Docker Hub, но это можно настроить. Нам понадобится образ с предустановленным Node.js.

! Укажите

image: node:14-alpine

before_script и after_script выполняются перед и после каждой задачи соответственно. В процессе выполнения задач, мы будем использовать модули Node.js.

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

cache:  key: ${CI_COMMIT_REF_SLUG}  paths:    - .npm/before_script:  - npm ci --cache .npm --prefer-offline

• Мы вначале указываем где задачи будут искать кэш, а именно внутри текущей папки в подпапке .npm.
  В качестве ключа кэша используем ${CI_COMMIT_REF_SLUG}, это означает что мы держим отдельный кэш для каждой ветви в Git.
• В before_script мы устанавливаем пакеты в соответствии с package-lock.json, указывая в качестве пути для кэша подпапку .npm.

Таким образом, в дальше в коде .gitlab-ci.yml мы можем исходить что пакеты уже установлены.

after_script нам в этом туториале не понадобится.

Перейдём к секции build1, изначально там должно быть что-то вроде этого:

build1:  stage: build  script:    - echo "Do your build here"

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

! Изменим команды чтобы действительно осуществлять сборку:

build1:  stage: build  script:  - npm run build  artifacts:    expire_in: 1 week    paths:    - 'build/'

• npm ci устанавливает необходимые модули в соответствии с файлом package-lock.json без проверки существуют ли они уже в папке node_modules.
• npm run build запускает саму сборку минифицированного React-приложения.
• artifacts указывает какие файлы должны быть сохранены для использования в будущем. Webpack с настройками create-react-app по умолчанию копирует файлы в папку build. expires_in мы используем для того чтобы не тратить место на уже не нужные сборки.

Обратим теперь внимание на кусок кода для этапа stage: test

test1:  stage: test  script:    - echo "Do a test here"    - echo "For example run a test suite"test2:  stage: test  script:    - echo "Do another parallel test here"    - echo "For example run a lint test"

! Нам не нужна задача test2, а задачу test1 изменим следующим образом:

test1:  stage: test  script:  - "CI=true npm test"   dependencies:  - build1

• npm test тут запускает модульные тесты, определённые в нашем проекте.
• dependencies указывает что данная задача test1 зависит от результатов задачи build1 чтобы артефакты этой задачи были доступны в текущей.

Перейдём к части связанной напрямую с развёртыванием.

deploy1:  stage: deploy  script:    - echo "Do your deploy here"

Эта часть обычно завязана на специфику среды в которую осуществляется развёртывание и потому технически сложна. GitLab поддерживает развёртывание в Kubernetes с минимальными усилиями по настройке. Альтернативой является реализация логики развёртывания в другую среду своими силами. Оставим технические детали этого процесса для будущих статей. Фокус данной статьи на объяснении основ работы с GitLab, поэтому мы прибегнем к хитрости, а точнее используем то обстоятельство что наше приложение на React технически является статическим вебсайтом и развернём его на GitLab Pages, которые доступны любому у кого есть учётная запись на GitLab.com.

! Заменим job deploy1 на этот код.

pages:  stage: deploy  script:  - mv public _public  - mv build public  only:  - master  artifacts:    paths:    - public  dependencies:  - build1

Мы переименовали deploy1 в pages потому что GitLab именно по названию задачи понимает что требуется развернуть файлы доступные этой задаче в GitLab Pages.
Далее делаем 2 вещи.

• mv public _public сохраняет папку public которая есть в приложении, сгенерированном из шаблона create-react-app. Мы делаем это потому что GitLab будет возвращать в ответ на запросы к Pages именно содержимое папки public.
• mv build public тут мы как раз помещаем результат сборки туда где веб-сервер GitLab Pages будет искать его.

Завершим на этом работу над нашим конвейером.

! Закоммитьте отредактированный файл .gitlab-ci.yml, укажите "Add CI/CD pipeline" в качестве Commit message, оставьте в качестве ветви master.

! Переведите задачу Создать конвейер непрерывной поставки в стадию Dev: done.

Проведём несколько циклов работы с GitLab Flow

Git очень гибкая система контроля версий кода и использовать его можно очень по-разному. Если каждый член команды использует Git по-своему, возникает путаница когда трудно понять логику действий других людей из истории изменений, и никто не понимает что ожидать от других. Об измерении производительности в такой ситуации и говорить не приходится. Для того чтобы такая путаница не возникала участники команды обычно договариваются о единых правила работы с Git, такая договорённость и называется Git workflow.

Чтобы изучить реализацию GitLab Flow в GitLab мы сделаем эти вещи:

• обсудим что такое процесс работы с Git(Git workflow) вообще;
• посмотрим, как в GitLab устроены права доступа и защищённые ветви;
• разберёмся как работают merge request`ы;
• проведём несколько итераций GitLab Flow.

Процесс работы с Git

Если коротко, то GitLab Flow состоит в том что

• при каждой необходимости что-то изменить в коде создаётся ветвь от главной (в Git по умолчанию master);
• затем открывается merge request (в других системах называется pull request) где происходит обсуждение вносимых изменений;
• для каждой из сред (тестовой, продуктивной и т.д.) при этом существует отдельная ветвь;
• одна из "ветвей сред", откуда происходит безусловное развёртывание может совпадать с главной;
• развёртывание происходит путём слияния в ветвь соответствующей среды;
• cлияния происходят из feature branch в главную ветвь или из "менее продуктивной" ветви среды в "более продуктивную".

На самом деле для реализации CD нам годится любой процесс работы с Git который поддерживает trunk based development, и мы могли бы реализовать любой такой процесс при помощи GitLab. Однако по той причине, что GitLab рекомендует использовать GitLab Flow и для того чтобы не усложнять наш сценарий, мы его и используем.

Уровни доступа в GitLab

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

• Instance administrator доступен только для отдельных инсталляций, может всё.
• Owner владелец группы проектов, может всё кроме чисто технических штук типа включения-отключения фич и интеграции с другими сервисами.
• Maintainer может всё кроме некоторых действий в отношении всего проекта типа изменения его названия или степени видимости, а также деструктивных действий типа удаления задач.
• Developer может то же что и Maintainer кроме некоторых администраторских и деструктивных функций внутри проекта типа настройки защищенности ветвей и редактирования комментариев.
• Reporter может редактировать задачи, но не может вносить изменения в репозиторий.
• Guest доступ только на чтение issue кроме конфиденциальных, может создавать новые задачи.
  Данные о полномочиях здесь приведены для полноты, активно использовать в рамках туториала мы их не будем.

Merge requests

Merge requests основной способ внесения изменений в код при использовании GitLab. Изменения вносятся в код, затем автором изменений создаётся merge request, который затем обсуждается, в котором происходит code review. Merge request в результате принимается, отправляется на доработку или отклоняется.

! Зайдите в задачу Провести несколько итераций GitLab Flow, назначьте его на себя и переведите в колонку Dev.

! Переведите задачу Создать конвейер непрерывной поставки в стадию QA.

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

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

! Откройте файл src/App.js на редактирование (Repository -> Files, Edit) и добавьте эту строчку прямо вверху файла.

import {useEffect} from 'react';

В качестве Commit message укажите, например, "Add React imports". В качестве Target branch оставьте master и нажмите Commit changes.

Упс, мы только что закоммитили изменения сразу в master. Некоторые workflow позволяют такое, но мы будем работать в рамках GitLab Flow. Избежать подобных казусов в дальнейшем нам поможет фича GitLab под названием защищённые ветви(protected branches). Её смысл не в разграничении доступа, а в том, чтобы помочь членам команды работать в рамках договорённостей и избежать случайного изменения и удаления данных в репозитории.

! Нажмите в левом меню Settings -> Repository. В открывшейся странице найдите раздел Protected Branches.

Вы увидите что по умолчанию защищена только ветка master, но вы можете добавить и другие. И по умолчанию

• force push запрещён всем
• push разрешён Maintainers
• merge разрешён Maintainers

! Измените Allowed to push на No one.

! Отлично, давайте вернёмся к редактированию файла src/App.js. После строчки

function App() {

перед строчкой

  return (

добавьте

  useEffect(() => {    alert('Consent to cookies and everything!');  }, []); 

Соответствующий участок кода должен теперь выглядеть примерно так

// ...other codefunction App() {  useEffect(() => {    alert('Consent to cookies and everything!');  }, []);   return (// ...other code

Укажите "Add the annoying popup" в качестве commit message.

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

! Замените предлагаемое имя на master и нажмите Commit changes.

Вы увидите сообщение об ошибке You are not allowed to push into this branch. Хорошо! Защита ветвей работает. Давайте теперь инициируем процедуру внесения изменений в код так как это предполагается делать.

! Замените теперь имя ветви с master на feature-cookies-consent. Оставьте чекбокс Start a new merge request with these changes установленным. Будет создана ветвь с указанным названием и изменения будут закоммичены в эту ветвь. Вы окажетесь на странице создания merge request'а. Оставьте

• заголовок merge request'а по умолчанию.
• Assignee и Reviewer Unassigned.
• всё остальное также по умолчанию.

Нажмите Submit merge request

Кстати

• Assignee ответственный за работу над merge request'ом и его слияние в целевую ветвь,
• Reviewer же изучает предложенные изменения и может согласовать их если они кажутся правильными.

После создания merge request'а, ы окажетесь его на странице. Давайте изучим эту страницу. В основной области мы видим следующее.

• Какую ветвь мы сливаем с какой (feature-cookies-consent в master).
• Статус pipeline для ветви feature-cookies-consent.
• Возможность согласовать merge request от имени текущего пользователя.
• Кнопка Merge осуществляет принятие merge request'а и непосредственно слияние ветвей, которое приводит к внесению изменений в master.
• Область где можно посмотреть коммиты, которые будут слиты, там же можно изменить сообщение merge commit'а.
• Возможности принять участие в обсуждении:
  
  • выразить своё отношение и оставить смайлик;
  • область добавления комментария.
• Кнопку Close merge request, которая позволяет закрыть merge request без принятия изменений в код master.

Для бесплатных подписок есть только возможность "совещательного" согласования merge request'а, в платных версиях есть возможность сделать согласование необходимым.

Если вы переключитесь на вкладку Changes, вы можете посмотреть, какие изменения в код планируется внести. Здесь же вы можете создать комментарий, который будет ссылаться на строку кода.

Кстати, merge requests также поддерживают метки, которые вы можете использовать чтобы было проще находить нужные.

К этому моменту работа конвейера уже должна завершиться и тесты завершены неуспешно. В нашем конкретном случае это потому что мы использовали window.alert который является чисто браузерным объектом и наши выполняемые в среде Node.js юнит-тесты не имеют к нему доступа.

В случае непрерывной поставки требуется очень хороший набор автоматических тестов потому что именно на них переложена почти вся, а в случае непрерывного развёртывания(Continuous Deployment) вся, ответственность за контроль качества. Поддержание такого набора тестов в актуальном состоянии главная технический вызов в реализации таких методологий.

! Исправим src/App.js, добавив проверку на то что код работает в браузере. Давайте поместим код, использующий window.alert внутрь блока кода, проверяющего что мы в браузере. Убедитесь что вы редактируете файл в ветке feature-cookies-consent.
Должно получиться примерно так

// ...other codefunction App() {  useEffect(() => {    if (typeof process === 'undefined' || process.release === undefined) {      alert('Consent to cookies and everything!');    }  }, []);   return (// ...remaining code

Добавьте "Ensure running in a browser" в качестве commit message. В качестве Target Branch должна быть установлена feature-cookies-consent.

! Давайте вернёмся в merge request Add the annoying popup и нажмём кнопку Merge и примем изменения в код. Оставьте чекбокс Delete source branch установленным.

При использовании GitLab Flow feature branches традиционно удаляют. Это позволяет избежать замусоривания системы уже неактуальными ветвями и создавать ветвь с тем же именем в случае отправки задачи на доработку.

! Откройте Repository -> Graph и обратите внимание на то что feature-cookies-consent теперь слита с master.
Затем откройте файл src/App.js в ветке master и заметьте что код уже содержит правки.

! Зайдите в задачу Провести несколько итераций GitLab Flow и в основной области нажмите стрелочку вниз рядом с кнопкой Create merge request. Укажите имя ветки, которую вы хотите создать чтобы базировать на ней новый merge request. feature-notifications-consent вполне подойдёт. Оставьте в качестве source branch master.

При создании merge request'а таким образом задача будет закрыта автоматически как только мы сольём код в основную ветвь.

Обратите внимание что автоматически сгенерированное название нашего merge request'а начинается с Draft:. Это означает что merge request помечен как черновик. Это полезно для авторов чтобы явно обозначить что работа пока не завершена и избежать слияния изменений as is в результате недопонимания. Этого же можно добиться и при помощи кнопки Mark as draft в верхней правой части основной области.

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

! Давайте для разнообразия внесём изменения в код чуть иначе. На странице merge request'а нажмите кнопку Open in Web IDE. Откроется чуть более удобный для работы с кодом интерфейс. Уже из него откройте файл src/App.js. Добавьте код

      Notification.requestPermission().then(function(result) {        alert(`You ${result} notifications`);      });

после ранее добавленной строчки

      alert('Consent to cookies and everything!');

! Нажмите кнопку Commit в левой нижней части. Вы увидите интерфейс коммита, укажите в качестве commit message "Add the notifications users want". Оставьте всё остальное по умолчанию и нажмите кнопку Commit.

! Перейдите в merge request, например, используя подменю в верхней правой части экрана рядом с меню логина.Нажмите кнопку Mark as ready в верхней правой части формы merge request'а. Нажмите кнопку Merge или Merge when pipeline succeeds в зависимости от того завершился ли уже конвейер.

! Откройте наш тестовый вебсайт и убедитесь что новые "фичи" работают, и наша страница ощущается как большинство современных сайтов в интернете.

! Если с сайтом всё хорошо, перетащите задачу Создать конвейер непрерывной поставки в стадию Closed на доске.

Итак, мы провели несколько полных циклов работы и теперь можем изучить метрики, которые GitLab собрал в процессе работы.

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

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

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

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

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

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

• Issue время которое уходит на то чтобы задачу "взять в работу" т.е. присвоить метку или добавить в Milestone.
• Plan время от последнего действия в предыдущем этапе до появления первого коммита в ветке, хоты бы один из коммитов которой связан с той же задачей. То есть "время, которое уходит чтобы начать коммитить".
• Code время существования ветки, связанной с той или иной задачей, которое уходит до появления merge request'a.
• Test время от начала до конца всех конвейеров данного проекта.
• Review время от создания merge request'а до его слияния или закрытия.
• Staging время от принятия merge request до развёртывания в продуктивную среду.

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

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

Analytics -> Repository показывает разные графики связанные с языками коммитов, показателями code coverage (если настроено), распределением коммитов во времени (месяц, дни недели, часы).

Analytics -> CI/CD показывает сводные данные по выполенным pipelines, в том числе график показывающий динамику изменения "успешности" выполнения pipelines.

Поздравляю!

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

Ссылки

1. GitLab product handbook
2. The DevOps Handbook
3. Pro Git Book

Мы говорим CI/CD и подразумеваем непрерывную интеграцию. Никто не имеет в виду (и не практикует) непрерывный деплоймент. Вообще никогда. О нем все забыли. Пора это изменить.

Поучительная история

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

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

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

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

Что подводит нас к разговору о CI/CD?

CI/CD (непрерывная интеграция и доставка, или деплоймент) это часть нашей жизни. Мы ходим на конференции по CI/CD, пишем статьи о CI/CD, ведем блоги о CI/CD, указываем CI/CD на странице LinkedIn. Никто даже не спорит, надо оно нам или нет. Мы все одинаково обожаем CI/CD. Так ведь?

Вот только мы говорим CI/CD и подразумеваем непрерывную интеграцию. Никто не имеет в виду (и не практикует) непрерывный деплоймент. О нем все забыли.

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

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

Что это вообще такое CI/CD?

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

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

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

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

Гибельный водоворот разработки

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

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

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

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

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

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

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

Каким должен быть интервал? В идеале 15 минут. Максимум час. Предсказуемость важна не меньше продолжительности, поэтому человек тут будет только мешать. Если сейчас вам требуется 15 дней, а не минут, не отчаивайтесь. Любые усилия по сокращению интервала обязательно окупятся. Любые!

Вижу, вы сомневаетесь. Моя команда, мол, такое не осилит, здесь вам не Facebook и не Google.

Вы идете сложным путем

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

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

Как это вообще можно сравнивать? Пока код еще свеж в памяти, мы четко видим проблему и ее решение.

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

В таком ритме разработчики обычно находят больше 80% всех багов сразу пока ничего еще не забылось и знаешь, на что смотреть. Если что-то пошло не так, можно тут же слепить еще один диф.

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

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

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

Задача номер 1 для технических руководителей в 2021 году

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

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

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

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

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

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

Не надо быть гением, чтобы раскрыть весь потенциал CI/CD. Честное слово. Надо просто приложить чуть больше усилий к тому, чтобы наладить этот процесс. Хорошие специалисты вырастают в хороших командах.

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

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

Сложно ли это? Еще как. Надеюсь, мне удалось вас убедить, что оно того стоит. Это изменит вашу жизнь. Это шаг к социотехническим системам будущего. Чем больше команд его сделают, тем лучше. А какой у вас план по CI/CD на 2021 год?

Узнать больше о CI/CD и получить практику создания пайплайнов можно на курсе Слёрма CI/CD на примере Gitlab CI.

Вы изучили команды Git но хотите представлять, как непрерывная интеграция (Continuous Integration, CI) происходит в реальности? Или может вы хотите оптимизировать свои ежедневные действия? Этот курс даст вам практические навыки непрерывной интеграции с использованием репозитория на GitHub. Данный курс не задуман как некий визард, который можно просто прокликать, напротив, вы будете совершать те же действия, что люди на самом деле делают на работе, тем же способом, которым они это делают. Я буду объяснять теорию по мере прохождения вами имеющих к ней отношение шагов.

Что мы будем делать?

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

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

Вы пройдёте такие стандартные для CI сценарии:

• Работа над фичей;
• Применение автотестов для обеспечения качества;
• Реализация приоритетной задачи;
• Разрешение конфликта при слиянии ветвей (merge conflict);
• Возникновение ошибки в продуктивной среде.

Что вы узнаете?

Вы сможете ответить на такие вопросы:

• Что такое непрерывная интеграция(CI)?
• Какие типы автотестов используются при CI, и в ответ на какие действия они запускаются?
• Что такое pull request и когда они нужны?
• Что такое разработка через тестирование (Test Driven Development, TDD) и как она соотносится с CI?
• Осуществлять слияние(merge) или применять изменения поверх(rebase)?
• Откатывать или чинить в следующей версии?

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

Что такое непрерывная интеграция?

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

Существуют разночтения по поводу этого термина

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

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

Непрерывная интеграция отличается от непрерывной поставки (Continuous Delivery, CD) тем, что не требует релиз-кандидата после каждого цикла интеграции.

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

1. Pull in the latest code. Create a branch from master. Start working.
2. Create commits on your new branch. Build and test locally. Pass? Go to the next step. Fail? Fix errors or tests and try again.
3. Push to your remote repository or remote branch.
4. Create a pull request. Discuss the changes, add more commits as discussion continues. Make tests pass on the feature branch.
5. Merge/rebase commits from master. Make tests pass on the merge result.
6. Deploy from the feature branch to production.
7. If everything is good in production for some period of time, merge changes to master.

Подготовка

Убедитесь в наличии нужного ПО

Чтобы пройти этот курс вам понадобится Node.js и Git-клиент.

Можете использовать любой Git-клиент, но я буду приводить команды только для командной строки.

Убедитесь, что у вас установлен Git-клиент, поддерживающий командную строку

Если у вас пока не установлен Git-клиент, поддерживающий командную строку, можете найти инструкции по установке здесь.

Подготовьте репозиторий

Вам потребуется создать личную копию(fork) репозитория-шаблона с кодом для курса на GitHub. Давайте договоримся называть эту личную копию репозиторием курса.

Сделали? Если вы не меняли настройки по умолчанию, ваш репозиторий курса скорее всего называется continuous-integration-team-scenarios-students, он находится в вашем аккаунте на GitHub, и URL выглядит так

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

Я буду называть этот адрес просто <URL репозитория>.

Угловые скобки как <тут> будут означать, что вы должны заменить такое выражение на соответствующее значение.

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

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

Вы всегда можете использовать способность GitHub отображать Markdown чтобы увидеть текущее состояние списка, который мы сочиняем, тут

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

Про ответы

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

Если вы чувствуете, что не понимаете что делать и не можете продолжать, можете подсмотреть в ветку solution, которая есть в вашем стартовом репозитории.
Пожалуйста, не осуществляйте слияние solution в master во время курса. Вы можете использовать эту ветку чтобы разобраться что делать, или чтобы сравнивать свой код с авторским, используя все возможности, которые даёт нам Git. Если вы совсем потерялись, можете полностью заменить свою ветку master на ветку solution и затем сбросить свою рабочую директорию до того шага курса, который вам нужен.

Используйте это только если вам это действительно нужно

Закоммитьте(commit) свой код

git add .git commit -m "Backing up my work"

Эти команды

• переименовывают master в master-backup;
• переименовывают solution в master;
• переключают(checkout) на новую ветку master и переписывают содержимое рабочей директории;
• создают ветку "solution" из "master" (которая раньше была "solution") на случай если вам в будущем понадобится ветка "solution".

git branch -m master master-backupgit branch -m solution mastergit checkout master -fgit branch solution

После этих действий вы можете использовать git log master чтобы выяснить, какой коммит вам нужен.
Вы можете сбросить свою рабочую директорию на этот коммит так:

git reset --hard <the SHA you need>

Если вы довольны результатом, в какой-то момент вам понадобится опубликовать вашу версий репозитория в удалённый репозиторий(remote). Не забудьте явно указать удалённую ветку когда будете это делать.

git push --force origin master

Пожалуйста обратите внимание, что мы используем git push --force. Вряд ли вы часто захотите так поступать, но у нас тут крайне специфичный сценарий с одним пользователем репозитория, который вдобавок, понимает, что он делает.

Starting working

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

Задание: обновите локальный репозиторий, создайте ветку из master, начните работать

1. Клонируйте репозиторий курса из <URL репозитория>.
2. Запустите npm install в каталоге репозитория курса; он нужен нам для установки Jest, который мы используем для запуска тестов.
3. Создайте ветку и назовите ее feature. Переключитесь на эту ветку.

4. Добавьте тестовый код в ci.test.js между комментариями с просьбой сделать это.

   
   

   it('1. pull latest code', () => {  expect(/.*pull.*/ig.test(fileContents)).toBe(true);});it('2. add commits', () => {  expect(/.*commit.*/ig.test(fileContents)).toBe(true);});it('3. push to the remote branch with the same name', () => {  expect(/.*push.*/ig.test(fileContents)).toBe(true);});it('4. create a pull request and continue working', () => {  expect(/.*pull\s+request.*/ig.test(fileContents)).toBe(true);});
   

   
   
5. Добавьте текст с первыми 4 шагами в файл ci.md.
   

   1. Pull in the latest code. Create a branch from `master`. Start working.    2. Create commits on your new branch. Build and test locally.  Pass? Go to the next step. Fail? Fix errors or tests and try again.  3. Push to your remote repository or remote branch.  4. Create a pull request. Discuss the changes, add more commits  as discussion continues. Make tests pass on the feature branch.  
   

   
   

   Команды

# Клонируйте репозиторий курсаgit clone <repository URL>cd <repository name># Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.npm install# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.git checkout -b feature# Отредактируйте ci.test.js как описано выше.# Отредактируйте ci.md как описано выше

Создавайте коммиты в новой ветке, осуществляйте сборку и тестирование локально

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

Типовые сценарии, когда тесты запускаются автоматически

• Локально:
  
  • Постоянно или в ответ на соответствующие изменения кода;
  • При сохранении (для интерпретируемых или JIT-компилируемых языков);
  • При сборке (когда требуется компиляция);
  • При коммите;
  • При публикации в общий репозиторий.

• На сервере сборки(build server) или в среде сборки:
  
  • Когда код публикуется в персональную ветку / репозиторий.
  • Тестируется код в этой ветке.
  • Тестируется потенциальный результат слияния (обычно с master).
  • В качестве этапа непрерывной интеграции/конвейера непрерывной поставки

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

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

Задание

Я предлагаю сначала запустить тесты вручную, используя команду npm test. После этого давайте добавим git hook для запуска наших тестов при коммите. Есть одна загвоздка: Git hooks не считаются частью репозитория и поэтому не могут быть клонированы из GitHub вместе с остальными материалами курса. Чтобы установить hook, вам нужно запустить install_hook.sh или скопировать файл repo/hooks/pre-commit в локальный каталог .git/hooks/.
При коммите вы увидите, что выполняются тесты, и они проверяют, присутствуют ли в списке определенные ключевые слова.

1. Запустите тесты вручную, выполнив команду npm test в папке репозитория вашего курса. Убедитесь, что тесты были выполнены.
2. Установите hook на коммит (pre-commit hook), запустив install_hook.sh.
3. Закоммитьте изменения в локальный репозиторий.
4. Убедитесь, что тесты выполняются перед коммитом.

Ваш репозиторий должен выглядеть так после выполнения этих действий.

Команды

# Установите pre-commit hook выполнив install_hook.sh.  # Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.git add ci.md ci.test.jsgit commit -m "Add first CI steps"# Убедитесь, что тесты запускаются перед коммитом.  

Опубликуйте код в удаленный репозиторий или удаленную ветку

Завершив работать локально, разработчики обычно делают свой код общедоступным, чтобы его можно было в конечном итоге интегрировать с общим. С помощью GitHub это обычно достигается публикацией работы либо в персональной копии репозитория(personal fork, форк), либо в личной ветке.

• При использовании форков разработчик клонирует удаленный общий репозиторий, создавая его личную удаленную копию, также известную как форк. После этого он клонирует этот личной репозиторий, чтобы работать с ним локально. Когда работа завершена и коммиты созданы, он помещает их в свой форк, где они доступны другим и могут быть интегрированы в общий репозиторий. Этот подход обычно используется в проектах с открытым исходным кодом на GitHub. Он также используется в моем расширенном курсе [Team Work and CI with Git] (http://devops.redpill.solutions/).
• Другой подход состоит в том, чтобы использовать только один удалённый репозиторий и считать только ветку master совместно используемого репозитория "защищенной". В этом сценарии отдельные разработчики публикуют свой код в ветки удаленного репозитория, чтобы другие могли этот код посмотреть, если все в порядке, объединить с master общего репозитория.

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

Давайте опубликуем наш код.

Задание

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

Команды

git push --set-upstream origin feature

Создайте pull request

Создайте pull request с названием Steps review. Установите feature как "head branch" и master как "base branch".

Убедитесь, что вы установили master в своем форке репозитория в качестве "base branch", я не буду отвечать на запросы на изменения в репозиторий с материалами курса.

На сленге GitHub "base branch" это ветка, на которой вы основываете свою работу, а "head branch" это ветка, содержащая предлагаемые изменения.

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

Pull request(PR)

Pull request(PR) это способ обсудить и задокументировать код, а также провести проверку(code review) кода. Pull request названы в честь общего способа интеграции отдельных изменений в общий код. Обычно человек клонирует удаленный официальный репозиторий проекта и работает над кодом локально. После этого он помещает код в свой личный удаленный репозиторий и просит ответственных за официальный репозиторий забрать(pull) его код в свои локальные репозитории, где они просматривают и, возможно, интегрируют(merge) его. Это понятие известно и под другими названиями, например, merge request.

На самом деле вам не обязательно использовать функцию pull request GitHub или аналогичных платформ. Команды разработчиков могут использовать другие способы связи, включая личное общение, голосовые звонки или электронную почту, но есть всё же ряд причин использовать такие pull requests в стиле обсуждения на форуме. Вот некоторые из них:

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

Обычно вы создаете pull request когда вам нужно что-то обсудить или получить обратную связь. Например, если вы работаете над функцией, которая может быть реализована несколькими способами, вы можете создать запрос на внесение изменений еще до написания первой строки кода, чтобы поделиться своими идеями и обсудить свои планы с соавторами. Если работа более проста, pull request открывается, когда что-то уже сделано, зафиксировано и может быть обсуждено. В некоторых сценариях вы можете открыть PR только из соображений контроля за качеством: чтобы запустить автоматические тесты или инициировать проверку кода. Что бы вы ни решили, не забывайте @упоминать людей, одобрение которых требуется в вашем pull request'е.

Обычно при создании PR вы делаете следующее.

• Указываете, что вы предлагаете изменить и где.
• Пишете описание, объясняющее цель изменений. Вы можете захотеть:
  
  • добавить что-нибудь важное, что не является очевидным из кода, или что-нибудь полезное для понимания контекста, например соответствующие #баги и номера коммитов;
  • @упомянуть всех, с кем хотите начать работать вместе, или вы можете @упомянуть их в комментариях позже;
  • попросить коллег помочь с чем-то или проверить что-либо конкретное.

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

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

Добавьте замечание о произвольности списка шагов CI

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

Задание: создание pull request для данного примечения

1. Переключитесь на ветку master.
2. Создайте ветку с именем bugfix.
3. Добавьте текст примечания в конец файла ci.md.
   

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  when code is deployed straight from feature branches. This list is just an interpretation  that I use in my [DevOps courses](http://personeltest.ru/away/redpill.solutions).  The official tutorial is [here](http://personeltest.ru/aways/guides.github.com/introduction/flow/).
   

4. Закоммитьте изменения.
5. Опубликуйте ветку bugfix в удалённый репозиторий.
6. Создайте pull request с именем Adding a remark с головной веткой bugfix и базовой веткойmaster.

Убедитесь, что вы установили master в своем форке репозитория в качестве "base branch", я не буду отвечать на запросы на изменения в репозиторий с материалами курса.

Вот как должен выглядеть ваш репозиторий.

Команды

# Переключитесь на ветку master. Создайте ветку bugfix.git checkout master# Создайте ветку bugfix-remark.git checkout -b bugfix# Добавьте текст примечания внизу ci.md.# Закоммитьте измененияgit add ci.mdgit commit -m "Add a remark about the list being opinionated"# Опубликуйте ветку bugfix в удалённый репозиторий.git push --set-upstream origin bugfix# Создайте pull request при помощи интерфейса GitHub как описано выше

Утвердите pull request "Adding a remark"

Задание

1. Создайте pull request.
2. Нажмите "Merge pull request".
3. Нажмите "Confirm merge".
4. Нажмите "Delete branch", она нам больше не нужна.

Это диаграмма коммитов после слияния.

Продолжайте работать и добавлять тесты

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

При непрерывной интеграции обычно применяется некоторое тестовое покрытие. Требования к покрытию тестами различаются и обычно находятся в документе с названием вроде "руководство для авторов"(contribution guidelines). Мы поступим просто и добавим по тесту для каждой строки в нашем контрольном списке.

При выполнении заданий сначала попробуйте закоммитить тесты. Если вы правильно установили pre-commit hook ранее, только что добавленный тест будет запущен, не будет пройден, и ничего не будет закоммичено. Обратите внимание: так мы узнаем, что наши тесты действительно что-то проверяют. Любопытно, что если бы мы начали с кода до тестов, прохождение тестов могло означать либо то, что код работает так, как ожидалось, либо что тесты на самом деле ничего не проверяют. Кроме того, если бы мы не написали тесты в первую очередь, мы могли бы вовсе их забыть, поскольку ничто не напоминало бы нам об этом.

Разработка через тестирование (TDD)

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

1. Добавьте тест.
2. Запустите все тесты и убедитесь, что новый тест не проходит успешно.
3. Напишите код.
4. Запустите тесты, убедитесь, что все тесты проходят успешно.
5. Проведите рефакторинг кода.
6. Повторите.

Поскольку результаты работы тестов, которые не были пройдены успешно, обычно отображается красным, а выполненные успешно зеленым, цикл также известен как "красный-зеленый-рефакторинг"(red-green-refactor).

Задание

Сначала попробуйте закоммитить тесты и дать им завершиться неуспешно, затем добавьте и закоммитьте сам текст списка шагов CI. Вы увидите, что тесты проходят ("зеленые").
Затем опубликуйте новый код в удалённый репозиторий и посмотрите, как выполняются тесты в интерфейсе GitHub в нижней части обсуждения запроса на внесение изменений, и обновляется статус PR.

1. Переключитесь на ветку feature.

2. Добавьте эти тесты в ci.test.js после последнего вызова it (...);.

   
   

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {  expect(/.*merge.*commits.*tests\s+pass.*/ig.test(fileContents)).toBe(true);});it('6. Deploy from the feature branch to production.', () => {  expect(/.*Deploy.*to\s+production.*/ig.test(fileContents)).toBe(true);});it('7. If everything is good in production for some period of time, merge changes to master.', () => {  expect(/.*merge.*to\s+master.*/ig.test(fileContents)).toBe(true);});
   

   
   
3. Попробуйте закоммитить тесты. Если pre-commit hook установлен, попытка коммита завершится ошибкой.
4. После добавьте этот текст в ci.md.
   

   5. Merge/rebase commits from master. Make tests pass on the merge result.  6. Deploy from the feature branch with a sneaky bug to production.7. If everything is good in production for some period of time, merge changes to master. 
   

5. Внесите и закоммитьте изменения локально.
6. Опубликуйте изменения в ветку feature.

Теперь у вас должно получиться что-то вроде этого

Команды

# Переключительна ветку featuregit checkout feature# Добавить тесты в ci.test.js как описано выше# Добавьте в индекс ci.test.js чтобы позже закоммититьgit add ci.test.js# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.git commit# Теперь добавьте текст в ci.md как описано выше# Внесите изменения и закоммитьте ихgit add ci.mdgit commit -m "Add the remaining CI steps"# Опубликуйте изменения в ветку featuregit push

Конфликт слияния

Перейдите к запросу на внесение изменений Steps review.

Несмотря на то, что мы не сделали ничего плохого, и тесты для нашего кода прошли успешно, мы все еще не можем осуществить слияние ветки feature и master. Это потому, что другая ветка bugfix была объединена с master пока мы работали над этим PR.
Это создает ситуацию, когда удаленная ветка master имеет более новую версию, чем та, на которой мы основывали ветку feature. Из-за этого мы не можем просто перемотать HEAD master до конца ветки feature. В этой ситуации нам нужно либо осуществить слияние(merge), либо применить коммиты feature поверх(rebase) master. GitHub на самом деле может выполнять автоматическое слияние, если нет конфликтов. Увы, в нашей ситуации обе ветки имеют конкурирующие изменения в файле ci.md. Эта ситуация известна как конфликт при слиянии(merge conflict), и нам нужно разрешить ее вручную.

Merge или rebase

Merge

• Создает дополнительный коммит слияния(merge commit) и сохраняет историю работы.
  
  • Сохраняет исходные коммиты веток с исходными отметками времени и авторами.
  • Сохраняет SHA коммитов и ссылки на них в обсуждениях запросов на изменения.
• Требует однократного разрешения конфликтов.
• Делает историю нелинейной.
  
  • Историю может быть трудно читать из-за большого количества веток (напоминает кабель IDE).
  • Усложняет автоматическую отладку, например, делает git bisect менее полезным он только найдет коммит слияния.

Rebase

• Воспроизводит коммиты из текущей ветки поверх базовой один за другим.
  
  • Формируются новые коммиты с новыми SHA, в результате чего коммиты в GitHub соотносятся с исходными pull requests, но не с соответствующими комментариями.
  • Коммиты могут быть рекомбинированы и изменены в процессе или даже объединены в один.
• Может потребоваться разрешить несколько конфликтов.
• Позволяет поддерживать линейную историю.
  
  • Историю может быть проще читать, если только она не является слишком длинной без разумных на то причин.
  • Автоматическая отладка и устранение неполадок несколько проще: делает возможным git bisect, может сделать автоматические откаты более чёткими и предсказуемыми.
• Требуется публикации ветви с перенесёнными коммитами с флагом --force при использовании с запросами на внесение изменений.

Обычно команды соглашаются всегда использовать одну и ту же стратегию, когда им нужно объединять изменения. Это может быть "чистое" слияние или "чистый" применение коммитов поверх или что-то промежуточное, например, выполнение применение коммитов поверх интерактивном режиме(git rebase -i) локально для веток, не опубликованных в общем репозитории, но слияние(merge) для "общедоступных" веток.

Здесь мы будем использовать слияние.

Задание

1. Убедитесь, что код в локальной ветке master обновлён из удалённого репозитория.
2. Переключитесь на ветку feature.
3. Инициируйте слияние с веткой master. Будет сообщено о конфликте слияния, связанном с конкурирующими изменениями в ci.md.
4. Разрешите конфликт так, чтобы в тексте остался и наш список шагов CI, и замечание о нем.
5. Опубликуйте коммит слияния в удаленную ветку feature.
6. Проверьте статус pull request'а в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

Команды

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.git checkout mastergit pull# Переключитесь на ветку featuregit checkout feature# Инициируйте слияние с веткой master git merge master# A merge conflict related to concurrent changes to ci.md will be reported# => Auto-merging ci.md#    CONFLICT (content): Merge conflict in ci.md#    Automatic merge failed; fix conflicts and then commit the result.# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.# отредактируйте ci.md чтоб он не содержал маркеров конфликта слиянияgit add ci.mdgit merge --continue# при коммите можете оставить сообщение по умолчанию# Опубликуйте коммит слияния в удаленную ветку feature.git push# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

Отличная работа!

Вы закончили работу со списком, и теперь вам нужно утвердить pull request в master.

Задание: Утвердите pull request "Steps review"

1. Откройте pull request.
2. Нажмите "Merge pull request".
3. Нажмите "Confirm merge".
4. Нажмите "Delete branch", так как она нам больше не нужна.

Это ваш репозиторий в данный момент

Ошибка на продуктиве

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

В подобном сценарии нам нужно позаботиться о:

• том, что развёрнуто на продуктиве;
• коде в ветке master с ошибкой, с которого разработчики могут начинать новую работу.

Откатывать или исправлять в следующей версии?

"Откатывание"(rolling back) это развертывание заведомо исправной более ранней версии в продуктивную среду и отмена(revert) коммитов, содержащих ошибку. "Исправление в следующей версии"(fixing forward) это добавление исправления в master и развертывание новой версии как можно скорее. Поскольку API и схемы баз данных меняются по мере развертывания кода в производственной среде, при непрерывной поставке и наличии хорошего покрытия тестами, откатывание, как правило, намного сложнее и рискованнее, чем исправление в следующей версии.

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

• исправить ошибку на продуктиве как можно скорее;
• сделать код в master сразу пригодным для начала новой работы.

Задание

1. Переключитесь на ветку master локально.
2. Обновите локальный репозиторий из удалённого репозитория.
3. Отмените коммит слияния PR Steps review в master.
4. Опубликовать изменения в удалённый репозиторий.

Это история репозитория с отмененным коммитом слияния

Команды

# Переключитесь на ветку master.git checkout master# Обновите локальный репозиторий из удалённого репозитория.git pull# Отмените коммит слияния PR Steps review в master.# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставитьgit show HEAD# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первымgit revert HEAD -m 1# можете не менять сообщения коммитов# Опубликуйте изменения в удалённый репозиторийgit push

Самопроверка

Убедитесь, что ci.md больше не содержит текста "sneaky bug" после отмены коммита слияния.

Исправить список шагов CI и вернуть его в master

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

Мы можем подойти к задаче по-разному:

• отменить(revert) коммит, которая отменяет слияние feature с master;
• перенести коммиты из бывшей feature.

Разные команды разработчиков в данном случае используют разные подходы, мы же перенесём полезные коммиты в отдельную ветку и создадим отдельный pull request для этой новой ветки.

Задание

1. Создайте ветку под названием feature-fix и переключитесь на нее.

2. Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.

   
   

   

   
   

3. Добавьте регрессионный тест в ci.test.js:

   
   

   it('does not contain the sneaky bug', () => {expect( /.*sneaky\s+bug.*/gi.test(fileContents)).toBe(false);});
   

   
   
4. Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.
5. Удалите текст " with a sneaky bug" в ci.md.
6. Добавьте в индекс изменения тестов и изменения в списке шагов и закоммитьте их.
7. Опубликуйте ветку в удалённый репозиторий.

У вас в результате должно получиться что-то похожее

Команды

# Создайте ветку под названием feature-fix и переключитесь на нее.git checkout -b feature-fix# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.# используйте историю чтобы узнать хэши коммитов:# - предшествующего коммиту с первой частью списка: C0# - добавляющего последние элементы списка: C2git log --oneline --graphgit cherry-pick C0..C2# разрешите конфликты слияния# - отредактируйте ci.md и/или ci.test.js# - добавьте файлы в индекс# - выполните "git cherry-pick --continue", можете не менять сообщение коммита# Добавьте регрессионный тест в ci.test.js# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.# Удалите текст " with a sneaky bug" в ci.md.# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.git add ci.md ci.test.jsgit commit -m "Fix the bug in steps list"# Опубликуйте ветку в удалённый репозиторий.git push --set-upstream origin feature-fix

Создайте pull request.

Создайте pull request с названием Fixing the feature. Установите feature-fix как "head branch", а master как "base branch".
Пожалуйста, подождите, пока завершатся тесты. Вы можете увидеть статус тестов в нижней части обсуждения PR.

Убедитесь, что вы установили master в своем форке репозитория в качестве "base branch", я не буду отвечать на запросы на изменения в репозиторий с материалами курса.

Утвердите pull request "Fixing the feature"

Спасибо за исправление! Пожалуйста, утвердите изменения в master из pull request.

Задание

1. Нажмите "Merge pull request".
2. Нажмите "Confirm merge".
3. Нажмите "Delete branch", так как она нам больше не нужна.

Это то, что у вас должно быть в данный момент

Поздравляю!

Вы выполнили все действия, которые люди обычно совершают в процессе непрерывной интеграции.

Если вы заметили какие-либо проблемы с курсом или знаете как его улучшить, создайте issue в репозитории с материалами курса. У этого курса также есть интерактивная версия использующая GitHub Learning Lab в качестве платформы.

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

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

Что такое непрерывная локализация?

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

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

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

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

Непрерывная локализация даёт разработчикам преимущества

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

Как внедрить непрерывную локализацию в процессы компании?

Вот несколько советов.

1. Используйте платформы автоматизации

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

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

Пример из нашего опыта партнёрство Alconost и Crowdin.

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

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

2. Начните с популярных языков

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

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

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

Опыт приложения inDriver

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

По мере роста популярности приложения команде inDriver понадобилась помощь с локализацией, и компания обратилась в Alconost. Приложение inDriver нужно было не только перевести на популярные языки (например, на французский), но и локализовать для индонезийского и индийского рынков. При этом понадобился перевод на некоторые редкие диалекты, чтобы сервис пользовался высоким уровнем доверия среди местных пользователей.

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

3. Соберите команду по локализации

Это следующий этап организации процесса непрерывной локализации. В команду обычно входят:

• Инженер по локализации: отвечает за построение и организацию рабочих процессов.
• Менеджер проекта: следит за работами по проекту и сроками.
• Менеджер по качеству: отвечает за качество конечного локализованного продукта.
• Переводчики: занимаются непосредственно локализацией контента.

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

4. Задействуйте пользователей

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

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

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

Заключение

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

Нужна помощь с локализацией / переводом? Мы в Alconost всегда рады помочь!

О нас

Alconost профессионально занимается локализацией игр, приложений и сайтов на более 70 языков. Лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджмент проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем видеоролики.
Подробнее

Добрый день, коллеги! Позвольте представиться меня зовут Павел Бацев, я администратор сервисов в ГК Спортмастер. В системном администрирование 8 лет, второй год занимаюсь изучением и внедрением devops-практик.

Сегодня я предлагаю рассмотреть вам кейс, который, прежде всего, будет интересен администраторам и инженерам с парком windows-хостов и монолитными системами.

Под катом: некоторые особенности работы конвейера доставки, работающего с использованием windows-агентов bamboo; проблемы, возникающие при использовании dsc и jea-сессий powershell в домене с устаревшим уровнем леса, и варианты их решения; способ внедрения автоматического ui-тестирования без задействования профессиональных тестировщиков.

Итак, рассмотрим, исходные данные:

Имеем бизнес-критичную информационную систему, которая интегрирована с системой внутреннего документооборота, системой заявок в Службу горячей линии, 1С.

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

Система, о которой идет речь, имеет классическую монолитную архитектуру и состоит из:

• Базы данных MS SQL;
• Веб-сервера IIS;
• Веб-сервиса IIS;
• Шедуллера регламентных заданий Служба Windows;
• Кеша Redis, как служба Windows.

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

Исходя из рутинных задач были определены операции, которые требуют автоматизации и выполнение в рамках единого конвейера, а также учтён задел на последующие развитие:

• Доставка сборок (сформированных артефактов) на целевые хосты веб-серверов;
• Кастомизация сборок правкой файлов контента, параметров верстки, адресов сторонних плагинов и прочее.
• Выполнение скриптов миграций утилитой (набором bat/ps-скриптов) от разработчика, находящейся в теле сборки;
• Организация верной последовательности запуска системы;
• Лёгкий откат при возникновении неполадок конвейера и ошибках кода.
• Масштабируемость выполнения (при росте агентов bamboo, росте количества целевых контуров/хостов и т.п.) и унификация для различных контуров (dev, test, stage, prod);
• Использование вычислительных мощностей агентов bamboo;
• Вывод полного и читабельного лога выполнения всех шагов в ui bamboo;
• Организация возможности выполнения конвейера и первичной диагностики возникающих проблем командой аналитики, а не техническим экспертом или т.п.
• Реализация системы оповещения о результатах выполнения конвейера в удобный бизнесу инструмент: выбор пал на канал telegram (простейшая реализация chatops).

В нашей компании реализованы различные инструменты, позволяющие внедрять практики devops. На момент моего вступления в должность администратора сервисов наиболее развитым и способным покрыть поставленные задачи был стек от Atlassian, поэтому реализацию конвейера было решено выполнять, используя связку jira+bitbucket+bamboo.

Так как обслуживаемая система использует ОС Windows Server, а имеющийся на тот момент пул bamboo-агентов был на *nix, возникла идея проверки работы кроссплатформенного взаимодействия. Всё было хорошо, powershell core, установленный на *nix-агенты, работал исправно, но при тестировании сетевого взаимодействия выяснилась проблема не отрабатывали второй тап аутентификации между windows-хостами.

Какие варианты решения были рассмотрены

Попробовали мы вот что.

• установка библиотеки Kerberos и работа по аналогии с Ansible for Windows;
• использование Python PowerShell Remoting Protocol Client library и зависимых с ним пакетов;
• использование windows агентов bamboo.

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

Не обошлось без сложностей и при реализации конвейера доставки изменений на базе windows агентов bamboo, куда же без проблем. Собственно, вот они:

• текущий лес ad не поддерживает групповые управляемые учетные записи служб (gMSA);
• при использовании встроенного плагина bamboo по обработке скриптов Script и хранении скриптов в СКВ, при получении ошибок powershell встроенные интерпретатор bamboo не воспринимал их и завершал задачи\задания\шаги\планы, как удачные;
• сторонний плагин Parse Log Task для простейшего парсинга ошибок по заданным паттернам было невозможно добавить в задачи Deployment Projects.

Реализованный конвейер

Остановимся на общей концепции, инструментах и некоторых особенностях.

Система контроля версий

В качестве СКВ используется bitbucket, но так как используется ПО с закрытым исходным кодом, то в СКВ хранится только обвес (скрипты и конфиги) для нормальной работы конвейера. Хранение скриптов конвейера организовано в рамках одного репозитория, разделение контуров\типа конвейера идёт по бранчам. Структура папок для всех бранчей унифицирована.

CI/CD

Реализация всех процессов CI/CD сведена в выполнение билд-плана bamboo по причинам, выявленным в процессе разработки концепта, и наличия некоторых недостатков инструментария от Atlassian.



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

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

Да, отмечу, что при реализации всех шагов конвейера используется инструментарий powershell. В частности dsc и jea. А раз была проблема с использованием gMSA, то мы разработали концепцию с задействованием временных шар, срок жизни которых ограничен временем выполнения задания конвейера. Отсюда появляются задачи с характерным признаком TFP и DelShare:

• создание временной области на текущем агенте:
• удаление временной области на текущем агенте.

В итоге вроде бы простейшее задание разбивается на семь задач:

1. получение кода скриптов на агент bamboo;
2. создание временной области, для хранения dsc;
3. парсер результата задачи создания временной области;
4. выполнение основной смысловой задачи шага;
5. парсер результата выполнение основной задачи;
6. удаление временной области;
7. парсер результата задачи удаление временной области.

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





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

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

Также реализовали конвейеры, покрывающие другие типовые задачи: обновление сущностей БД, используя утилиту собственной разработки подрядчика или утилиту от redgate; автоматическое ui тестирование системы; обновление\добавление кастомного контента js\css; перезапуск системы непродуктивного контура; оповещения в telegram.

Написали инструкции для группы аналитиков и провели обучающие встречи по использованию инструментов CI/CD.

А ещё разработали концепт и протестировали выполнение конвейеров по переходам бизнес-процесса в jira\отложенному заданию (не востребовано, т.к. заказчик пожелал использовать ui bamboo).

Ближайшие планы

• перенос хранения сборок с сетевой шары в Artifactory;
• после обновления леса ad внедрение gMSA;
• написание своего плагина bamboo для оповещений в telegram;
• написание своего плагина bamboo для парсинга результатов выполнения ps-скриптов из файла.

Автотестирование без профессиональных тестировщиков

Теперь же про успешно реализованный кейс по разработке и внедрению UI-автотестов с минимальными трудозатратами и квалификацией по инструментарию.

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

В качестве инструментария мы взяли:

• selenium ide как доступная и удобная платформа для формирования скелета автотеста с возможностью импорта в различные языки программирования;
• selenium webdriver+node js+mocha как связка кроссплатформенная инструментов, подходящая к текущей конфигурации и набору установленных плагинов в bamboo;
• windows-агенты bamboo как раннеры тестов;
• allure как визуализатор результатов для бизнеса, удобный и простой в понимании;
• канал telegram как простейшая реализация chatops.

В selenium ide были записаны скелеты автотестов по сценариям от бизнеса.



Сценарии были импортированы в js и доработаны для выполнения в рамках выбранного инструментария.

Полученные конечные скрипты для UI-автотестирования были загружены в СКВ и разбиты по контурам.



После успешного завершения конвейер релиза, в зависимости от контура, запускает конвейер UI-тестирования.

По завершении формируется артефакт с детальным логом выполнения.


Все тесты завершены успешно


Все или часть тестов завершены неудачно

Плюс в telegram-канал приходит информация о результате, с детальным логом результатов.


Все тесты завершены успешно


Все или часть тестов завершены неудачно

Затем проведена передача знаний команде аналитиков, которая на основе сформированных скелетов и завершенных скриптов автотестирования самостоятельно выполняет доработку\разработку.

Это дает возможность:

• исключить лишние шаги по постановке/проверке выполнения заданий между командами администрирования и аналитики;
• увеличить вовлечённость команд в общий процесс внедрения devops-практик;
• де-факто организовать прообраз продуктовой команды;
• ускорить реализацию заданий от бизнеса.

Если вы сталкивались с подобным и используете windows-монолит, поделитесь, пожалуйста, своим опытом доставки изменений.

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

В большинстве случаев требуется типовая задача: "сгенерировать YAML и положить его в Kubernetes". Собственно, с чем Argo CD замечательно и справляется.

Argo CD позволяет подключить Git-репозиторий и синкать его состояние в Kubernetes. По умолчанию есть поддержка нескольких видов приложений: Kustomize, Helm чарты, Ksonnet, голый Jsonnet или просто директории с YAML/JSON манифестами.

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

В первую очередь интересует возможность добавления поддержки qbec и git-crypt, которые с полна были рассмотренны в предыдущей статье.

---

Прежде чем приступить к конфигурации, нужно сначала разобраться с тем как именно Argo CD работает.

Для каждого добавленного приложения он имеет две фазы:

• init начальная подготовка перед деплоем, здесь может быть всё что угодно: скачивание зависимостей, распаковка секретов и другое.
• generate выполнение непосредственно команды генерации манифестов, вывод должен быть валидным YAML stream, это именно то, что будет применено в кластер.

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

Со своей стороны Argo умеет нативно обрабатывать Helm-хуки, что позволяет не нарушать логики применения релизов.

---

QBEC

Qbec позволяет удобно описывать приложения с помощью jsonnet, а кроме того имеет возможность рендерить Helm-чарты, а так как Argo CD умеет нормально обрабатывать Helm-хуки, то использование этой возможности с Argo CD позволяет добиться ещё более корректных результатов.

Для того чтобы добавить поддержку qbec в argocd нужно две вещи:

• в конфиге Argo CD дожен быть определен ваш custom plugin и команды для генерации манифестов.
• нужные бинарники должны быть доступны в образе argocd-repo-server.

Первая задача решается довольно просто:

# cm.yamldata:  configManagementPlugins: |    - name: qbec      generate:        command: [sh, -xc]        args: ['qbec show "$ENVIRONMENT" -S --force:k8s-namespace "$ARGOCD_APP_NAMESPACE"']

(команда init не используется)

$ kubectl -n argocd patch cm/argocd-cm -p "$(cat cm.yaml)"

Для добавления бинарников предлагается собрать новый образ, или использовать трюк с init-контейнером:

# deploy.yamlspec:  template:    spec:      # 1. Define an emptyDir volume which will hold the custom binaries      volumes:      - name: custom-tools        emptyDir: {}      # 2. Use an init container to download/copy custom binaries into the emptyDir      initContainers:      - name: download-tools        image: alpine:3.12        command: [sh, -c]        args:        - wget -qO- https://github.com/splunk/qbec/releases/download/v0.12.2/qbec-linux-amd64.tar.gz | tar -xvzf - -C /custom-tools/        volumeMounts:        - mountPath: /custom-tools          name: custom-tools      # 3. Volume mount the custom binary to the bin directory (overriding the existing version)      containers:      - name: argocd-repo-server        volumeMounts:        - mountPath: /usr/local/bin/qbec          name: custom-tools          subPath: qbec        - mountPath: /usr/local/bin/jsonnet-qbec          name: custom-tools          subPath: jsonnet-qbec

$ kubectl -n argocd patch deploy/argocd-repo-server -p "$(cat deploy.yaml)"

Теперь посмотрим как будет выглядеть манифест нашего приложения:

apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata:  name: qbec-app  namespace: argocdspec:  destination:     namespace: default    server: https://kubernetes.default.svc  project: default  source:     path: qbec-app    plugin:       env:         - name: ENVIRONMENT          value: default      name: qbec    repoURL: https://github.com/kvaps/argocd-play  syncPolicy:     automated:       prune: true

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

применим и посмотрим что у нас получилось:

приложение задеплоилось, отлично!

---

git-crypt

Git-crypt позволяет настроить прозрачное шифрование репозитория. Это простой и безопасный способ хранить конфиденциальные данные прямо в git.

С имплементацией git-crypt оказалось сложнее.

Теоретически мы могли бы выполнять git-crypt unlock на init-стадии нашего custom-плагина, но это не очень удобно, так как не позволило бы использовать нативные методы деплоя. Например в случае Helm и Jsonnet, мы теряем гибкий GUI-интерфейс который позволяет упростить настройку приложения (values-файлы и прочее).

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

Так как на данный момент Argo CD не предоставляет возможности для описания каких-либо хуков для синхронизации репозитория, пришлось обойти это ограничение хитрым шелл скриптом-обёрткой, который заменяет собой команду git:

#!/bin/sh$(dirname $0)/git.bin "$@"ec=$?[ "$1" = fetch ] && [ -d .git-crypt ] || exit $ecGNUPGHOME=/app/config/gpg/keys git-crypt unlock 2>/dev/nullexit $ec

Argo CD выполняет git fetch каждый раз перед операцией деплоя. Именно на эту команду мы и повесим выполнение git-crypt unlock для разблокировки репозитория.

для тестов можете использовать мой docker-образ в котором уже есть всё необходимое:

$ kubectl -n argocd set image deploy/argocd-repo-server argocd-repo-server=docker.io/kvaps/argocd-git-crypt:v1.7.3

Теперь нам нужно подумать о том, как Argo будет расшифровывать наши репозитории. А именно сгенерировать gpg-ключ для него:

$ kubectl exec -ti deploy/argocd-repo-server -- bash$ printf "%s\n" \    "%no-protection" \    "Key-Type: default" \    "Subkey-Type: default" \    "Name-Real: YOUR NAME" \    "Name-Email: YOUR EMAIL@example.com" \    "Expire-Date: 0" \    > genkey-batch $ gpg --batch --gen-key genkey-batchgpg: WARNING: unsafe ownership on homedir '/home/argocd/.gnupg'gpg: keybox '/home/argocd/.gnupg/pubring.kbx' createdgpg: /home/argocd/.gnupg/trustdb.gpg: trustdb createdgpg: key 8CB8B24F50B4797D marked as ultimately trustedgpg: directory '/home/argocd/.gnupg/openpgp-revocs.d' createdgpg: revocation certificate stored as '/home/argocd/.gnupg/openpgp-revocs.d/9A1FF8CAA917CE876E2562FC8CB8B24F50B4797D.rev'

Сохраним имя ключа 8CB8B24F50B4797D для дальнейших шагов. Экспортируем сам ключ:

$ gpg --list-keysgpg: WARNING: unsafe ownership on homedir '/home/argocd/.gnupg'/home/argocd/.gnupg/pubring.kbx-------------------------------pub   rsa3072 2020-09-04 [SC]      9A1FF8CAA917CE876E2562FC8CB8B24F50B4797Duid           [ultimate] YOUR NAME <YOUR EMAIL@example.com>sub   rsa3072 2020-09-04 [E]$ gpg --armor --export-secret-keys 8CB8B24F50B4797D

И добавим его в виде отдельного секрета:

# argocd-gpg-keys-secret.yamlapiVersion: v1kind: Secretmetadata:  name: argocd-gpg-keys-secret  namespace: argocdstringData:  8CB8B24F50B4797D: |-    -----BEGIN PGP PRIVATE KEY BLOCK-----    lQVYBF9Q8KUBDACuS4p0ctXoakPLqE99YLmdixfF/QIvXVIG5uBXClWhWMuo+D0c    ZfeyC5GvH7XPUKz1cLMqL6o/u9oHJVUmrvN/g2Mnm365nTGw1M56AfATS9IBp0HH    O/fbfiH6aMWmPrW8XIA0icoOAdP+bPcBqM4HRo4ssbRS9y/i    =yj11    -----END PGP PRIVATE KEY BLOCK-----

$ kubectl apply -f argocd-gpg-keys-secret.yaml

Единственное что нам осталось, это пробросить его в контейнер argocd-repo-server, для этого отредактируем deployment:

$ kubectl -n argocd edit deploy/argocd-repo-server

И заменим существующий gpg-keys volume на projected, где и укажем наш секрет:

   spec:     template:       spec:         volumes:         - name: gpg-keys           projected:             defaultMode: 420             sources:             - secret:                 name: argocd-gpg-keys-secret             - configMap:                 name: argocd-gpg-keys-cm

Argo CD автоматически подгружает gpg-ключи из этой директории при старте контейнера, таким образом он загрузит и наш приватный ключ.

проверим:

$ kubectl -n argocd exec -ti deploy/argocd-repo-server -- bash$ GNUPGHOME=/app/config/gpg/keys gpg --list-secret-keysgpg: WARNING: unsafe ownership on homedir '/app/config/gpg/keys'/app/config/gpg/keys/pubring.kbx--------------------------------sec   rsa2048 2020-09-05 [SC] [expires: 2021-03-04]      ED6285A3B1A50B6F1D9C955E5E8B1B16D47FFC28uid           [ultimate] Anon Ymous (ArgoCD key signing key) <noreply@argoproj.io>sec   rsa3072 2020-09-03 [SC]      9A1FF8CAA917CE876E2562FC8CB8B24F50B4797Duid           [ultimate] YOUR NAME <YOUR EMAIL@example.com>ssb   rsa3072 2020-09-03 [E]

Отлично, ключ загружен! Теперь нам достаточно добавить Argo CD в наш репозиторий в качестве коллаборатора и он сможет автоматически расшифровывать его на лету.

Импортируем ключ на локальный компьютер:

$ gpg --armor --export-secret 8CB8B24F50B4797D > 8CB8B24F50B4797D.pem$ gpg --import 8CB8B24F50B4797D.pem

Настроим уровень доверия:

$ gpg --edit-key 8CB8B24F50B4797Dtrust5

Добавим argo в качестве коллаборатора в наш проект:

$ git-crypt add-gpg-user 8CB8B24F50B4797D

---

Ссылки по теме:

• GitHub: репозиторий с модифицированным образом
• Argo CD: Custom Tooling
• Argo CD: Config Management Plugins
• GitHub Gist: генерация gpg ключей без пароля в неинтерактивном режиме

В статье рассмотрена проблематика очистки образов, которые накапливаются в реестрах контейнеров (Docker Registry и его аналогах) в реалиях современных CI/CD-пайплайнов для cloud native-приложений, доставляемых в Kubernetes. Приведены основные критерии актуальности образов и вытекающие из них сложности при автоматизации очистки, сохранения места и удовлетворения потребностям команд. Наконец, на примере конкретного Open Source-проекта мы расскажем, как эти сложности можно преодолеть.

Введение

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

1. использовать фиксированное количество тегов для образов;
2. каким-либо образом очищать образы.

Первое ограничение иногда допустимо для небольших команд. Если разработчикам хватает постоянных тегов (latest, main, test, boris и т.п.), реестр не будет раздуваться в размерах и долгое время можно вообще не думать об очистке. Ведь все неактуальные образы перетираются, а для очистки просто не остаётся работы (всё делается штатным сборщиком мусора).

Тем не менее, такой подход сильно ограничивает разработку и редко применим к CI/CD современных проектов. Неотъемлемой частью разработки стала автоматизация, которая позволяет гораздо быстрее тестировать, развертывать и доставлять новый функционал пользователям. Например, у нас во всех проектах при каждом коммите автоматически создается CI-пайплайн. В нём собирается образ, тестируется, выкатывается в различные Kubernetes-контуры для отладки и оставшихся проверок, а если всё хорошо изменения доходят до конечного пользователя. И это давно не rocket science, а обыденность для многих скорее всего и для вас, раз вы читаете данную статью.

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

Но как вообще определить, актуален ли образ?

Критерии актуальности образа

В подавляющем большинстве случаев основные критерии будут таковы:

1. Первый (самый очевидный и самый критичный из всех) это образы, которые в настоящий момент используются в Kubernetes. Удаление этих образов может привести к серьезным издержкам в связи с простоем production (например, образы могут потребоваться при репликации) или свести на нет усилия команды, которая занимается отладкой на каком-либо из контуров. (По этой причине мы даже сделали специальный Prometheus exporter, отслеживающий отсутствие таких образов в любом Kubernetes-кластере.)

2. Второй (менее очевиден, но тоже очень важен и снова относится к эксплуатации) образы, которые требуются для отката в случае выявления серьёзных проблем в текущей версии. Например, в случае с Helm это образы, которые используются в сохраненных версиях релиза. (К слову, по умолчанию в Helm лимит в 256 ревизий, но вряд ли у кого-то реально есть потребность в сохранении такого большого количества версий?..) Ведь мы, в частности, для того и храним версии, чтобы можно было их потом использовать, т.е. откатываться на них в случае необходимости.

3. Третий потребности разработчиков: все образы, которые связаны с их текущими работами. К примеру, если мы рассматриваем PR, то имеет смысл оставлять образ, соответствующий последнему коммиту и, скажем, предыдущему коммиту: так разработчик сможет оперативно возвращаться к любой задаче и работать с последними изменениями.

4. Четвертый образы, которые соответствуют версиям нашего приложения, т.е. являются конечным продуктом: v1.0.0, 20.04.01, sierra и т.д.

NB: Определенные здесь критерии были сформулированы на основе опыта взаимодействия с десятками команд разработчиков из разных компаний. Однако, конечно, в зависимости от особенностей в процессах разработки и используемой инфраструктуры (например, не используется Kubernetes), эти критерии могут отличаться.

Соответствие критериям и существующие решения

Популярные сервисы с container registry, как правило, предлагают свои политики очистки образов: в них вы можете определять условия, при которых тег удаляется из registry. Однако возможности этих условий ограничиваются такими параметрами, как имена, время создания и количество тегов*.

* Зависит от конкретных реализаций container registry. Мы рассматривали возможности следующих решений: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io по состоянию на сентябрь'2020.

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

Например, третий критерий связанный с потребностями разработчиков может решаться за счет организации процессов внутри команд: специфичного именования образов, ведения специальных allow lists и внутренних договоренностей. Но в конечном счете его всё равно необходимо автоматизировать. А если возможностей готовых решений не хватает, приходится делать что-то своё.

Аналогична и ситуация с двумя первыми критериями: их невозможно удовлетворить без получения данных от внешней системы той самой, где происходит развёртывание приложений (в нашем случае это Kubernetes).

Иллюстрация workflow в Git

Предположим, вы работаете примерно по такой схеме в Git:



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

Что произойдёт, если политики очистки позволяют оставлять (не удалять) образы только по заданным названиям тегов?



Очевидно, такой сценарий никого не обрадует.

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



Результат стал значительно лучше, однако всё ещё далёк от идеала. Ведь у нас по-прежнему есть разработчики, которым нужны образы в реестре (или даже развёрнутые в K8s) для отладки багов

Резюмируя сложившуюся на рынке ситуацию: доступные в реестрах контейнеров функции не предлагают достаточной гибкости при очистке, а главная тому причина нет возможности взаимодействовать с внешним миром. Получается, что команды, которым требуется такая гибкость, вынуждены самостоятельно реализовывать удаление образов снаружи, используя Docker Registry API (или нативный API соответствующей реализации).

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

Наш путь к универсальной очистке образов

Откуда такая потребность? Дело в том, что мы не отдельно взятая группа разработчиков, а команда, которая обслуживает сразу множество таковых, помогая комплексно решать вопросы CI/CD. И главный технический инструмент для этого Open Source-утилита werf. Её особенность в том, что она не выполняет единственную функцию, а сопровождает процессы непрерывной доставки на всех этапах: от сборки до деплоя.

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

* Хоть сами реестры могут быть различными (Docker Registry, GitLab Container Registry, Harbor и т.д.), их пользователи сталкиваются с одними и теми же проблемами. Универсальное решение в нашем случае не зависит от реализации реестра, т.к. выполняется вне самих реестров и предлагает одинаковое поведение для всех.

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

Итак, мы занялись внешней реализацией механизма для очистки образов вместо тех возможностей, что уже встроены в реестры для контейнеров. Первым шагом стало использование Docker Registry API для создания всё тех же примитивных политик по количеству тегов и времени их создания (упомянутых выше). К ним был добавлен allow list на основе образов, используемых в развёрнутой инфраструктуре, т.е. Kubernetes. Для последнего было достаточно через Kubernetes API перебирать все задеплоенные ресурсы и получать список из значений image.

Такое тривиальное решение закрыло самую критичную проблему (критерий 1), но стало только началом нашего пути по улучшению механизма очистки. Следующим и куда более интересным шагом стало решение связать публикуемые образы с историей Git.

Схемы тегирования

Для начала мы выбрали подход, при котором конечный образ должен хранить необходимую информацию для очистки, и выстроили процесс на схемах тегирования. При публикации образа пользователь выбирал определённую опцию тегирования (git-branch, git-commit или git-tag) и использовал соответствующее значение. В CI-системах установка этих значений выполнялась автоматически на основании переменных окружения. По сути конечный образ связывался с определённым Git-примитивом, храня необходимые данные для очистки в лейблах.

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

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

В целом, получившаяся реализация удовлетворяла нашим потребностям, но вскоре нас ожидал новый вызов. Дело в том, что за время использования схем тегирования по Git-примитивам мы столкнулись с рядом недостатков. (Поскольку их описание выходит за рамки темы этой статьи, все желающие могут ознакомиться с подробностями здесь.) Поэтому, приняв решение о переходе на более эффективный подход к тегированию (content-based tagging), нам пришлось пересмотреть и реализацию очистки образов.

Новый алгоритм

Почему? При тегировании в рамках content-based каждый тег может удовлетворять множеству коммитов в Git. При очистке образов больше нельзя исходить только из коммита, на котором новый тег был добавлен в реестр.

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

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

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

Итоговая конфигурация и общий алгоритм

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

• множеством references, т.е. Git-тегами или Git-ветками, которые используются при сканировании;
• илимитом искомых образов для каждого reference из множества.

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

cleanup:  keepPolicies:  - references:      tag: /.*/      limit:        last: 10  - references:      branch: /.*/      limit:        last: 10        in: 168h        operator: And    imagesPerReference:      last: 2      in: 168h      operator: And  - references:        branch: /^(main|staging|production)$/    imagesPerReference:      last: 10

Такая конфигурация содержит три политики, которые соответствуют следующим правилам:

1. Сохранять образ для 10 последних Git-тегов (по дате создания тега).
2. Сохранять по не более 2 образов, опубликованных за последнюю неделю, для не более 10 веток с активностью за последнюю неделю.
3. Сохранять по 10 образов для веток main, staging и production.

Итоговый же алгоритм сводится к следующим шагам:

• Получение манифестов из container registry.
• Исключение образов, используемых в Kubernetes, т.к. их мы уже предварительно отобрали, опросив K8s API.
• Сканирование Git-истории и исключение образов по заданным политикам.
• Удаление оставшихся образов.

Возвращаясь к нашей иллюстрации, вот что получается с werf:



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

Заключение

• Рано или поздно с проблемой переполнения registry сталкивается большинство команд.
• При поиске решений в первую очередь необходимо определить критерии актуальности образа.
• Инструменты, предлагаемые популярными сервисами container registry, позволяют организовать очень простую очистку, которая не учитывает внешний мир: образы, используемые в Kubernetes, и особенности рабочих процессов в команде.
• Гибкий и эффективный алгоритм должен иметь представление о CI/CD-процессах, оперировать не только данными Docker-образов.

P.S.

Читайте также в нашем блоге:

• Content-based tagging в сборщике werf: зачем и как это работает?;
• 3-way merge в werf: деплой в Kubernetes с Helm на стероидах;
• Поддержка monorepo и multirepo в werf и при чём здесь Docker Registry;
• Релиз werf 1.1: улучшения в сборщике сегодня и планы на будущее.

Полтора года назад мы переводили пару статей о том, что такое GitOps. С тех пор этот термин (и сам подход) набрал ещё большую популярность в среде DevOps-инженеров, особенно эксплуатирующих Kubernetes. В то же время у меня появилось свое видение того, какие у него проблемы и каким он должен быть. Поделиться этими мыслями я решил в получасовом видео смотрите его либо читайте основную выжимку, если предпочитаете текст:


Далее представлен текстовый пересказ видео.

Предисловие о терминологии

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

В сообществе бытуют два понимания GitOps:

1. Обобщенное как паттерна, при котором Git является единым источником правды и в котором через действия в Git мы управляем действительностью. Из самого названия GitOps любому, кто много работал с Git и IaC (Infrastructure as Code), интуитивно понятен этот паттерн. Именно такое обобщенное понимание мы и используем в нашем проекте werf.
2. Более конкретное понимание GitOps, в частности, определяющееся pull-моделью и обязательным промежуточным Git-репозиторием. Именно такую конкретную реализацию достаточно активно продвигают некоторые компании (включая авторов самого термина). Информацией именно об этой модели заполнен интернет.

В данном видео (и статье) под GitOps я подразумеваю именно второе, конкретное, понимание и пытаюсь разобрать, какие к нему есть вопросы.

Что такое GitOps

Какая картина возникает у вас в голове, когда вы слышите GitOps?

Все начинается с Git-репозитория. В нем есть YAML-файлы, описывающие желаемое состояние Kubernetes. Например:

• два Deployment'а,
• StatefulSet,
• Ingress.

Вместе они формируют некоторое простое приложение, которое располагается в кластере Kubernetes.

Единственная недостающая часть это GitOps-оператор. Он отвечает за синхронизацию состояния из Git в Kubernetes. Для этого он периодически (или по событию, которое может быть запущено, например, через webhook):

• считывает состояние из Git,
• считывает состояние из Kubernetes,
• сравнивает их,
• меняет состояние Kubernetes (если это необходимо).

Вот и все. Проще не бывает: репозиторий Git с (обычно предварительно скомпилированными) манифестами, кластер Kubernetes и штука, которая поддерживает синхронизацию между ними (GitOps-оператор).


Обычная схема GitOps в действии

NB. Хотя GitOps-оператор и может работать снаружи, почти всегда он находится внутри кластера Kubernetes. Но для упрощения мы изображаем его снаружи.

Само использование этого подхода уже предостерегает нас от некоторых вещей. Если по какой бы то ни было причине некоторый пользователь напрямую изменит что-то в Kubernetes, GitOps-оператор обнаружит изменение и вернет K8s в состояние, определенное в Git. Это создает своего рода забор, который мотивирует пользователей (вместо прямого внесения изменений в K8s) делать правки в единственном источнике правды, которым выступает Git.

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


Стена, предотвращающая прямой доступ пользователей к Kubernetes

Всё ли здесь учтено?

В представленной схеме не хватает одной важной части container registry. Если новый Docker-образ попадает в реестр, GitOps-оператор через некоторое время обнаружит изменение и распространит его в Kubernetes (новый образ будет доставлен в K8s).



Становится очевидно, что состояние Kubernetes на самом деле не полностью определено в Git. Состояние Kubernetes определяется Git'ом и container registry.

Преимущества и недостатки GitOps

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

1. Автоматизация Мы не производим вручную ни какие-либо правки в Kubernetes, ни синхронизацию состояния из Git. Для последнего есть GitOps-оператор, который отвечает за синхронизацию, выполняя ее полностью автоматически.
2. Конвергентность Система стремится прийти в желаемое состояние и, даже если время от времени происходит рассинхронизация, сама возвращается обратно в требуемое, синхронизированное состояние. Почему может произойти рассинхронизация? Две основные причины: а) что-то изменилось в Kubernetes (ручные или несанкционированные действия и подобное), б) изменения внесены в Git, но еще не доставлены в Kubernetes. В обоих случаях за восстановление синхронизации системы отвечает GitOps-оператор.
3. Идемпотентность Если мы повторим синхронизацию несколько раз, результат первой синхронизации не повлияет на результат второй, они оба не повлияют на третью, и так далее. Впрочем, если у нас имеются уже скомпилированные манифесты, коммитнутые в Git, эта идемпотентность обеспечивается в основном самим Kubernetes и его API, так что в этом смысле заслуги GitOps тут нет.
4. Детерминизм Состояние в Kubernetes целиком и полностью определяется тем, что написано в Git. Как я уже говорил, это неправда, потому что состояние зависит ещё от container registry. Если кто-то изменит состояние реестра, изменит образ в реестре развалится практически всё. Подробности будут ниже.
5. Наблюдаемость В любой момент времени мы хотим знать, синхронизирована ли наша система. Хотим иметь возможность получать алерт, если это не так. С одной стороны да, наблюдаемость присутствует: ведь мы знаем, соответствует ли текущий Kubernetes манифесту в Git. Однако мы в то же время не знаем, находится ли наша система в желаемом состоянии. Ведь что такое желаемое состояние? Это комбинация из манифестов (в репозитории Git) и образов контейнеров (в реестре). Вывод: только половина состояния определяется Git, и только половину состояния можно наблюдать.
6. Аудит Необходимо надежно и удобно просматривать все изменения, внесенные в Kubernetes, причем в одном месте. И это место Git. Но это неправда, потому что мы также должны полагаться на функции аудита используемого container registry. Сопоставление данных аудита из двух систем совсем не назовешь надежным или удобным.
7. Безопасность Речь про запрет прямого доступа CI-системы к кластеру Kubernetes. На первый взгляд, наличие оператора, который находится внутри кластера и pull'ит изменения (без прямого доступа к кластеру извне), кажется более безопасным. Однако CI-система (или пользователь) по-прежнему должны иметь возможность отправлять образы в container registry и обновлять манифесты в Git'е. А это означает, что CI-система (или пользователь) уже имеют весь возможный доступ к кластеру. Изменение доступа с прямого на опосредованный не улучшает безопасность, а создает неправильное ощущение безопасности, что делает всю среду только менее защищенной. Вы должны обеспечить безопасность своего CI, других способов тут нет.

С чем мы вообще сравниваем GitOps?

Как обычно осуществляется доставка в Kubernetes? Самый очевидный и наиболее часто используемый способ это просто деплой из CI-системы. Этот подход иногда называют CIOps.

Как работает CIOps

Всё тоже начинается с Git-репозитория, но на этот раз не просто репозитория с манифестами Kubernetes. Это репозиторий приложения, который содержит:

• исходный код;
• Dockerfile(s);
• Kubernetes-манифесты, но теперь они представлены Helm-чартом;
• и скорее всего здесь же располагаются некоторые тесты.

К этому репозиторию подключена CI-система. Это может быть что угодно: Jenkins, GitLab CI/CD, GitHub Actions и т.д. У этой CI-системы есть следующие задания (или jobs, tasks, actions, stages как бы они ни назывались):

• Build для сборки образа;
• Unit test для запуска тестов на образе;
• Publish для публикации образа (или скорее даже образов) в реестре;
• Deploy to stage

На первый взгляд, это задание просто выполняет helm, которому передается чарт из Git. Но одного чарта недостаточно. Обычно вам также необходимо передать в Helm информацию о только что созданных образах: новые теги этих образов. На основе таких тегов Helm рендерит манифесты и отправляет их в Kubernetes API. А K8s в свою очередь уже приводит себя к заданному состоянию и вытягивает новые образы.

NB. Кстати, вы можете заменить Helm на любой другой инструмент: разницы не будет. В любом случае у вас есть какие-то шаблоны и теги Docker-образов. И теги будут использоваться для рендеринга (компиляции) этих шаблонов.

Вернемся к нашим заданиям, осталась еще парочка:

• E2e test для запуска end-to-end-тестов на развернутом приложении;
• Deploy to production делает то же самое, что и Deploy to stage, но для production-окружения.

Вот как обычно выглядит деплой в Kubernetes из CI-системы.


Обычная схема CIOps

Преимущества и недостатки CIOps

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

Прежде всего, что с детерминизмом? Бывает по-разному, но обычно всё плохо:

1. Во многих реализациях этого подхода я видел проблему в области сборки Docker-образов. Даже имея исходный код и Dockerfile в одном репозитории, а также действительно стараясь заморозить все внешние зависимости в нём же, мы всё равно в конечном итоге не получаем гарантии воспроизводимости наших сборок. Если по какой-либо причине мы соберем образ дважды (из одного и того же коммита), можно получить не только небольшие бинарные различия (потому что это два разных образа), но и два действительно разных образа (образы с разными содержимым).
   
   В Kubernetes нет проблем с детерминизмом процесса применения манифестов, однако сложность в том, чтобы сделать манифесты непротиворечивыми, повторимыми, воспроизводимыми одними и теми же каждый раз. Поскольку повторимость отрендеренных результатов во многом зависит от повторимости этапов сборки (и публикации), от детерминированности этапов сборки и публикации, конечный результат не получается консистивным и воспроизводимым, поэтому весь workflow получается недетерминированным.
2. Другая проблема заключается в стратегии тегирования. Найти способ воспроизводимого тегирования далеко не так просто. Наиболее естественной реализацией видится использование ID коммитов из Git'а. Можно сделать проверку наличия образа (в реестре) и, если образ с таким коммитом уже есть, пропустить сборку и публикацию, а если образа нет собирать образ и публиковать его. При таком подходе, если вы вызовете сборку несколько раз, второй и последующие вызовы ничего не поменяют.
   
   Однако я никогда не видел, чтобы в реальной жизни это делали правильно. Либо тег используется повторно, поэтому при повторном выполнении существующий образ заменяется в реестре (что обычно дает непредсказуемые результаты), либо стратегия тегирования основана на некоторых данных из CI-системы (идентификаторы заданий или что-то подобное).

Это означает, что нет и идемпотентности. Кстати, если некоторые шаги полагаются на данные из CI-системы, то состояние Kubernetes будет определять не только Git и container registry, но еще и CI-система

NB. Повторюсь, что в процессе применения манифеста нет проблем с идемпотентностью: проблема заключается в воспроизводимости в консистентности данных, которые мы передаем в Helm (которые передаются процессу рендеринга).

Таким образом, несмотря на то, что Helm-чарт находится в Git, несмотря на то, что Helm сам по себе идемпотентен (вы можете заменить Helm на kubectl или другой аналогичный инструмент), несмотря на то, что Dockerfile и исходный код также находятся в том же Git, весь workflow не является детерминированным и идемпотентным. Нет гарантии восстановления кластера до состояния конкретного коммита в Git.

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

• Больше нет конвергентности и наблюдаемости, потому что нет согласованного и повторяемого способа получить желаемое, целевое состояние (а как его тогда наблюдать?).
• Git не полностью определяет состояние, поэтому нет и аудита. История Git может что-то сказать, но это далеко не окончательный или единственный источник истины.
• Нужно ли говорить о безопасности? Замена прямого доступа на опосредованный ничего не меняет.

Зато всё хорошо с автоматизацией. Ведь CI-системы они про автоматизацию. Так что здесь вопросов нет: да, мы доставляем наши изменения автоматически. Просто эти изменения нам неизвестны

NB. Говоря об автоматизации, важно упомянуть еще одну вещь: обратную связь. Чтобы автоматизация работала правильно, необходимо предоставить пользователю четкую обратную связь. Когда мы разворачиваем приложения в Kubernetes, довольно часто попадаем в ситуацию, когда Helm (или kubectl apply) сообщает: Успешно применено. Однако это вовсе не означает, что наши изменения развернуты. Это лишь говорит о том, что запрос на развертывание приложений был успешно получен. Если вы попадали в подобную ситуацию, вам могут пригодиться werf или kubedog.

Подводя итог по CIOps: если все сделать правильно, такая схема может работать. Необходимо уделить достаточно внимания этапу сборки и тегированию, сделав их идемпотентными и детерминированными. Тогда в большинстве случаев вы мгновенно получаете все остальное (более или менее). Особенно, если вы не забываете об обеспечении понятной обратной связи.

Вот с чем мы должны сравнивать GitOps.

Но сделаю еще один шаг. Будьте честны с собой: как часто вам нужно повторно разворачивать приложение? Или развернуть его в каком-нибудь историческом состоянии? Если наступят плохие времена (авария в кластере или неизвестное изменение в кластере), мы будем глубоко опечалены Но если накатываем только новые изменения и если делаем это только последовательно, то ведь вполне себе можно жить с недетерминированным и неидемпотентным подходом.

Я не пытаюсь убедить вас в правильности такого подхода как раз наоборот: я категорически за детерминизм и за идемпотентность. Однако пытаюсь сказать, что в реальных ситуациях все может быть нормально даже с недетерминированным и неидемпотентным рабочим процессом. Поэтому, возможно, вы не захотите вкладывать много дополнительных усилий для достижения этой полной безопасности. Здесь вопрос скорее в том, сколько вы готовы заплатить?

GitOps или CIOps

Итак, на бумаге GitOps почти идеален, а CIOps очень плох. Однако совершенство GitOps (само по себе) вызывает сомнения. А CIOps, если все сделано правильно, может сработать или даже вполне хорошо работать. Но это всё ещё не полная картина.

Дело в том, что CiOps описывает весь процесс: от изменений, внесенных в Git приложения, до их развертывания в production-кластере Kubernetes, а GitOps охватывает только некоторую часть этого процесса. Давайте же посмотрим на всю картину.

GitOps на более полной схеме

Вернемся к схеме с GitOps. На самом деле, в Git-репозитории есть нескольких веток и, вероятно, есть несколько кластеров, например, для staging и production.


GitOps с разными ветками и кластерами

Но по-настоящему важно то, что основной Git-репозиторий, содержащий весь исходный код нашего приложения и все сопутствующие вещи, отсутствовал. Это тот самый репозиторий, который мы видели в CIOps. В дальнейшем будем называть их как репозиторий приложения (Application repo) и кластерный репозиторий (Cluster repo).

Затем весь процесс практически полностью повторяет CIOps. Задания в CI-системе:

• Build,
• Unit test,
• Publish,
• Deploy: начинаем с тех же шагов, забирая информацию об образах из задания Publish и передавая ее в Helm, но затем вместо того, чтобы вносить изменения напрямую в Kubernetes, мы делаем коммит в кластерный репозиторий.
  
  В то же время работает GitOps-оператор. И он либо замечает новые образы в container registry, либо новые манифесты в кластерном Git-репозитории. И выполняет свою работу: приводит Kubernetes к целевому состоянию.

Еще несколько вещей, на которые стоит обратить внимание:

1. У нас нет обратной связи в CI-системе: задание Deploy говорит, что все хорошо, потому что успешно коммитнуло новые манифесты в кластерный репозиторий. Однако это не означает, что изменения были успешно применены в кластере. Поэтому нужно заглянуть в какую-то другую систему И мы вынуждены делать это даже для того, чтобы проверить совсем простые вещи например, чтобы убедиться, валидны ли новые манифесты.
2. Система стала асинхронной. Например, GitOps-оператор может заметить новый образ в container registry до того, как новые манифесты будут коммитнуты (и увидены им). Таким образом, GitOps-оператор может применить старые манифесты с новыми образами, а вдруг они не подойдут друг другу?

Наконец, происходит деплой в production. В GitOps, чтобы сделать выкат в production, нужно выполнить merge из ветки staging в ветку production. (Возможно, вам также потребуется сделать promote образам из stage в production в реестре, хотя этого можно избежать, используя правильные стратегии тегирования.)



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

Даже если GitOps-часть делает все то, что о ней написано (а это не совсем так), общий workflow наследует все проблемы от CIOps и добавляет дополнительный уровень сложности.


При оценке GitOps важно учитывать весь CI-пайплайн

GitOps это антипаттерн?

Я считаю, что GitOps, реализованный описанным или подобным способом, на самом деле является антипаттерном. Вся культура DevOps говорит о плавности и непрерывности потока потока изменений от идеи/Git'а к production и о совместной работе. Однако такая реализация GitOps обманывает нас, обещая прозрачность и удобство, а на самом деле препятствует потоку ненужным промежуточным репозиторием, ненужной стеной между разработкой и эксплуатацией.

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

И что мы получим в таком случае?

• CIOps может быть неидемпотентным и недетерминированным и, будучи таковым, может вредить.
• Используя GitOps, мы получаем идемпотентность и детерминизм. Но
• Детерминизм в GitOps посредственный, потому что половина правды лежит не в Git, а в container registry.
• Другие минусы отустствие обратной связи там, где нам это нужно (в CI-системе, где разработчики всё делают), и повышенная сложность из-за новых элементов и введенной асинхронности.

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

Готов поспорить, что стандартная реализация GitOps будет заменена чем-то, что даст вам идемпотентность и детерминизм, но более практичным и удобным способом. Способом, совместимым с существующими подходами CI. Способом, не создающим стену. Будет ли этот подход называться GitOps 2.0?..

Эпилог про werf

Последние несколько лет мы в компании Флант работали над Open Source-инструментом werf. Как мне кажется, у нас получилось решить главный вызов всей этой истории (как я его вижу): мы смогли превратить основной Git-репозиторий (репозиторий приложения) в единственный источник истины. Для этого werf реализован таким образом, чтобы гарантировать идемпотентность и детерминизм этапов сборки, тегирования и деплоя. А все остальное построено на этом.



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

P.S.

Читайте также в нашем блоге:

• Что такое GitOps [по версии Weaveworks]?;
• GitOps: сравнение методов Pull и Push;
• werf наш инструмент для CI/CD в Kubernetes (обзор и видео доклада).

Что изменилось со времени 12.0

Прежде чем приступить к описанию нового мажорного релиза 13.0, мы хотели бы уделить внимание пройденному пути. Мы столького достигли с момента выхода версии 12.0! Недавно в блоге вышел специальный пост, в котором мы сделали обзор релизов GitLab с 12.0 по 12.10. Три наших фаворита из этой серии релизов это управление требованиями, сетевая безопасность контейнеров и конвейеры (в русской локализации GitLab сборочные линии) родитель-ребенок.

В дополнение к улучшениям самого продукта мы также обновили наши партнерские программы и интеграции, добавили рекомендации по интеграции для использования сторонних сканеров безопасности, а также расширили наши пакеты услуг техподдержки, чтобы помочь вам с такими вещами, как миграции Jira и Jenkins. На нашем новом видеоканале Learn@GitLab вы найдете множество видеоуроков. Например, Начало работы с CI.

Итерации ключ к устойчивости

GitLab помогает ИТ- и бизнес-командам развиваться, вовремя реагировать и адаптироваться, и ключ ко всему этому итерации. Пользователям необходимо быстро взаимодействовать, оптимизировать работу и автоматизировать процессы для обеспечения безопасности и соответствия требованиям, не забывая при этом о качестве продукта. GitLab 13.0 поможет вам итерировать быстро и с более глубоким пониманием процесса. Доступ к Git-репозиториям также является критически важным, и мы усовершенствовали наш кластер Gitaly для высокодоступных (HA) хранилищ Git, чтобы в случае сбоя всегда имелось несколько свежих и готовых к работе реплик.

Оперативное реагирование и сотрудничество всей команды

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

Дизайнеры важная часть команды разработчиков. Работая над одной из самых популярных новых фич, темной темой для Web IDE, мы поняли, как привлечь дизайнеров к более тесному сотрудничеству. Также мы переместили управление дизайном в план Core, тем самым отмечая пользователей, которые занимаются дизайном продуктов, как отдельных участников.

Оптимизация для повышения эффективности

Поскольку многие компании стремятся быть более оперативными и более эффективными, GitLab старается упростить существующие процессы разработки программного обеспечения. Новые фичи, направленные на повышение эффективности, включают в себя упрощенное развертывание на Amazon ECS и новый объединенный список оповещений, который объединяет IT-оповещения, поступающие из нескольких источников, в едином интерфейсе. Кроме того, у нас есть хорошая новость и для пользователей Terraform. В GitLab 13.0 появился краткий обзор результата terraform plan в мерж-реквестах (в русской локализации GitLab запросы на слияние) и использование GitLab в качестве бэкенда для state файла.

Доверяйте вашим процессам и не жертвуйте безопасностью и соответствием требованиям

GitLab помогает компаниям комплексно внедрять средства контроля безопасности и соответствия требованиям в жизненный цикл разработки ПО, снижая риски и высвобождая ресурсы для критически важных потребностей бизнеса. Наши возможности тестирования безопасности приложений помогают вам быстрее находить и исправлять уязвимости безопасности, благодаря чему GitLab недавно был назван нишевым игроком в Gartner Magic Quadrant for Application Security Testing 2020 года.

С момента оценки Gartner релиза 12.4 мы добавили много новых фич. А в 13.0 мы добавили возможность сканирования REST API через DAST и полное сканирование истории коммитов на наличие секретных ключей. Более того, мы поменяли наш способ работы с объектами уязвимостей. Благодаря этому появилась возможность экспортировать уязвимости из панели безопасности и в будущем будут доступны более широкие возможности управления уязвимостями.

В дополнение к сканированию безопасности в релизе 13.0 GitLab автоматизирует правила и обеспечивает более детальный контроль с помощью заморозки развертывания с помощью API Freeze Periods. Это поможет легко предотвратить непреднамеренные релизы в продакшн на указанный промежуток времени. Для упрощения аудитов в 13.0 появилась фильтрация в поиске событий аудита на уровне инстанса, это часть нашего эпика по событиям аудита.

А что впереди?

Мы с энтузиазмом готовим предстоящие релизы, в частности, фичи, которые помогут вам:

• Обеспечить соответствие требованиям и автоматически применять соответствующие меры контроля и отчетности.
• Получать больше инсайтов благодаря выпуску версий с A/B-тестированием и контролировать их с помощью нескольких улучшений для переключаемых фич фильтрация фич по статусу, A/B-тестирование на основе переключаемых фич и возможность создавать переключаемые фичи из мерж-реквеста).
• Определять узкие места и потери благодаря отображению стадий в аналитике цикла разработки в виде потока.
• Управлять правилами и оставлять GitLab автоматизацию их использования, включая готовый набор сетевых правил безопасности контейнера.
• Тестировать API приложений фаззингом, а также считывать переменные CI из хранилища HashiCorp.

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

Теперь, без лишних слов, приступим к описанию всех классных фич релиза 13.0!

Приглашаем на наши встречи.

MVP этого месяца Sashi

Sashi добавил огромное количество улучшений в релиз 13.0 в различных разделах GitLab. Его работа помогла улучшить контроль версий сниппетов, удалить ошибки, связанные с тегом Releases, и минимизировать дублирование событий, посылаемых веб-хуками. Также он улучшил структуру и читаемость кода, обеспечив каждому формату пакета уникальную модель для хранения метаданных.

Спасибо Sashi за всю эту работу!

Ключевые фичи релиза GitLab 13.0

Кластер Gitaly для высокодоступных хранилищ Git

(PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

GitLab теперь поддерживает высокодоступные системы хранения Git без использования NFS. Конфигурации высокой доступности (high availability, HA) повышают доступность важных систем, таких как хранилища Git, за счет устранения единичных точек отказа, обнаружения сбоев и автоматического переключения на реплику. Это означает, что отдельный компонент системы может выйти из строя, не вызвав сбоя у конечного пользователя. Доступ к репозиториям Git очень важен для разработчиков и компаний, поскольку при его выходе из строя разработчики не смогут отправлять код и развертывание будет заблокировано.

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

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

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

Автоматическое развертывание в ECS

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

До сих пор у нас не было простого способа развертывания в Amazon Web Services. Из-за этого пользователям GitLab приходилось тратить много времени на настройку собственной конфигурации.

В GitLab 13.0 поддержка развертывания в AWS уже ждет вас в Auto DevOps! Пользователи GitLab, которые развертывают в Elastic Container Service (ECS) от AWS, теперь могут воспользоваться возможностями Auto DevOps, даже если они не используют Kubernetes. Auto DevOps упрощает и ускоряет поставку и облачное развертывание с помощью полного конвейера поставки сразу из коробки. Благодаря устранению лишних сложностей вы сможете сконцентрироваться на аспектах создания программного обеспечения. Просто отправьте коммит, а GitLab сделает все остальное!

Чтобы подключить эту фичу, необходимо определить переменные окружения для AWS: AWS_ACCESS_KEY_ID, AWS_ACCOUNT_ID и AWS_REGION, а также включить Auto DevOps. Затем ваше развертывание ECS будет автоматически собрано для вас с полным автоматическим конвейером поставки.

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

Просмотр иерархии эпиков на дорожной карте

(ULTIMATE, GOLD) Стадия цикла DevOps: Plan

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

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

Контроль версий для сниппетов

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

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

Теперь сниппеты в GitLab также находятся под контролем версий в Git-репозитории. При редактировании сниппета каждое изменение создает коммит. Сниппеты также можно клонировать для локального редактирования, а затем отправлять в репозиторий Snippet.

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

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

Темная тема в Web IDE

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

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

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

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

Отдельные объекты уязвимостей

(ULTIMATE, GOLD) Стадия цикла DevOps: Defend

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

Одно из самых больших преимуществ заключается в том, что теперь каждая уязвимость будет иметь уникальный URL. Это означает, что на уязвимость можно ссылаться напрямую, делиться ей и отслеживать ее как единый источник информации. На этой странице вы можете изменить статус уязвимости на Обнаружена ("Detected"), Подтверждена ("Confirmed"), Проигнорирована ("Dismissed") или Решена ("Resolved"). Еще одним преимуществом является то, что обнаруженные уязвимости будут сохраняться при следующем запуске сканера. Ранее запуск сканирования на той же ветке перезаписывал все предыдущие результаты новыми. Сохранение прошлых объектов уязвимостей улучшит качество отслеживания, наглядность и сократит дублирование результатов между прогонами сканера. Кроме того, это даст в будущем возможность создавать отчеты о тенденциях уязвимостей в группах и проектах с течением времени по широкому ряду параметров.

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

Поддержка REST API в сканированиях DAST

(ULTIMATE, GOLD) Стадия цикла DevOps: Secure

В GitLab 13.0 мы добавили DAST сканирования REST API. Это позволит обеспечить полное DAST-покрытие безопасности всего приложения, а не только пользовательского интерфейса. DAST поддерживает использование спецификации OpenAPI в качестве руководства по сканированию URL-адресов и конечных точек REST, что позволит обеспечить безопасность всех направлений атак и даст больше информации о потенциальных уязвимостях любого работающего приложения.

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

SAST для .NET Framework

(ULTIMATE, GOLD) Стадия цикла DevOps: Secure

Мы представляем начальную поддержку .Net Framework, которая позволит разработчикам запускать сканирования безопасности SAST в дополнительных типах .NET проектов. Как и в других наших заданиях SAST, в них будут использоваться обработчики заданий GitLab (runner) для Linux. В будущем мы планируем добавить поддержку обработчиков заданий Windows. С момента появления в GitLab 11.0, SAST для .NET включал в себя поддержку только для проектов .NET Core.

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

Краткий обзор результата terraform plan в мерж-реквестах

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

Если вы используете Terraform для определения вашей инфраструктуры в виде кода, вы знаете, как удручает необходимость постоянно передавать коллегам итоговые изменения из команды terraform plan в slack и комментариях в мерж-реквестах. В GitLab 13.0 теперь вы будете видеть краткий обзор вывода команды terraform plan в том контексте, где это наиболее полезно непосредственно в вашем мерж-реквесте. Это поможет вам быстрее проверять изменения в вашей инфраструктуре и предоставит удобное место для взаимодействия с членами вашей команды по предполагаемому влиянию на вашу инфраструктуру по мере изменения кода.

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

Документация по работе с инфраструктурой с помощью Terraform и оригинальный эпик.

Использование GitLab в качестве бэкенда для state файла Terraform

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

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

Многие пользователи искали более простой способ настройки файлового хранилища без использования дополнительных сервисов или настроек. Начиная с GitLab 13.0 как HTTP-бэкенд для Terraform можно использовать сам GitLab, что устраняет необходимость настраивать отдельное хранилище для state файлов для каждого нового проекта.

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

HTTP-бэкенд для состояний Terraform от GitLab поддерживает:

• Многочисленные именованные файлы состояния в одном проекте
• Блокировку
• Хранилище объектов
• Шифрование в состоянии покоя

Все это теперь доступно и для пользовательских инстансов GitLab, и на GitLab.com.

Документация по работе с инфраструктурой с помощью Terraform и оригинальный эпик.

Исключайте большие файлы с помощью частичного клонирования

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

Хранение больших бинарных файлов в Git обычно не приветствуется, поскольку все добавленные файлы будут загружены каждым, кто впоследствии клонирует или проверяет обновления (git fetch) репозитория. Это сильно замедляет, если вовсе не останавливает, работу при медленном или ненадежном соединении.

В GitLab 13.0 частичное клонирование было включено для фильтров по размеру блоба, а также экспериментально для других фильтров. Это позволяет исключить проблемные большие файлы из клонирований и скачиваний обновлений. Когда Git обнаруживает недостающий файл, он будет загружен по требованию. При клонировании проекта используйте --filter=blob:none для полного исключения блобов или --filer=blob:limit=1m для исключения по размеру файла. Обратите внимание, что для частичного клонирования требуется версия Git не ниже 2.22.0.

Узнайте все подробности в нашем недавнем посте Как частичное клонирование в Git позволяет вам получать только необходимые большие файлы.

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

Управление панелями метрик через переменные

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

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

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

Сниженное потребление памяти GitLab с Puma

(CORE, STARTER, PREMIUM, ULTIMATE) Доступность

Puma теперь по умолчанию является сервером веб-приложений для установок на основе Omnibus и Helm. Puma снижает объем памяти, потребляемой GitLab, примерно на 40% по сравнению с Unicorn, что повышает эффективность работы GitLab и позволяет потенциально сэкономить на стоимости инстансов с самостоятельным управлением.

Установкам, которые настроили количество процессов Unicorn, или используют более медленные диски с NFS, возможно придется изменить конфигурацию Puma по умолчанию. Посмотрите важные заметки по обновлениям и улучшения в GitLab chart, чтобы узнать больше.

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

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

Фильтр для поиска по событиям аудита в инстансе

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

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

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

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

Включение защиты веток по умолчанию на уровне группы

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

Раньше при переносе настроек защиты ветки по умолчанию с уровня инстанса на уровень проектов можно было легко запутаться, потому что в некоторых сценариях этот процесс был неинтуитивным: разработчики не могли добавлять новые коммиты в проекты, которые они же и создали. Из-за этого организациям было сложно найти баланс между снижением рисков и предоставлением свободного доступа к проектам для всех разработчиков, так как решение проблемы требовало повышения их до maintainer (в русской локализации GitLab сопровождающий).

Теперь защиту веток по умолчанию можно настроить на уровне группы, чтобы предоставить большую гибкость для администраторов и владельцев групп. Используя комбинацию защиты веток по умолчанию и настроек создания проекта по умолчанию, организации смогут найти нужный баланс между автономией и контролем. Например, использовать свои настройки для защиты веток по умолчанию и разрешать создавать новые проекты только пользователям с ролями maintainer. Это позволит разработчикам добавлять новые коммиты (без принудительного пуша или удаления веток) к новым проектам, при этом оставляя создание проектов maintainers.

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

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

Аналитика цикла разработки: график задач по типу

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage

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

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

Email-уведомления при авторизации из неизвестного источника

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

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

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

Предупреждение при закрытии тикета с неразрешенными зависимостями

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

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

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

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

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

Более удобное добавление эпиков и тикетов через дерево эпиков

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Plan

Создание и добавление тикетов и эпиков через дерево эпиков ранее было разделено по нескольким кнопкам и выпадающим меню, и поэтому его было неудобно использовать. Мы объединили действия add (добавить) и create (создать) в отдельную кнопку с меню, чтобы добавлять новые тикеты и эпики было проще и быстрее!

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

Эмодзи в обсуждении дизайнов

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

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

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

Новый режим сравнения для мерж-реквестов

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

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

В GitLab 13.0 мы добавляем экспериментальный режим сравнения. Он будет показывать дифф, рассчитанный путем симуляции мержа, что даст более точное представление изменений, чем использование мержей обеих веток. Этот режим доступен в выпадающем меню ветки, выбранной для сравнения через пункт master (HEAD). В будущем этот режим заменит текущий способ сравнения по умолчанию.

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

Темы подсветки синтаксиса для Web IDE

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

GitLab поддерживает шесть тем подсветки синтаксиса при просмотре кода. Темы крайне важны для удобства разработчиков при просмотре и редактировании кода в GitLab. Теперь мы добавили поддержку всех шести тем подсветки синтаксиса в Web IDE, включая Solarized Dark, Solarized Light, Monokai и режим без подсветки.

На протяжении нескольких последних релизов (например, в 12.8 и 12.9) мы добавляли и улучшали поддержку тем подсветки в Web IDE. Новые темы подсветки являются продолжением этой работы и помогли заложить основу для нашей темной темы в Web IDE, которая также выходит в 13.0. Мы продолжаем улучшать интерфейс для разработчиков и делать нашу Web IDE более комфортной.

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

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

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

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

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

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

Правила пушей для групп

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

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

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

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

Кнопки навигации по коммитам в мерж-реквестах

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

Удобная навигация по коммитам в больших мерж-реквестах позволяет более эффективно проводить ревью с перемещением между коммитами.

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

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

Доступ к отчетам JUnit через API GitLab

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

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

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

Фильтр для конвейеров по автору триггера и названию ветки

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

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

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

Доступ к реестру пакетов GitLab для чтения или записи через токены развертывания

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Package

Токены развертывания позволяют вам получать доступ к репозиториям группы, репозиториям проекта и реестрам контейнеров. Команды read_repository, read_registry и write_registry ранее не позволяли вам получать доступ к реестру пакетов GitLab. В результате командам DevOps приходилось использовать небезопасные или дорогостоящие обходные пути.

В GitLab 13.0 мы добавили более точные настройки разрешений токенов развертывания GitLab. Теперь вы можете задавать доступ к реестру пакетов для чтения или записи. Создавать токены развертывания и управлять ими можно из приложения GitLab или через API.

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

Все версии пакета под одним именем

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Package

Реестр пакетов GitLab ранее рассматривал каждую новую версию пакета как новый пакет. Из-за этого было сложно искать нужные пакеты или сравнивать изменения между разными версиями пакета.

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

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

Заморозка развертывания через API Freeze Period

(ULTIMATE, GOLD) Стадия цикла DevOps: Release

С этим релизом GitLab предоставляет больше способов управлять окружениями. Новый API Freeze Period позволит вам легко предотвратить непреднамеренный релиз в продакшн в течение заданного вами периода, например, во время праздника или корпоративного события. Теперь вы можете пользоваться правилами, которые обычно находятся за пределами GitLab, чтобы уменьшить неопределенность и риск при автоматизации развертываний.

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

Обновление майлстоунов релиза через пользовательский интерфейс GitLab

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

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

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

Поиск образов по имени в реестре контейнеров GitLab

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

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

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

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

Просмотр нагрузки и аннотаций внешних IT-уведомлений в GitLab

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

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

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

Рендер эмодзи на странице состояния проекта

(ULTIMATE, GOLD) Стадия цикла DevOps: Monitor

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

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

Переключение видимости панели метрик

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

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

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

Добавление аннотаций на панель метрик

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

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

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

Поиск секретных ключей в полной истории репозитория

(ULTIMATE, GOLD) Стадия цикла DevOps: Secure

В GitLab 13.0 мы обновляем наше сканирование для поиска секретных ключей для поддержки новой переменной SAST_GITLEAKS_HISTORIC_SCAN, что позволит проводить сканирование полной истории репозитория. Это поможет вам находить ключи, которые могли затеряться среди старых коммитов. На момент появления в GitLab 11.9 сканирование для поиска секретных ключей проводилось по истории изменений в коммитах мерж-реквеста, что позволяло находить новые добавленные ключи, но не затрагивало более давнюю историю коммитов. Наша новая фича будет особенно полезна при использовании поиска секретных ключей в репозитории в первый раз для полного сканирования репозитория на наличие ключей.

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

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

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

(ULTIMATE, GOLD) Стадия цикла DevOps: Defend

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

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

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

Интеграция SIEM с файерволом веб-приложений

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

Мы объявляем о новой интеграции SIEM для файервола веб-приложений (WAF). Эта интеграция позволяет пользователям экспортировать свои логи WAF в SIEM или в централизованное решение для логирования, чтобы можно было просматривать любые аномалии, обнаруженные WAF. Эта фича также облегчает пользователям тестирование и настройку пользовательских правил WAF, что уменьшает количество ложных срабатываний. Интеграцию SIEM можно настроить, включив Fluentd на странице Операции > Kubernetes (Operations > Kubernetes).

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

Вторичные ноды Geo автоматически пересылают запросы SSH для несинхронизированных репозиториев

(PREMIUM, ULTIMATE) Доступность

Geo поддерживает выборочную синхронизацию проектов, что позволяет системным администраторам выбирать подмножество данных, реплицируемое во вторичные ноды Geo. Geo уже поддерживает перенаправление запросов HTTP(S) на основной сервер при попытке доступа к этим несинхронизированным репозиториям. Однако пользователи, пытавщиеся получить доступ к несинхронизированным репозиториям на вторичной ноде через SSH, получали сообщение об ошибке, что репозиторий недоступен. Это сбивало с толку пользователей и заставляло их либо ждать синхронизации хранилища, либо выполнять дополнительную работу для подключения к нужному хранилищу.

В GitLab 13.0 любые запросы Git, сделанные через SSH к несинхронизированной вторичной ноде Geo, будут перенаправлены на первичную ноду. Это приводит к гораздо более плавному взаимодействию с пользователями, поскольку им не нужно будет знать, что реплицируется или не реплицируется на эту ноду: Geo выполнит запрос как по HTTP(S), так и по SSH без какой-либо дополнительной настройки.

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

Обработчик заданий теперь поддерживает загрузку артефактов непосредственно из хранилища объектов

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

Обработчик заданий GitLab (GitLab Runner) 13.0 теперь поддерживает загрузку артефактов непосредственно из хранилища объектов. Когда эта опция включена, сервер GitLab будет перенаправлять обработчик заданий непосредственно в хранилище объектов, а не проксировать трафик. Это может привести к значительной экономии затрат на передачу по сети, а также к снижению нагрузки на сервер GitLab.

Для подключения установите переключаемую фичу FF_USE_DIRECT_DOWNLOAD в true через переменную окружения.

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

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

(PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

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

Это важное дополнение к событиям аудита исправляет пробел в неоспоримости действий (nonrepudiation) для вашей программы соответствия требованиям и повышает надежность и полноту данных о событиях аудита GitLab.

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

Аналитика цикла разработки: метрики для времени выполнения и времени цикла

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage

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

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

Приложение интеграции Okta SCIM для GitLab.com

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage

Теперь мы предлагаем приложение интеграции Okta SCIM для групп на Gitlab.com. Когда Okta SCIM настраивается для группы GitLab, членство в этой группе синхронизируется между GitLab и Okta. Это экономит время администратора группы, затрачиваемое на добавление и удаление пользователей.

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

Экспорт и импорт групп в пользовательском интерфейсе

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

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

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

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

Просмотр майлстоунов на дорожной карте

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Plan

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

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

Перетаскивание тикетов между эпиками в дереве эпиков

(ULTIMATE, GOLD) Стадия цикла DevOps: Plan

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

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

Управление дизайнами теперь в Core

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

В релизе 12.2 управление дизайнами началось с загрузки дизайнов и обсуждения интересующих мест в рамках GitLab Premium. С тех пор мы рассматривали как отдельных участников наших пользователей, занимающихся дизайном продуктов, а в 13.0 мы переместили эти две фичи в GitLab Core. Это согласуется с нашей моделью покупки для индивидуальных разработчиков. Мы ожидаем, что в будущем по мере развития управления дизайнами мы добавим другие замечательные командные функции, такие как согласование.

Так что теперь все пользователи могут загружать дизайны и давать обратную связь по дизайну в тикетах GitLab. Напоминаем, что вы найдете вкладку Дизайн (Design) рядом с вкладкой Обсуждение (Discussion) в любом тикете. Для начала попробуйте загрузить скриншот с помощью перетаскивания.

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

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

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

С выпуском сниппетов с поддержкой версий в GitLab 13.0 мы обновили редактор сниппетов до более легкой версии редактора из нашей Web IDE. С помощью этого редактора пользователи смогут воспользоваться базовым дополнением кода и статическим анализом (линтингом) для некоторых языков. Мы также улучшили определение языка исходного кода для лучшей подсветки синтаксиса и добавили поддержку для всех наших тем подсветки синтаксиса. Эти улучшения облегчат редактирование и совместную работу над сниппетами.

Мы рады обеспечить согласованность редактора сниппетов и редактора в Web IDE. В следующем релизе мы добавим эти возможности также для нашего редактора одиночного файла и редактирования файла .gitlab-ci.yml.

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

WYSIWYG для редактора статических сайтов

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

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

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

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

Фильтр Approved-by для мерж-реквестов

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Create

Утверждение мерж-реквеста требует, чтобы определенные люди одобрили изменения, прежде чем их можно будет смержить. При поиске в списке мерж-реквестов вы можете быстро найти, какие из них нуждаются в вашем одобрении, с помощью фильтра Утверждающие (Approvers). В GitLab 13.0 теперь вы также сможете найти любые ранее одобренные вами мерж-реквесты, используя новый фильтр Approved-By.

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

Поддержка родительских групп и пользователей в файле CODEOWNERS

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

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

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

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

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

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

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

Теперь можно передавать переменные окружения и другие данные между заданиями CI. Используя ключевое слово dependencies (или ключевое слово needs для конвейеров DAG), задание может наследовать переменные от других заданий, если они получены с помощью артефактов отчета dotenv. Это предлагает более изящный подход для обновления переменных между заданиями по сравнению с использованием артефактов или передачей файлов.

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

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

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

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

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

Просмотр более надежных данных в списке в пользовательском интерфейсе реестра пакетов

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Package

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

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

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

Просмотр всех ваших пакетов Python в одном месте с помощью реестра пакетов GitLab

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Package

Пользовательский интерфейс реестра пакетов GitLab позволяет вам подтвердить, что ваши пакеты были собраны правильно, и устранить неполадки, если что-то пошло не так. Однако MVC нового репозитория PyPI, запущенного в 12.10, не включал эту функциональность.

В версии 13.0 мы добавили репозиторий PyPI в пользовательский интерфейс реестра пакетов. Теперь вы можете просматривать и загружать пакеты PyPI вашего проекта или группы и проверять метаданные и правильность сборки пакета. Вы также можете скопировать команды настройки и установки для более эффективного совместного использования и разработки. Если пакет был собран с использованием конвейера GitLab, вы сможете просмотреть и связать его с конвейером, а также с коммитом, который использовался для публикации пакета.

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

Поддержка API для списков переключаемых фич

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release

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

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

Определите правила, чтобы важные образы никогда не удалялись

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

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

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

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

Используйте облачные пакеты сборки для Auto DevOps (бета-версия)

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

Облачные пакеты сборки являются следующей итерацией пакетов сборки. В то время как GitLab в настоящее время по умолчанию использует пакеты сборки Herokuish, мы намерены перевести Auto DevOps на облачные пакеты сборки, когда проект созреет, чтобы предоставить нашим пользователям надежное и хорошо поддерживаемое решение. В этом релизе вы можете выбрать использование бета-версии облачных нативных пакетов сборки в конвейерах Auto DevOps, установив переменную CI AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED.

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

Агрегирование оповещений из внешних инструментов в GitLab

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

При реагировании на предупреждения респондентам необходим единый интерфейс, объединяющий IT-оповещения, поступающие из нескольких источников. Новый список оповещений позволяет быстро и интуитивно сортировать оповещения, чтобы в первую очередь найти и проанализировать наиболее важные проблемы. Вы можете найти список предупреждений в Операции > Оповещения (Operations > Alerts).

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

Добавьте часто используемые панели мониторинга в избранное

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

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

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

Отображение графиков в полноэкранном режиме

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

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

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

Анонимизация на страницах статуса

(ULTIMATE, GOLD) Стадия цикла DevOps: Monitor

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

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

Просмотр списка просканированных DAST ресурсов

ULTIMATE, GOLD) Стадия цикла DevOps: Secure

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

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

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

Интеграции SIEM для правил контейнерных сетей

(ULTIMATE, GOLD) Стадия цикла DevOps: Defend

Мы представляем новую интеграцию SIEM для правил сетевой безопасности контейнеров. Интеграция позволяет пользователям экспортировать свои логи Cilium в SIEM или в централизованное решение для логирования, чтобы они могли просматривать любые аномалии, обнаруженные их сетевыми правилами. Просмотр журналов также помогает пользователям тестировать и настраивать свои сетевые правила, чтобы снизить вероятность ложных срабатываний. Интеграцию SIEM можно настроить на странице Операции > Kubernetes (Operations > Kubernetes).

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

Оперативная информация о базе данных уязвимостей

(ULTIMATE, GOLD) Стадия цикла DevOps: Secure

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

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

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

PostgreSQL 11 теперь минимально необходимая версия для установки GitLab

(CORE, STARTER, PREMIUM, ULTIMATE) Доступность

Теперь минимальной требуемой версией PostgreSQL для всех пользовательских инстансов стала PostgreSQL 11. PostgreSQL версий 9.6 и 10 были удалены в GitLab 13.0. Это обновление позволяет нам начать вводить улучшения производительности на основе функций разбиения на разделы, которые были добавлены в PostgreSQL 11. Мы планируем поддерживать PostgreSQL 11 на протяжении всей серии релизов GitLab 13.x. Поддержка PostgreSQL 12 будет добавлена в ближайшее время. Посмотрите важные замечания по обновлению для получения инструкций по обновлению PostgreSQL.

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

Улучшена производительность репликации Geo для артефактов заданий, загрузок и файлов LFS

(PREMIUM, ULTIMATE) Доступность

Чтобы определить, что нужно реплицировать с первичной базы данных, Geo сравнивает базу данных отслеживания с вторичной базой данных только для чтения. Если запросы к базе данных Geo выполняются слишком долго, то данные не могут быть успешно реплицированы. В GitLab 13.0 мы используем новый подход к синхронизации артефактов заданий и загрузок, тем самым исключая возможность таймаутов базы данных. Мы также улучшили производительность запросов к базе данных для извлечения артефактов заданий, объектов LFS и загрузок, когда эти файлы хранятся локально. Это повышает общую масштабируемость и производительность GitLab Geo.

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

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

---

Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 13.0 released with Gitaly Clusters, Epic Hierarchy on Roadmaps, and Auto Deploy to ECS.

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

Релиз GitLab 13.1 уже доступен! Улучшения нового релиза включают расширенное управление уведомлениями и инструменты, которые помогут вам контролировать и улучшать качество кода, а также другие способы поддержания безопасности и соответствия вашего кода требованиям.

Автоматизируйте и расширяйте управление оповещениями

Оповещения необходимы для обслуживания приложения, но изучение и сортировка всех выдаваемых оповещений могут значительно снизить производительность и время отклика. Система управления оповещениями в GitLab объединяет и упорядочивает оповещения всех ваших сервисов, упрощая их анализ и устранение, повышая производительность и помогая вам сразу же приступить к изучению и ликвидации критических проблем. Ключевые нововведения в 13.1 включают назначение оповещений, интеграцию Slack и создание GitLab To-Dos при назначении оповещений.

Улучшение качества кода

Скорость развертывания имеет значение только в том случае, если вы развертываете качественный код. Благодаря приоритизации тестов для недавно измененного кода разработчики смогут сразу же начать устранять ошибки, не выполняя при этом весь набор тестов. Отслеживание покрытия кода с течением времени позволяет выявить тенденции качества как для разработчиков, так и для менеджеров, а встроенный code intelligence увеличивает скорость и точность ревью кода, интегрируя справочные материалы непосредственно в GitLab.

Укрепление и повышение уровня безопасности и соответствия требованиям

Безопасность важна для всех, и мы стремимся сократить барьеры на пути к полностью безопасному и совместимому SDLC. Вот почему мы рады сообщить, что мы перевели SAST-сканирование Brakeman в план Core, предоставляя возможность сканировать исходный код на наличие известных уязвимостей каждому Rails разработчику, независимо от уровня плана. Для организаций, ориентированных на соблюдение требований, мы добавили пользовательский интерфейс управления правилами для сетевых правил контейнеров, а также включили экспорт уязвимостей на уровне группы в CSV-файл для аудита или дальнейшего внутреннего анализа. Кроме того, мы внесли пару UX-улучшений в панель безопасности, добавив сохранение фильтров и иконки состояния тикетов для поддержания контекста во время работы в этой панели.

И это еще не все!

Это лишь небольшая выборка из обновлений релиза 13.1. В нем мы также достигли важного рубежа в отношении сотрудничества с сообществом. В рамках этого релиза были приняты более 300 мерж-реквестов (в русской локализации GitLab запросы на слияние) от нашего обширного сообщества, и мы высоко ценим вклад каждого из вас! Читайте дальше, чтобы узнать больше о других замечательных улучшениях, таких, как виджеты мерж-реквестов для тестирования доступности, возможность пометить обсуждение в дизайне как решенное, уведомления об успешном завершении конвейера и многие другие!

Если вы хотите узнать, что вас ждет в следующем релизе, посмотрите наше видео по релизу 13.2.

Приглашаем на наши встречи.

MVP этого месяца Jacopo Beschi

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

Работа над этой фичей заняла около 8 месяцев и Jacopo справился с этой задачей отлично! Он получил подтверждение от 5 различных ревьюверов, отличные отклики от нас в GitLab и большой интерес от пользователей: более 30 голосов за этот тикет и почти 70 активных дискуссий, связанных с ним.

Jacopo, спасибо за этот потрясающий вклад, мы очень его ценим!

Основные фичи в GitLab 13.1

Управление оповещениями в GitLab

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

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

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

В релизе 13.2 и далее мы планируем улучшить рабочие процессы оповещений и реагирования на инциденты с помощью интеграции с PagerDuty, отображения соответствующих метрик и логов оповещений, ассоциирования с перечнями задач (runbook) и создания специального Alert Integration Builder, чтобы ваши операторы могли самостоятельно обслуживать и беспрепятственно интегрировать GitLab с любыми инструментами мониторинга. Ознакомиться с ходом нашей работы и предложить свои идеи для будущих улучшений можно в эпике (в русской локализации GitLab цель) по управлению оповещениями.

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

Настройка стратегий переключения фич для разных окружений

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release

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

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

Виджет тестирования доступности в мерж-реквесте

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

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

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

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

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

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

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

С релизом 13.1 вы сможете отметить любой комментарий как Решенный (Resolved), что означает, что обсуждение по нему завершено. Пины завершенных обсуждений исчезнут из дизайна, так что вы сможете сосредоточиться на том, что осталось. И, конечно же, если вам нужно что-то пересмотреть, все ваши завершенные обсуждения будут доступны в области Решенные обсуждения (Resolved Comment) в нижней части боковой панели. Там вы сможете найти их и проверить, какая ревизия была применена в данной точке.

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

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

Ревью мерж-реквестов перенесены в Core

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

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

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

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

Code Intelligence

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

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

Мы вдохновлялись огромной работой, проделанной нашими коллегами из Sourcegraph, и использовали формат LSIF. Благодаря этому встроенный в GitLab Code Intelligence теперь можно добавить в любой проект с помощью нового задания в файле .gitlab-ci.yml. Это задание будет отвечать за LSIF-отчет, после генерации которого вы будете видеть доступные действия Code Intelligence при наведении курсора на объекты в коде. С релизом 13.1 вам больше не понадобятся сторонние инструменты или IDE для этого.

Будущие итерации будут включать в себя возможность поиска ссылок, а также поддержку API. Вы можете следить за обновленями в эпике Code Intelligence.

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

Управление переключаемыми фичами через списки пользователей

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release

GitLab раньше уже поддерживал возможность контролировать развертывание фич на основе ID пользователей. Однако многократно добавлять пользователей для каждой фичи или окружения может быть утомительно. Чтобы сделать этот процесс удобнее, мы добавили новую стратегию для переключаемых фич списки. Списки пользователей создаются и модифицируются с помощью API. После создания списка выберите стратегию list для вашей переключаемой фичи и соответствующий список. Если у вас уже есть созданные списки, вы сразу же сможете ими воспользоваться.

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

График изменения покрытия кода в проекте

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

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

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

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

Специальное задание CI для управления требованиями

(ULTIMATE, GOLD) Стадия цикла DevOps: Plan

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

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

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

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

Параметр expires_at в конечной точке /user/keys

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

Спасибо Petar Prokic (@pprokic) за этот вклад от сообщества!

Конечные точки в API пользователей /user/keys и /users/:id/keys теперь поддерживают опциональный параметр expires_at для определения даты истечения срока действия SSH-ключей. Это изменение поможет пользователям и организациям управлять последствиями в случаях скомпрометированных учетных записей в контролируемом окружении.

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

Конечная точка projects для API аудита событий

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

Спасибо Julien Millau (@devnied) за этот вклад от сообщества!

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

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

Тренды и подробности в аналитике тикетов

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage

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

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

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

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage

Ограничение доступа на основе IP-адресов теперь доступно для планов Premium и Silver. Эта фича позволяет вам ограничить доступ к группам и их контенту по одной или нескольким IP-подсетям. Включение ограничения доступа по IP гарантирует, что ваши данные не будут покидать пределы территории, не блокируя при этом доступ ко всему инстансу.

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

Заголовок тикета теперь зафиксирован на странице

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

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

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

Поддержка EditorConfig в Web IDE

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

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

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

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

Скрытие вступительной части YAML в статическом редакторе сайтов

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

Статические генераторы сайтов используют первые несколько строк (вступительную часть, "front matter") в начале файла Markdown, между двумя строками ---, для форматирования, настройки или парсинга страницы. Вступительная часть не должна отображаться вместе с содержимым страницы и должна при этом соответствовать определенным правилам форматирования.

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

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

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

Вставка изображений в Markdown в Web IDE

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

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

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

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

Фильтр конвейеров по статусу и имени тега

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

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

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

Переменные CI/CD для инстансов

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

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

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

Шаблоны для упрощения первоначальной настройки ключевых слов

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

Понять, как использовать новое ключевое слово rules, может быть сложно, особенно если ранее вы пользовались только only/except. Эти два ключевых слова отличаются принципиально: rules создает конвейер мерж-реквеста по умолчанию, а only/except этого не делает.

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

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

Скачивайте артефакты заданий проще и быстрее

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

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

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

С GitLab 13.1 мы добавили поддержку скачивания следующих типов отдельных отчетов по артефактам:

• доступность
• архив
• cobertura
• качество кода
• сканирование контейнера
• dast
• сканирование зависимостей
• dotenv
• junit
• управление лицензиями
• сканирование лицензии
• lsif
• метрики
• производительность

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

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

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

(ULTIMATE, GOLD) Стадия цикла DevOps: Secure

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

Просто перейдите на любую панель безопасности группы и кликните на новую кнопку Экспорт (Export). Ваш браузер автоматически начнет загрузку.

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

Более явный поиск секретных ключей и новый отдельный шаблон поиска секретных ключей

(ULTIMATE, GOLD) Стадия цикла DevOps: Secure

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

CI/CD конфигурация для поиска секретных ключей теперь предоставляется в отдельном шаблоне от GitLab и запускается как новый тип сканирования. Этот новый шаблон поиска секретных ключей теперь также включен в Auto DevOps. Мы рекомендуем вам использовать этот шаблон и затем убрать старое определение задания SAST secrets-sast из шаблона настройки SAST в файле SAST.gitlab-ci.yml. Мы сняли видео, которое объяснит вам процесс перехода на этот новый шаблон. Мы избавимся от старого определения SAST-задания по поиску секретных ключей в следующем релизе GitLab.

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

Сканирование SAST для Helm charts

(ULTIMATE, GOLD) Стадия цикла DevOps: Secure

Наш анализатор статического сканирования безопасности приложений (SAST) для манифестов Kubernetes теперь поддерживает Helm чарты. Это обновление также добавляет поддержку двух новых переменных окружения для точной настройки анализатора: KUBESEC_HELM_CHARTS_PATH и KUBESEC_HELM_OPTIONS.

Отдельное спасибо @agixid за вклад в разработку этой фичи!

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

Документация по сине-зеленым развертываниям

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

Мы задокументировали пример сине-зеленого развертывания с использованием NGINX, который загружает развертывание напрямую из файла .gitlab-ci.yml. Этот пример поможет вам настроить ваши сине-зеленые развертывания, если вы используете похожую конфигурацию, и предоставляет набор действий, которые вы можете применять и для других типов приложений.

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

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

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

Каждый раз, когда конвейер завершается с ошибкой, вы автоматически получаете уведомление по email. Однако, когда после неудачи конвейер восстанавливается и завершается успешно, автоматическое уведомление не приходит, что заставляет вас вручную проверять статус конвейера. В этом релизе мы рады представить вам фичу от @jacopo-beschi, которая решает эту проблему путем автоматической отправки уведомления, когда конвейер после неудачи завершается успешно.

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

Улучшенная авторизация для файла состояния Terraform под управлением GitLab

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

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

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

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

Назначение оповещений GitLab членам команды

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

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

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

Логирование назначений оповещений в системных заметках

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

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

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

Отправка оповещений GitLab в Slack

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

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

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

Создание списков To-Do при назначении работы по оповещениям

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

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

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

Отображение внешних ссылок на панели метрик

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

Панели метрик наиболее полезны тогда, когда они позволяют добавлять больше деталей. В GitLab 13.1 вы сможете добавлять ссылки в меню More actions на вашей панели метрик. Так вы можете связать вашу панель метрик и панель управления с другими панелями метрик и инструментами устранения неполадок, которыми пользуется ваша команда.

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

Поддержка UTC для панелей метрик

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

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

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

Панели задач с самомониторингом для пользователей Omnibus GitLab

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

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

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

Управление правилами сетевой безопасности контейнеров

(ULTIMATE, GOLD) Стадия цикла DevOps: Defend

С первым релизом пользовательского интерфейса для управления правилами сетевой безопасности контейнеров пользователи смогут легко сканировать список правил, применяемых в их проекте, и включать/выключать эти правила через пользовательский интерфейс. Вы можете посмотреть на новое управление правилами в Security & Compliance -> Threat Management -> Policies.

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

Сократилось время поиска через API

(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Доступность

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

В GitLab 13.1 мы оптимизировали некоторые запросы, решив проблему N+1 вызовов базы данных, и увидели 40%-е улучшение времени ответа. Поиск еще никогда не был таким быстрым!

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

Поиск со страницы проекта через выпадающее меню включает поиск по группе

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Доступность

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

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

Исправленные баги

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

Вот некоторые баги, которые мы исправили в релизе 13.1, и о которых стоит упомянуть:

• Наблюдения по релизу не собирались, если релиз был создан через пользовательский интерфейс
• Изображения в списке релизов выходили за рамки страницы
• Некорректно отображалась разметка в описании релиза
• Не было отображения ошибок нижестоящих конвейеров в вышестоящих
• Появлялась ошибка 404 Not Found при попытке скачать архив артефактов по определенному тегу через API заданий
• Не было проверки размера значения переменных инстанса
• Появлялось некорректное сообщение об ошибке, когда конвейеры отключены, а мерж-реквест должен завершиться успешно (must succeed) и нет запущенных внешних конвейеров
• API поиска игнорировал параметр ref при поиске коммитов
• Возникала ошибка настройки параметра Elasticsearch highlight.max_analyzed_offset в GitLab
• Была проблема со вложенными массивами в Elasticsearch версии 7.7.0
• Заметки в конфиденциальных тикетах отображались как конфиденциальные
• Не было отображения тикетов, добавленных в эпик через API на дереве эпиков
• Неправильно применялись ограничивающие (scoped) метки при добавлении по имени через API
• Оператор NOT игнорировался в булевом фильтре для эпиков

Все исправления багов в GitLab 13.1 можно посмотреть здесь.

Добавление события аудита при создании ключа SSH через API

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage

Спасибо Rajendra Kadam (@raju249) за вклад в разработку этой фичи!

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

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

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

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

Аналитика вкладов в разработку помогает командам понимать, как нагрузка распределяется между участниками. Ранее вклад пользователей, подтверждающих мерж-реквесты (approvers) никак не учитывался, несмотря на их значимую роль в обеспечении необходимого ревью. Таблица со вкладами пользователей в группе теперь включает столбец Approved MRs, с возможностью сортировки по числу подтвержденных мерж-реквестов.

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

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

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage

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

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

Быстрое назначение исполнителей

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

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

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

Распределение операций чтения по кластеру Gitaly (бета)

(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

Кластер Gitaly позволяет вам реплицировать репозитории Git на нескольких теплых нодах Gitaly, что повышает надежность путем устранения единичных точек отказа.

В GitLab 13.1 операции чтения Git можно распределять по актуальным репликам Gitaly. Это позволяет более эффективно использовать доступные ресурсы и может улучшить производительность.

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

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

Автоматическое аварийное переключение кластера Gitaly включено по умолчанию

(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

Кластер Gitaly улучшает отказоустойчивость хранилища Git в GitLab: устраняет единичные точки отказа, обнаруживает сбои и автоматически переключается на реплику. Начиная с GitLab 13.1, когда Gitaly Cluster настроен, по умолчанию включаются выбор ноды-лидера для SQL и аварийное переключение.

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

Ранее в GitLab 13.0 вместо аварийного переключения по умолчанию был выбор лидера в памяти.

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

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

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

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

В GitLab 13.1 вы можете быстро добавлять изображения на свои страницы с помощью редактора статических сайтов. После нажатия иконки Изображение на панели форматирования просто укажите URL, добавьте необязательный текст ALT, и все готово. Ссылка может вести на изображения, уже размещенные в вашем проекте, ресурс, размещенный в сети доставки контента (CDN), или любой другой внешний URL. Редактор создает миниатюры для предварительного просмотра, так что вы cможете убедиться, что добавили правильное изображение и нет ссылок на отсутствующие изображения.

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

Терминал Web IDE и синхронизация файлов перенесены в Core

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

GitLab 11.6 представил Веб-терминалы для Web IDE. Через несколько релизов была добавлена синхронизация файлов с веб-терминалом, позволяющая веб-терминалу взаимодействовать с изменениями, внесенными через Web IDE.

Ранее в 2020 году GitLab решил переместить 18 фич в опенсорсный план Core нашего продукта. В этом релизе GitLab мы завершили работу по перемещению в Core как веб-терминала, так и утилиты синхронизации файлов. Мы рады предоставить эти фичи большему числу пользователей и посмотреть, для каких ситуаций и рабочих процессов вы можете их использовать.

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

GitLab Runner 13.1

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

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

Что нового:

• Поддержка Windows 1903 для Docker executor под Windows
• Поддержка Windows 1909 для Docker executor под Windows
• Пакеты для RHEL/CentOS 8
• Выполняется любой шаг, определенный в ответе, возвращаемом заданием
• Kubernetes executor поддерживает конфигурацию авторизации Docker для приватных реестров

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

• Cборка иногда получала ошибку нет такого файла или каталога при доступе к каталогу сборки
• Запущенные длительные задания были отменены в пользовательском интерфейсе GitLab, но обработчик заданий продолжал процесс
• Обработчики заданий могли не поддерживать связь с сервером GitLab при сборке задания
• Задание застревало со стратегией прикрепления на Kubernetes
• Kubernetes прикреплял недопустимую метку времени лога при парсинге логов
• Была проблема с Kubernetes, когда скрипт сборки генерировал длинную строку
• Терялся конец вывода из обработчика заданий
• Было невозможно публиковать вспомогательные образы для Windows

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

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

Сначала выполняются тесты для измененных файлов

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

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

Разработчики Ruby могут сократить цикл обратной связи, используя gem TestFileFinder, чтобы найти тесты, предназначенные для измененного кода, а затем запустить эти тесты на ранней стадии в конвейере. Это подход MVC к решению проблемы, но мы надеемся, что он будет вам полезен. Мы с нетерпением ждем отзывов и идей в проекте TestFileFinder.

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

Используйте метаданные, чтобы понять, как создаются ваши пакеты NuGet

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Package

Когда пакет NuGet загружается в GitLab, задание открывает архив и читает файл .nuspec. Имя и версия пакета извлекаются сразу, но некоторые другие поля, например dependencies, project_url и tags, доступны, но не извлечены. Эти поля полезны для понимания того, как был построен пакет и каковы его зависимости.

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

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

Динамические значки состояния тикета на панелях безопасности

(ULTIMATE, GOLD) Стадия цикла DevOps: Secure

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

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

На панелях безопасности сохраняются фильтры

(ULTIMATE, GOLD) Стадия цикла DevOps: Secure

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

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

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

Анализатор SAST для Rails теперь доступен для всех

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

Мы хотим помочь разработчикам писать классный код и меньше беспокоиться о распространенных ошибках безопасности. Статическое тестирование безопасности приложений (SAST) помогает предотвратить уязвимости безопасности, позволяя разработчикам легко выявлять типичные проблемы безопасности по мере разработки кода и заранее их предотвращать. В рамках наших обязательств по управлению GitLab мы делаем наш анализатор SAST для Rails (Brakeman) доступным для каждого плана GitLab. Это позволит всем пользователям GitLab, работающим с Rails, использовать сканирования безопасности SAST для своих проектов. Мы продолжим переводить другие анализаторы SAST с открытым исходным кодом (OSS) в план Core. Вы можете следить за нашим эпиком SAST to Core, чтобы узнать, когда станут доступны другие анализаторы, и внести свой вклад в этот процесс.

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

Поддержка API для установки нескольких стратегий переключаемых фич

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release

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

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

Встроенная ссылка на руководство по развертыванию в AWS

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

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

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

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

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

Теперь GitLab позволяет вам удобно указать тип ссылки на ресурс, добавленный в ваш релиз, с помощью выпадающего меню. Ранее, если вы добавляли ссылки к релизу, вы не могли указать тип ресурса. Теперь вы можете выбрать тип ресурса из следующих вариантов: Runbook, Package, Image или Other.

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

Упрощенная настройка для интеграции Terraform

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

Вы можете проще запускать фичи Terraform, интегрированные в GitLab, с одним из образов Terraform, предоставленных GitLab. Образы Terraform в GitLab расширяют официальные образы Terraform для бета-версий Terraform 0.12 и 0.13, включая простые команды для использования виджетов для мерж-реквестов без раздувания ваших файлов YAML для CI/CD.

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

Сортировка столбцов для списка оповещений

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

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

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

Легенды в виде таблицы на панели метрик

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

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

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

На панели метрик отображаются ссылки на связанные панели

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

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

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

Проверка конфигурации панели метрик

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

Настраивать файлы YAML для панели мониторинга может быть сложно. GitLab 13.1 добавляет проверку в файл YAML, чтобы помочь вам диагностировать проблемы с панелью метрик. Если YAML определение панели мониторинга ошибочно, появится предупреждающее сообщение.

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

На страницах статуса теперь показываются изображения

(ULTIMATE, GOLD) Стадия цикла DevOps: Monitor

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

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

Улучшения в GitLab Helm chart

(CORE, STARTER, PREMIUM, ULTIMATE) Доступность

• Шаблон extraEnv теперь поддерживается в GitLab Helm charts. Это позволяет вам предоставлять дополнительные переменные окружения, такие как прокси-серверы, как для определенных чартов GitLab, так и глобально для всех чартов. Обратитесь к документации по глобальным настройкам или документации по подчартам, чтобы подробно узнать, как реализовать extraEnv.
• Пользовательские аннотации, определенные в разделе deployment глобальных настроек в values.yml, теперь доступны во всех подчартах GitLab. Аннотации развертывания позволяют предоставлять доступ на уровне развертывания, а не на уровне ноды, например разрешая развертыванию читать из корзины Amazon S3, не давая всей ноде доступа к этой корзине. Подробнее о настройке аннотаций развертывания смотрите в документации по аннотациям.
• Библиотеки PostgreSQL и клиент в образах контейнера GitLab обновились до PostgreSQL 12, что позволяет использовать больше версий PostgreSQL. Обратите внимание, что GitLab 13.1 по-прежнему поддерживает только PostgreSQL 11, но поддержка PostgreSQL 12 планируется в будущем релизе.
• Для повышения безопасности теперь вы можете передать ключ-секрет Kubernetes для значений заголовков с высокими требованиями к безопасности, таких как токен авторизации для конечных точек при настройке уведомлений реестра. За информацией о настройке обращайтесь к документации по настройкам реестра.

Документация по GitLab Chart.

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

(PREMIUM, ULTIMATE) Доступность

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

В GitLab 13.1 добавлена команда Geo gitlab-ctl promotion-preflight-checks, которая перечисляет все необходимые предполетные проверки и требует от системных администраторов подтверждения, что все эти проверки выполнены. Команда автоматически запускается при запуске
gitlab-ctl promote-to-primary-node.

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

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

Уменьшен размер индекса для расширенного глобального поиска

(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Доступность

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

Мы отключили частичное совпадение при поиске по коду в GitLab 13.1, что привело к уменьшению размера индекса на 75%. Если вам нужно частичное совпадение, вы можете использовать подстановочные знаки в своем поисковом запросе. Частичное совпадение для других типов контента, таких как тикеты или мерж-реквесты, по-прежнему поддерживается.

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

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

Используйте роли IAM для зашифрованных корзин Amazon S3

(CORE, STARTER, PREMIUM, ULTIMATE) Доступность

Теперь вы можете использовать роли AWS IAM для доступа к зашифрованным корзинам S3. Ранее такие корзины не работали вообще. Чтобы узнать больше, смотрите документацию по хранилищу объектов.

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

---

Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 13.1 released with Alert Management and Code Quality Enhancements.

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

Ну и год же был 2020! Мы счастливы представить релиз 13.7 с более чем 45 фичами и улучшениями поставки ПО, вышедший как раз к праздникам.

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

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

Вот что вас ждёт в релизе 13.7:

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

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

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

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

Улучшена автоматизация релизов и гибкость развёртывания

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

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

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

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

Более надёжное и эффективное управление пакетами и зависимостями

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

Мы также внесли улучшения в прокси зависимостей от GitLab; кстати, эта фича была перенесена в Core в GitLab 13.6.

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

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

И, наконец, вы можете использовать предопределённые переменные с прокси зависимостей взамен того, чтобы полагаться на свои собственные определённые переменные или вшитые значения в вашем файле gitlab.ci-yml. Таким образом, появился более масштабируемый и эффективный способ начать проксирование и кэширование образов.

И это ещё не всё!

Взгляните на ещё несколько классных новых фич релиза 13.7:

• Импорт требований из CSV-файла
• Размещение пользователей с помощью SAML на GitLab.com
• Возможность задавать через интерфейс процент трафика канареечных развёртываний
• Просмотр частоты развёртываний через API

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

6-7го января у нас прошёл виртуальный хакатон, узнайте больше об этом и будущих мероприятиях от GitLab здесь.

MVP этого месяца Rachel Gottesman

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

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

Проверяющие для мерж-реквестов

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

Попросить коллегу просмотреть ваш код должно быть обычной частью рабочего процесса, но иногда это бывает неоправданно сложно. Такая простая задача, как запрос на ревью, может привести к путанице. Например, как именно следует запрашивать: через электронное письмо, комментарий, сообщение в чате? Без формального механизма ревью мерж-реквестов могут быть непоследовательными, и за их проведением будет сложно уследить. Раньше уже можно было назначить проверяющего на мерж-реквест, но и автор, и рецензент отображались в одном и том же поле Assignee, что не позволяло другим членам команды узнать, кто за что отвечал в этом мерж-реквесте.

GitLab 13.7 представляет новую фичу теперь авторы мерж-реквеста могут запросить ревью у конкретных пользователей. В новом поле Reviewers пользователи могут быть назначены проверяющими для мерж-реквеста аналогичным образом, как назначаются ответственные (assignee). Назначенные на ревью пользователи получат уведомление, предлагающее им просмотреть мерж-реквест. Таким образом, теперь существует формальный процесс запроса ревью для мерж-реквеста и уточняются роли каждого пользователя в работе над ним.

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

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

Автоматический откат в случае сбоя

(ULTIMATE, GOLD) Стадия цикла DevOps: Release

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

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

Клонирование тикета через быстрое действие

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

Чтобы сделать создание похожих тикетов более эффективным, тикеты теперь поддерживают быстрое действие /clone, которое создаёт в том же проекте новый тикет с идентичными названием, описанием и метаданными. Быстрое действие /clone заменяет более трудоёмкий процесс, который включал в себя несколько шагов для создания тикета, копирования идентификатора или пути к исходному тикету и использование быстрого действия copy_meta.

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

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

Обработчик заданий GitLab для Red Hat OpenShift

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

Наконец-то стал доступен образ контейнера обработчика заданий GitLab (GitLab runner) для платформы контейнеров Red Hat OpenShift! Чтобы установить обработчик заданий на OpenShift, воспользуйтесь новым оператором обработчиков заданий GitLab. Он доступен на бета-канале в Red Hat's Operator Hub веб-консоли для администраторов кластеров OpenShift, уже развёрнутой по умолчанию на платформе, где они могут найти и выбрать операторы для установки на своём кластере. На платформе контейнеров OpenShift Operator Hub уже развёрнут по умолчанию. Мы планируем перенести оператор обработчика заданий GitLab на стабильный канал, а в начале 2021 года в общий доступ. Наконец, мы также разрабатываем оператор для GitLab, так что следите за будущими публикациями.

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

Просмотр статуса развёртываний на странице окружений

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

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

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

Задавайте через пользовательский интерфейс процент трафика для канареечного развёртывания

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release

В GitLab 13.7 вы можете менять процент трафика для канареечного развёртывания (значение canary-weight) непосредственно с досок развёртывания в пользовательском интерфейсе. Вы также можете менять это значение из gitlab-ci.yml и через API, но сделав это в пользовательском интерфейсе, вы сможете наблюдать за развёртыванием и при необходимости отмасштабировать поды прямо с досок развёртывания. Так у вас будет больше контроля над ручными или инкрементальными развёртываниями по таймеру, а также вы сможете лучше контролировать и даже снижать риски.

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

Просмотр частоты развёртываний через API

(ULTIMATE, GOLD) Стадия цикла DevOps: Release

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

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

Поддержка нескольких файлов манифеста в проекте

(PREMIUM, ULTIMATE) Стадия цикла DevOps: Configure

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

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

Импорт требований из внешних инструментов

(ULTIMATE, GOLD) Стадия цикла DevOps: Plan

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

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

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

Несколько конечных точек HTTP для оповещений

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Monitor

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

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

Синхронизация групп на GitLab.com с помощью SAML

(SILVER, GOLD) Стадия цикла DevOps: Manage

В GitLab 13.7 вы можете привязать группу в вашем поставщике учётных записей к группе на GitLab.com с помощью SAML. Членство в группе будет обновляться, когда пользователь войдёт в учётную запись GitLab через своего провайдера SAML. Эта фича снижает необходимость в ручном назначении групп, что снижает загрузку по группам для администраторов GitLab. Синхронизация групп также улучшает адаптацию новых членов групп, избавляя их от необходимости запрашивать доступ у администраторов групп GitLab.

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

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

DevOps Adoption

(ULTIMATE) Стадия цикла DevOps: Manage

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

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

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

Улучшенный пользовательский интерфейс для создания проектов

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

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

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

Ограничение создания проектов и групп для внешних аккаунтов

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Manage

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

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

Сортировка по числу блокируемых тикетов

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

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

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

В версии 13.7 вы можете использовать фильтр Блокирует другие тикеты для списка тикетов, чтобы отсортировать его по числу блокируемых тикетов.

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

Просмотр файлов в мерж-реквестах по одному

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

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

В GitLab 13.7 мы добавили возможность просматривать файлы по одному при просмотре мерж-реквеста. При переходе на вкладку мерж-реквеста Изменения кликните на иконку с шестерёнками и поставьте галочку Показывать файлы по одному. После выбора этого параметра вы сможете просматривать файлы по одному, переключаясь между ними при помощи кнопок Предыдущий и Следующий.

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

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

Просмотр изменений мерж-реквеста в VS Code

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

При ревью мерж-реквестов в VS Code для обращения к изменениям зачастую приходится делать checkout ветки и затем пытаться разобраться в диффе между этой веткой и целевой веткой мержа.

С релизом 3.7.0 расширения GitLab Workflow изменения мерж-реквеста стали доступны напрямую в VS Code. Это позволяет быстро просматривать изменения в мерж-реквестах ваших проектов.

В рамках работы над добавлением полноценного ревью кода в VS Code следующим шагом мы собираемся добавить комментарии к диффам.

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

Улучшенное скачивание артефактов для вложенных конвейеров

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

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

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

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

Обход ограничений Docker и ускорение конвейеров

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package
Для более быстрых и надёжных сборок вы можете использовать нашу фичу, прокси зависимостей, для кэширования образов контейнеров из Docker Hub. Однако, когда Docker начал применять ограничения по количеству запросов docker pull, вы могли заметить, что даже когда ваш образ скачивался из кэша, Docker всё равно засчитывал его в лимит. Это происходило потому, что прокси зависимостей кэшировал только слои (или блоб-объекты) образа, но не манифест, который содержит информацию о том, как собрать данный образ. Так как манифест был необходим для сборки, всё равно приходилось выполнять pull. А если Docker Hub был недоступен, вы не могли скачать нужный образ.
Начиная с этого релиза прокси зависимостей будет кэшировать и слои, и манифест образа. Так что при первом скачивании с использованием alpine:latest образ будет добавлен в кэш прокси зависимостей, и это будет считаться за один pull. В следующий раз, когда вы будете скачивать alpine:latest, всё будет скачиваться из кэша, даже если Docker Hub недоступен, и это скачивание не будет учитываться в лимите Docker.

Напоминаем вам, что начиная с 13.6 прокси зависимостей стал доступен в плане Core. Поэтому попробуйте эту фичу сейчас и скажите нам, что вы о ней думаете. Или даже лучше, помогите нам с открытыми тикетами.

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

Быстрый поиск и просмотр общих пакетов

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

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

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

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

Прокси зависимостей для приватных проектов

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

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

Теперь вы можете использовать прокси зависимостей и для приватных проектов. Вы можете снизить свои скачивания с Docker Hub путём кэширования ваших образов контейнера для использования их в будущем. Так как прокси зависимостей хранит образы Docker в пространстве, связанном с вашей группой, вы должны авторизоваться с вашим логином и паролем GitLab или с личным токеном доступа, для которого есть разрешение как минимум на чтение (read_registry).

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

Улучшенная поддержка анализаторов SAST для нескольких проектов

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

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

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

Описание релиза во внешнем файле

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

Если вы создаёте релизы в конвейерах через файл .gitlab-ci.yml вашего проекта, вам, возможно, было сложно поддерживать в актуальном состоянии описание каждого релиза. В релизе GitLab 13.7 вы можете задавать описание вашего релиза в файле с контролем версий или в автоматически генерируемом файле и вызывать его из .gitlab-ci.yml. При этом содержимое файла загружается в описание релиза в формате Markdown. Это упрощает создание, поддержку и использование контроля версий для релизов, а также будет особенно полезно при автогенерации лога изменений. Огромное спасибо Nejc Habjan и Siemens за этот невероятный вклад!

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

Поддержка для версий Kubernetes 1.17, 1.18 и 1.19

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

Поддержка GitLab для последних версий Kubernetes позволяет вам пользоваться преимуществами интеграций GitLab с Kubernetes, такими как GitLab Kubernetes Agent, Auto DevOps и на более поздних кластерах GitLab Managed Apps. В этом релизе GitLab добавил официальную поддержку для версий Kubernetes 1.17, 1.18 и 1.19.

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

Geo поддерживает репликацию сниппетов

(PREMIUM, ULTIMATE) Доступность

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

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

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

Поддержка зашифрованных учётных данных LDAP

(CORE, STARTER, PREMIUM, ULTIMATE) Доступность

GitLab использует единый файл конфигурации, например gitlab.rb в Omnibus GitLab, что упрощает настройку всех связанных сервисов. В этот файл конфигурации включены некоторые секретные ключи, например учётные данные для аутентификации на сервере LDAP. Хотя для доступа к этому файлу требуются специальные права, хорошей практикой считается отделять секретные ключи от конфигурации.

Установки Omnibus GitLab и Source теперь поддерживают зашифрованные учётные данные, причём первыми поддерживаемыми учётными данными стали LDAP. Это снижает уязвимость конфигурационного файла GitLab, а также помогает достичь соответствия требованиям заказчика.

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

Веб-хуки при добавлении новых участников группы

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

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

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

Улучшенная фильтрация и сортировка списков участников группы

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

Мы продолжили улучшать наш список участников группы и добавили для него новые возможности фильтрации и сортировки. Это поможет администраторам группы быстро находить нужную им информацию. Например, сортировку по последнему времени входа (Last sign-in) можно использовать для поиска пользователей, которые в последнее время не заходили на GitLab, и для помощи в управлении лицензиями.

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

Автоматическая подготовка профиля пользователя с SAML

(SILVER, GOLD) Стадия цикла DevOps: Manage

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

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

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

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

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

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

Различайте изменения форматирования и правки, сделанные из редактора статических сайтов

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

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

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

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

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

Предзаполненные переменные при ручном запуске конвейеров

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

Раньше, когда вы хотели запустить конвейер вручную, вам нужно было узнать нужные переменные, а затем ввести их на странице Запуск конвейера (Run Pipeline). Это может быть утомительно и чревато ошибками, если нужно ввести множество пар ключ-значение. Теперь форма для запуска конвейера будет сгенерирована для вашего конвейера с переменными, предварительно заполненными на основе определений переменных в вашем файле .gitlab-ci.yml, что сделает этот процесс более эффективным.

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

Собранные с помощью CI/CD пакеты всегда отображают информацию о сборке

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

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

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

В дальнейшем любой пакет, собранный или обновлённый с помощью GitLab CI/CD, будет отображать информацию о коммите и конвейере в пользовательском интерфейсе пакетов. Чтобы избежать проблем с производительностью или пользовательским интерфейсом, будут отображаться только пять обновлений пакета. В майлстоуне 13.8 мы создадим дизайн, который поможет вам легко просматривать все данные, включая историю. А пока вы можете использовать API пакетов, чтобы смотреть всю историю сборки данного пакета.

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

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

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

С помощью проксирования и кэширования образов контейнеров из Docker Hub прокси зависимостей помогает вам повысить производительность ваших конвейеров. Несмотря на то, что прокси-сервер предназначен для интенсивного использования с CI/CD, для использования этой фичи вам нужно было определить свои собственные переменные или прописать значения в вашем файле gitlab.ci-yml. Это затрудняло начало работы для тех, кто работает один, и не позволяло использовать его в качестве масштабируемого решения, особенно для организаций с множеством различных групп и проектов.

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

• CI_DEPENDENCY_PROXY_USER: пользователь CI для входа в прокси зависимостей,
• CI_DEPENDENCY_PROXY_PASSWORD: пароль для входа в прокси зависимостей,
• CI_DEPENDENCY_PROXY_SERVER: сервер для входа в прокси зависимостей,
• CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX: префикс образа для извлечения образов через прокси зависимостей.

Попробуйте и дайте нам знать, что вы думаете!

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

Результаты сканирований безопасности в виджете мерж-реквеста стали удобнее

(CORE, STARTER, PREMIUM, FREE, BRONZE, SILVER) Стадия цикла DevOps: Secure

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

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

Специальные ссылки на уязвимости

(ULTIMATE, GOLD) Стадия цикла DevOps: Secure

Мы ввели уязвимости как полноценные объекты в 12.10. Будучи объектом, каждая из них имеет уникальный URL-адрес, позволяющий напрямую перейти к деталям любой уязвимости. Несмотря на значительное улучшение видимости и согласованности, ссылки на уязвимости в тикетах и эпиках (в русской локализации GitLab цели) всё равно нужно копировать вручную в виде ссылок Markdown. Это делает неэффективным совместное использование, а ссылки на уязвимости в других областях GitLab более громоздкими, чем для других объектов, например тикетов.

Теперь на уязвимости можно ссылаться с помощью специальных ссылок. На них впервые будет опробован новый синтаксис [object_type:ID], который в конечном итоге распространится на другие существующие ссылки. Теперь вы можете быстро вставить ссылку на уязвимость из любого места, где обычно используется специальная ссылка, например из описания тикета или мерж-реквеста. Просто введите [vulnerability:123] в описании тикета, чтобы вставить ссылку на уязвимость с идентификатором 123 в том же проекте. Вы также можете добавить к идентификатору префикс пространства имён или проекта, чтобы ссылаться на уязвимости вне контекста текущего проекта.

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

Смотрите, какие коммиты и конвейеры выполняются в форке, а какие в родительском проекте

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

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

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

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

Запросы к базе данных выполняются быстрее при использовании балансировщика нагрузки

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Доступность

Многие запросы к базе данных повторяются несколько раз, так что их можно кэшировать для повышения общей производительности. Для GitLab можно кэшировать примерно 10% всех запросов. В GitLab 13.7 мы включили кэширование запросов к базе данных, когда используется балансировка нагрузки базы данных. На GitLab.com это приводит к кэшированию ~700 000 запросов каждую минуту и сокращает среднее время выполнения запросов вплоть до 10%.

Для запросов, которые выполняются более 100 раз, мы уменьшили продолжительность запроса на 11-31% и кэшировали ~30% всех операторов SELECT, которые бы в противном случае выполнялись на реплике базы данных.

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

Для новых установок по умолчанию используется PostgreSQL 12

(CORE, STARTER, PREMIUM, ULTIMATE) Доступность

Начиная с GitLab 13.3 PostgreSQL 12 был доступен в качестве опции как для пакетов Omnibus, так и для нашего Helm chart. PostgreSQL 12 улучшает производительность, а также предлагает значительные преимущества при индексировании и секционировании.

Начиная с GitLab 13.7 новые установки GitLab будут по умолчанию использовать PostgreSQL 12. Чтобы выполнить обновление вручную, запустите gitlab-ctl pg-upgrade.

Многонодовые инстансы базы данных должны будут переключиться с repmgr на Patroni до обновления с помощью Patroni. Затем можно обновить и повторно синхронизировать вторичные ноды Geo.

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

---

Полный текст релиза и инструкции по обновлению/установке вы можете найти в оригинальном англоязычном посте: GitLab 13.7 released with merge request reviewers and automatic rollback upon failure.

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

Если в качестве инфраструктуры, где разворачивается приложение, выступает Kubernetes, можно сказать, что существует два способа запуска тестов (и других утилит для анализа кода) в CI/CD:

• непосредственно в кластере K8s с помощью отдельных Job или Helm hooks;
• снаружи K8s например, на сервере сборки/деплоя или локально у разработчиков.

Первый подход мы достаточно подробно описывали на интересном примере с базами данных в статье Как мы выносили СУБД (и не только) из review-окружений в статическое. В этой статье рассмотрен более простой путь запуск вне K8s-кластера. Делать мы это будем на примере SonarQube-тестов в рамках CI/CD, построенного на базе GitLab с использованием werf.

Стоит помнить, что такой метод подходит только для тех тестов, которые не требуют подключения к другим объектам в инфраструктуре. С другой стороны, этот вариант хорош тем, что позволяет экономить кластерные ресурсы: нам не нужно выделять дополнительные ресурсы в K8s, поскольку вместо этого используются внешние мощности (локальных машин или сервера сборки/деплоя).

Для запуска тестов будет использоваться CI/CD-утилита werf, которая позволяет работать с полным жизненным циклом доставки приложений, а в частности удобно собирать Docker-образы, а потом запускать их локально. Если вы уже используете werf, встраивание дополнительных команд будет совсем тривиальным, а если нет на данном примере можно увидеть, как удобно контролировать все процессы CI/CD в одном месте.

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

Подготовка: внедряем тесты в пайплайн приложения

Основная особенность использования тестов и других анализаторов кода в CI/CD необходимость устанавливать дополнительные пакеты/конфигурационные файлы в Docker-образ приложения. Установка все в один образ увеличивает размер итогового образа и добавляет неиспользуемые файлы во время запуска самого приложения.

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

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

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

В werf реализация задуманного осуществляется с помощью переменных окружения, устанавливаемых в определенной Job в CI/CD-пайплайне.

Для конфигурации на стороне GitLab CI/CD потребуется определить Job с тестами (в .gitlab-ci.yml) примерно так:

Build sonar-tests:  stage: build  script:    - werf build-and-publish  variables:    SONAR_TESTS: "yes"  tags:    - werf  only:    - schedules

Как видно, в variables определяется переменная SONAR_TESTS, которая и будет задействована в сборке через werf.

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

В рамках подготовительных работ важно заметить, что в конфигурации сборки (werf.yaml) появится следующий блок:

{{ if eq (env "SONAR_TESTS") "yes" }}---image: sonar-testsfrom: node:10.16.0# остальные этапы сборки# ...{{ end }}

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

Собираем образы тестов в werf

Перейдем к непосредственному созданию инструкций для сборки Docker-образа с помощью werf. В этом образе требуются следующие элементы:

1. исходный код приложения;
2. необходимые пакеты/файлы для запуска Sonar-тестов;
3. информация о токене, URL до Sonarqube dashboard и названии приложения в конфигурационном файле.

Получается следующий набор инструкций для werf:

{{ $sonar_version := "4.4.0.2170"}}{{ if eq (env "SONAR_TESTS") "yes" }}---image: sonar-testsfrom: node:10.16.0git:  - add: /    to: /appansible:  install:  - name: "npm install sonar"    shell: |      npm install --no-save -D sonarqube-scanner    args:      chdir: /app  - name: "Install default-jdk"    apt:      update_cache: yes      state: present      name:      - default-jdk  - name: "install sonarqube scanner"    args:      chdir: /app    shell: |      wget https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-{{ $sonar_version }}.zip      mkdir -p /root/.sonar/native-sonar-scanner/      unzip -qq sonar-scanner-cli-{{ $sonar_version }}.zip -d /root/.sonar/native-sonar-scanner/      mv /root/.sonar/native-sonar-scanner/sonar-scanner-{{ $sonar_version }}/ /root/.sonar/native-sonar-scanner/sonar-scanner-{{ $sonar_version }}-linux/  - name: "Setup /app/sonar.js"    copy:      content: |{{ tpl (.Files.Get ".werf/sonar.js") . | indent 8 }}      dest: /app/sonar.js{{ end }}{{ end }}

Опять же, полную информацию по структуре и содержанию werf.yaml можно найти в документации. Здесь мы рассмотрим только основные инструкции. Итак, установка необходимых компонентов в образ состоит из следующих операций:

1. Добавление исходного кода приложения в образ с помощью Git-модуля werf.
2. Инсталляция через NPM пакетов sonar и sonarqube-scanner. Эти пакеты требуются для поддержки SonarQube в Node.js-приложении.
3. Установка JDK, который потребуется для запуска тестов.
4. Загрузка .jar-файла sonar-scanner, для которого мы и устанавливаем JDK.
5. Добавление конфигурационного файла sonar.js с помощью функции .Files.Get. Подробнее см. далее.

Что за файл, находящийся по адресу .werf/sonar.js? Это конфиг, в котором хранится вся необходимая информация для запуска Sonar-тестов. Посмотрим на его содержимое:

{{ $_ := env "SONAR_TOKEN" | set . "Token" }}{{ $_ := env "SONAR_PROJECT" | set . "Project" }}{{ $_ := env "SONAR_URL" | set . "Url" }}    const sonarqubeScanner = require('sonarqube-scanner');    sonarqubeScanner( {      serverUrl : "{{ .Url }}",       token : "{{ .Token }}",      options: {        'sonar.projectName': "{{ .Project }}",        'sonar.projectDescription': 'Description for "{{ .Project }}" project...',        'sonar.sources': '.',        'sonar.projectKey': "{{ .Project }}",        'sonar.projectBaseDir': '/app'      }      },      () => process.exit()    )

В трёх первых строчках перечисляются переменные окружения, которые определяются, например, в GitLab CI/CD Variables. В дальнейшем, т.е. во время сборки/деплоя, эти переменные могут использоваться аналогично тому, как мы уже показывали в werf.yaml (через встроенную конструкцию werf).

Подробнее об определяемых переменных:

1. SONAR_TOKEN токен, который вы создаете в самом SonarQube; именно через него производится авторизация в SonarQube;
2. SONAR_PROJECT название созданного проекта в SonarQube;
3. SONAR_URL URL к SonarQube (может быть как внешним URL, так и адресом до сервиса).

В результате сборки (werf build) по таким конфигам (werf.yaml
и sonar.js) получается Docker-образ (под названием sonar-tests), который можно использовать для запуска Sonar-тестов, чем мы и займемся в следующей главе.

NB: Аналогичным образом можно собирать и запускать linting-тесты (речь не про что-то компилируемое), интеграционные тесты и т.д., причем даже в Kubernetes-окружении, а не только локально (в любом случае как минимум экономится место в основном образе).

Запускаем тесты с помощью команды werf run

Последний этап запуск тестов локально на GitLab Runner.

Для этого в GitLab CI/CD определяется отдельная Job, в которой будут запускаться тесты. Например:

Deploy sonar-tests:  script:    - werf run sonar-tests -- bash -c "node /app/sonar.js"  tags:    - werf  stage: deploy  environment:    name: sonar-tests  only:    - schedules  variables:    SONAR_TESTS: "yes"  after_script:    - echo "Scan results are here https://sonar/dashboard?id=${SONAR_PROJECT}"  when: always  dependencies:    - Build sonar-tests

Здесь используется единственная команда:

werf run sonar-tests -- bash -c "node /app/sonar.js"

В её первой части указывается название образа для запуска (sonar-tests, берётся из werf.yaml), во второй команда для выполнения внутри контейнера.

Теперь пайплайн будет запускать Sonar-тесты на GitLab Runner, а их результаты публиковать в SonarQube Dashboard.

Заключение

Описанный вариант запуска тестов в первую очередь будет полезен тем, кто уже использует werf или собирается его внедрить в своем проекте. С werf run можно выполнять тесты непосредственно на самом Runner'е и вместо отдельных Docker-инструкций описывать всё непосредственно в werf, аккумулируя подобные элементы в одном месте.

Этот подход, конечно, позволяет запускать не только SonarQube-тесты: подойдут и любые другие решения, не требующие создания отдельного окружения для них (в виде отдельного сервера БД, очередей сообщений и т.д.).

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

P.S.

Кстати, для разработчиков, только начинающих знакомиться с werf, мы подготовили увлекательный онлайн-самоучитель по этой утилите попробуйте!

Читайте также в нашем блоге:

• Из жизни с Kubernetes: Как мы выносили СУБД (и не только) из review-окружений в статическое;
• Организация распределенного CI/CD с помощью werf;
• Динамическая сборка и деплой Docker-образов с werf на примере сайта версионированной документации.