Для чего нужен гитлаб

Git для новичков (часть 1)

Что такое Git и зачем он нужен?

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

Репозиторием называют хранилище вашего кода и историю его изменений. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске.

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

Как работает

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

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

Установка

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

Но для начала, все же установим сам Git.

Windows. Проходим по этой ссылке, выбираем под вашу ОС (32 или 64 битную), скачиваем и устанавливаем.

Для Mac OS. Открываем терминал и пишем:

Linux. Открываем терминал и вводим следующую команду.

Настройка

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

Открываем терминал (Linux и MacOS) или консоль (Windows) и вводим следующие команды.

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

Теперь вы готовы к работе с Git локально на компьютере.

Создадим наш первый репозиторий. Для этого пройдите в папку вашего проекта.

Теперь Git отслеживает изменения файлов вашего проекта. Но, так как вы только создали репозиторий в нем нет вашего кода. Для этого необходимо создать commit.

Отлично. Вы создали свой первый репозиторий и заполнили его первым commit.

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

Не стоит после каждого изменения файла делать commit. Чаще всего их создают, когда:

Создан новый функционал

Добавлен новый блок на верстке

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

Вы завершили рабочий день и хотите сохранить код

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

Визуальный интерфейс

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

Но существуют и отдельные программы по работе с Git. Могу посоветовать эти:

Я не буду рассказывать как они работают. Предлагаю разобраться с этим самостоятельно.

Создаем свой первый проект и выкладываем на GitHub

Давайте разберемся как это сделать, с помощью среды разработки Visual Studio Code (VS Code).

Перед началом предлагаю зарегистрироваться на GitHub.

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

Установите себе дополнительно анализаторы кода для JavaScript и PHP

Откройте вашу папку, которую создали ранее

После этого у вас появится вот такой интерфейс

Здесь будут располагаться все файлы вашего проекта

Здесь можно работать с Git-ом

Кнопка для создания нового файла

Кнопка для создания новой папки

Давайте теперь перейдем во вкладу для работы с Git-ом.

Откроется вот такое окно:

Кнопка для публикации нашего проекта на GitHub

Вы создали и опубликовали репозиторий на GitHub.

Теперь сделаем изменения в коде и попробуем их снова опубликовать. Перейдите во вкладку с файлами, отредактируйте какой-нибудь файл, не забудьте нажать crtl+s (Windows) или cmd+s (MacOS), чтобы сохранить файл. Вернитесь обратно во вкладу управления Git.

Если посмотреть на значок вкладки Git, то можно увидеть цифру 1 в синем кружке. Она означает, сколько файлов у нас изменено и незакоммичено. Давайте его закоммитим и опубликуем:

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

Добавляем наш файл для будущего commit

Отправляем наш commit в GitHub

Поздравляю, вы научились создавать commit и отправлять его в GitHub!

Это первая вводная статья по утилите Git. Здесь мы рассмотрели:

Как его устанавливать

Как его настраивать

Как инициализировать репозиторий и создать commit через консоль

Как на примере VS Code, опубликовать свой код на GitHub

Забегая вперед, советую вам погуглить, как работают следующие команды:

P.S. Для облегчения обучения, оставлю вам ссылку на бесплатный тренажер по Git.

Источник

Введение в GitLab CI

Публикую перевод моей статьи из блога ГитЛаба про то как начать использовать CI. Остальные переводы гитлабовских постов можно найти в блоге компании Softmart.

Представим на секунду, что вы не знаете ничего о концепции непрерывной интеграции (Continuous Integration — CI) и для чего она нужна. Или вы всё это забыли. В любом случае, начнем с основ.

Представьте, что вы работаете над проектом, в котором вся кодовая база состоит из двух текстовых файлов. Более того, очень важно, чтобы при конкатенации этих файлов в результате всегда получалась фраза «Hello world.» Если это условие не выполняется, вся команда лишается месячной зарплаты. Да, все настолько серьезно.

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

Проблема в том, что в команде десять разработчиков, а человеческий фактор еще никто не отменял.

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

Запуск первого теста в CI

Добавляем, коммитим — и ура! Сборка успешна!

Поменяем во втором файле «world» на «Africa» и посмотрим, что получится:

Сборка неудачна, как и ожидалось.

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

Возможность загрузки результатов сборки

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

Все, что для этого нужно сделать — определить еще одну задачу для CI. Назовем ее «package»:

В результате появляется вторая вкладка

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

Проверяем… Все на месте:

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

Последовательное выполнение задач

Задача ‘package’ должна выполняться только при успешном прохождении тестов. Определим порядок выполнения задач путем введения стадий ( stages ):

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

Посмотрим на получившиеся артефакты:

Скачивание файла «compile» нам ни к чему, поэтому ограничим длительность жизни временных артефактов 20 минутами:

Итоговая функциональность конфига впечатляет:

Какие образы Docker лучше использовать

Прогресс налицо. Однако, несмотря на наши усилия, сборка до сих пор проходит медленно. Взглянем на логи:

Что, простите? Ruby 2.1?

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

Работа со сложными сценариями

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

А тем временем сборка не удалась:

Установка дполнительного ПО

Все это — тоже валидные команды CI. Полный список команд в разделе script должен выглядеть следующим образом:

А ведь мы только что создали конвейер! У нас есть три последовательные стадии, при этом задачи pack-gz и pack-iso стадии package выполняются параллельно:

Подводя итоги

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

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

Описания ключевых слов и ссылки на документацию

Также обратите внимание на другие примеры работы с GitLab CI:

Источник

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

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

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

Как работает GitLab
Самые важные функции:
1. создание отдельных веток от главной или так называемого «мастера», можно сказать, продакшн-версии проекта. Такое ветвление как бы создает копию, что позволяет эксперементировать, работая над разными участками кода, не затрагивая при этом исходный проект (откуда была создана ветка).
2. Когда вы довольны внесенными изменениями, можно отправить запрос на слияние. Запрос на слияние отправляется владельцу проекта, который может просмотреть внесенные вами изменения и задать любые дополнительные вопросы. Если владельца проекта все устраивает, он может объединить ваши изменения с исходным кодом.
3. подтягивание изменений с удаленного репозитория. Если код проекта обновился, все участники проекта смогут «подтянуть» изменения, то есть обновить проект до самой актуальной верии одной командой,

Работа с GitLab

1. СОЗДАНИЕ АККАУНТА

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

Если у вас еще нет аккаунта на gitlab нажмите «Register now» и заполните нужные поля. Далее нужно будет подтвердить регистрацию с помощью письма, которое будет отправлено вам на электронную почту.

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

2. СОЗДАНИЕ НОВОГО ПРОЕКТА/РЕПОЗИТОРИЯ

Чтобы создать новый проект нажмите «+«, который находится на верхней панели и нажмите «новый проект» («new project»):

Если поставить галочку напротив «Initialize repository with README», то проект инициализируется и создается файл README.txt. Делать это здесь не обязательно!

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

3. ПЕРЕНОС ПРОЕКТА НА УДАЛЕННЫЙ РЕПОЗИТОРИЙ GITLAB

Давайте создадим новый репозиторий на своем компьютере и перенесем его содержимое на GitLab. Так проект станет доступным для всех, кто является участником проекта.
Прежде всего репозиторий нужно создать и инициализировать командой «git»:

Создаем репозиторий с помощью командной строки (название репозитория пусть будет repo_name):

Переходим в репозиторий проекта:

Давайте создадим файл test_file.txt:

Теперь зафиксируем изменения(-m означает сообщение комита):

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

Чтобы проталкивания изменений в удаленный репозиторий нужно выполнить команду:

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

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

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

4. ДОСТУП ПО SSH-КЛЮЧУ

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

SSH-ключ создаётся с помощью команды:

Склонировать репозиторий по ssh-ключу

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

Переходим к локальному репозиторию (на вашем компьютере), удаляем https-адрес и добавляем скопированный ssh адрес:

Готово! Теперь есть доступ к проекту на gitlab по ssh-ключу. Логин и пароль вводить не надо.

5. РАБОТА С ВЕТКАМИ

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

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

Создать новую ветку можно двумя способами:
1. используя git:

2. используя интерфейс gitlab:

Кликаем по значку «+» и нажимаем «New branch«.

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

Проталкивание локальных изменений в удаленный репозиторий
Итак, представим, что мы сделали какие-то изменения в ветке «new-feature» (в данном случае добавили файл new_file).
Для того, чтобы эти изменения перенеслись в вашу ветку «new-feature» на удаленном репозитории нужно выполнить команды:

6. СЛИЯНИЕ ВЕТОК

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

Сделать это можно через интерфейс GitLab. Нужно нажать на кнопку «Create merge request«.

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

! все удаленные в сливаемой ветке файлы удалятся и в целевой ветке при слиянии, а измененные файлы заменят старые. Те файлы, которые вы не меняли останутся в прежнем состоянии.

7. ДОБАВЛЕНИЕ ПОЛЬЗОВАТЕЛЕЙ К ПРОЕКТУ

Как уже упоминалось, зачастую в репозитории работает не один человек, а целая команда. Для того, чтобы добавить к проекту разработчиков откройте настройки (Settings). Перейдите во вкладку Members. Здесь в окне Select или Invite member введите логин или email пользователей, которых хотите пригласить и выберете их роль в проекте выберите. Нажмите кнопу «Invite«.

Сохраняйте статью к себе на стену, чтобы не потерять ⬇

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всё это, а также многое другое, поддерживается 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 в удалённый репозиторий.

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

тут — ваше имя пользователя на GitLab.com.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

! Укажите

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Merge requests

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

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

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

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

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

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

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

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

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

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

Нажмите Submit merge request

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

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

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

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

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

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

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

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

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

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

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

! Нажмите кнопку 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, Plan, Code, Review и Staging, вы и получите примерно то самое заветное время для вывода на рынок (TTM).

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

Поздравляю!

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

Источник