гитлаб что это такое
Введение в 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.yml | Конфигурационный файл, в котором содержатся все определения сборки проекта |
| script | Определяет исполняемый shell-скрипт |
| before_script | Определяет команды, которые выполняются перед всеми заданиями |
| image | Определяет используемый Docker-образ |
| stage | Определяет стадию конвейера ( test по умолчанию) |
| artifacts | Определяет список артефактов сборки |
| artifacts:expire_in | Используется для удаления загруженных артефактов по истечению определенного промежутка времени |
| pipeline | Конвейер — набор сборок, которые выполняются стадиями |
Также обратите внимание на другие примеры работы с GitLab CI:
IPO GitLab: стоит ли спонсировать убытки программистов
На этой неделе на биржу выходит компания GitLab (NASDAQ: GTLB). В этом материале мы решили посмотреть, заслуживает ли она внимания инвесторов.
При создании материала использовались источники, недоступные пользователям из РФ. Надеемся, вы знаете, что делать.
Что тут происходит
Читатели давно просили нас начать разбирать отчетность и фундамент бизнеса иностранных эмитентов. Предлагайте в комментариях компании, разбор которых вам хотелось бы прочитать.
Часто при составлении отчетности компаний числа округляются, поэтому итоговые суммы в графиках и таблицах могут не сходиться. В разборе мы будем опираться на результаты компании за первые полгода 2021 года, так как выручка у компании растет очень быстро.
В статье есть скриншот таблицы из отчета. Чтобы было удобнее ею пользоваться, мы вынесли ее в гугл-таблицу и перевели на русский язык.
На чем зарабатывают
Основным источником сведений о компании для нас будет ее регистрационный проспект.
Выручка компании разделяется на следующие сегменты:
Выручка компании по регионам по результатам полугодия:
Среди ИТ-стартапов прибыльность считается грехом, что объясняет хроническую убыточность GitLab: по итогам первых 6 месяцев 2021 итоговая маржа составила −63,89% от выручки.
Взлетит?
Есть некоторые основания надеяться на успех как IPO, так и самой компании в долгосрочной перспективе.
Валовая маржа высока. Начнем с того, что у компании очень высокая валовая маржа — 88%. Большим плюсом GitLab видится крайне высокий уровень удержания выручки: он составляет 152% — это значит, что из имеющейся базы пользователей она извлекает денег так много, что это позволяет ей с лихвой компенсировать уход платных подписчиков. Однажды настанет момент, когда компания сможет начать сокращать расходы на отдел продаж, сжирающий сейчас большую часть денег, и выйти на прибыль.
Курс о больших делах
Перспективы. Бизнес компании выглядит довольно перспективным. GitLab благоприятствует несколько обстоятельств.
Стремительное распространение удаленной работы резко актуализировало вопрос о переводе значительной части операций различных отраслей в онлайн — это позволяет надеяться на загрузку программистов, которые будут активно пользоваться ПО компании. В известном смысле цифровизация активно шла и до пандемии, но теперь этот процесс форсируется как компаниями, так и государствами.
К слову, с самого начала работы весь штат GitLab работает на удаленке — и, не будь она убыточной, я бы даже сказал, что GitLab своим примером демонстрирует преимущества цифровизации.
Еще можно ожидать значительного роста инвестиций самых разных предприятий в ИТ: для повышения эффективности своего бизнеса. Например, в реальном секторе. Сейчас для этого складываются подходящие условия: с одной стороны, у компаний много денег и заказов, а с другой — нехватка ресурсов и дороговизна рабочей силы вынуждают корпоративный сектор искать долгосрочные решения. В принципе, это будет актуально и для сектора услуг, где многие предприятия страдают от нехватки рабочих рук.
Для американских предприятий это будет продолжением исторических традиций: инвестируя в новое оборудование и технологии на протяжении десятилетий, они значительно повысили продуктивность труда и возможность получать больше из имеющихся ресурсов, счастливо избежав необходимости серьезно увеличивать уровень зарплаты.
Сама GitLab предлагает в своем проспекте примеры того, как используют ее ПО ее клиенты из самых разных отраслей. Надо заметить, что все эти примеры сводятся к тому, как заказчик, используя ПО GitLab, разработал приложение или их комплекс, которые позволили ему выжимать больше из существующих мощностей.
Так что GitLab, пусть это и не вполне бросается в глаза, стоит в авангарде автоматизации.
IPO, традиции и банки. Компания проводит традиционное IPO, и ее андеррайтерами выступают Goldman Sachs, J. P. Morgan и прочие крупные банки. Учитывая, что нынче среди компаний пользуются популярностью методы выхода на биржу в обход банков типа DPO, инвестбанки-андеррайтеры заинтересованы в том, чтобы столь крупное IPO прошло удачно и акции выросли. Это значит, что они наверняка уже обзванивают своих клиентов, предлагая им «перспективный развивающийся стартап». В принципе, сейчас очень хорошее время для выхода на биржу, о чем свидетельствует статистика по IPO в США.
Не взлетит?
Но у GitLab есть слабые места, о которых обязательно нужно сказать.
Сама GitLab оценивает размеры своего целевого рынка в районе 40 млрд долларов. Занимая на нем примерно 0,54%, компания уже на старте претендует на то, чтобы стоить как 22,5% от него. В принципе, это стандартная айтишная схема, но в совокупности с убыточностью компании, как мне кажется, это предрасполагает к волатильности котировок.
Впрочем, убыточные и переоцененные ИТ-эмитенты Freshworks и Toast вполне успешно выступили на IPO: их котировки сильно выросли. GitLab, как компания схожего с ними размера, вполне может добиться результатов как минимум не хуже.
«Кому и кобыла невеста». Каждая убыточная ИТ-компания надеется найти прекрасного принца, который купит ее, решив все финансовые проблемы. Аналогичную компанию GitHub купила Microsoft в 2020 году за 7,5 млрд долларов. Не думаю, что GitLab кто-то купит со значительной премией к ее стартовой стоимости. Хотя я бы не стал совсем исключать этот вариант.
Неравные возможности. Конкуренция с упомянутым GitHub будет тормозить превращение компании в прибыльное предприятие. Аналитики обычно указывают на схожесть предложений, но главной проблемой мне видится, что за GitHub стоит сверхприбыльная и маржинальная Microsoft с практически бездонными карманами. Корпорация Билла Гейтса вполне может себе позволить тратиться на расширение GitHub.
За GitLab пока нет ничего, кроме ее наглости. Хуже всего, я думаю, что GitLab будет агрессивно расширяться путем как займов, так и эмиссии новых акций — первое по умолчанию плохо в преддверии подорожания кредитов, второе же может в теории сказаться на котировках не лучшим образом, особенно если не будет достаточного спроса на эти акции.
Классовая борьба. У компании будет 2 класса акций — A и B. Акции класса А дают голос на акцию, акции класса B дают 10 голосов. Как вы понимаете, акции класса B принадлежат нынешним владельцам компании и само их наличие устроено для того, чтобы владельцы компании могли диктовать свою волю остальным инвесторам. Возможно, это будет иметь неприятные последствия: например, компания может отказаться от продажи и решит самостоятельно расширяться, вплоть до банкротства.
Резюме
Что такое GitLab, как и для чего он используется
GitLab — это инструмент для хранения и управления репозиториями Git. Он дает возможность выполнять совместную разработку силами нескольких команд, применять обновления кода и откатывать изменения, если это необходимо.
Решение может работать на собственном сервере или в облаке. Для обоих случаев существуют полностью бесплатная версия и платные тарифы, стоимость которых зависит от функционала (подробнее о тарифах GitLab ниже).
В этой статье мы рассмотрим установку бесплатной версии GitLab Community Edition (GitLab CE) на сервер с Ubuntu 20.04 LTS x86_64, сравним GitLab с GitHub, разберемся с возможностями платных и бесплатных версий GitLab и расскажем как пользоваться GitLab. Но для начала подготовим выделенный сервер для разворачивания демо-стенда.
Чтобы создать сервер, откроем панель управления my.selectel.ru и перейдем в меню Серверы и оборудование, затем нажмем кнопку Заказать сервер.
В нашем примере для GitLab используется выделенный сервер фиксированной конфигурации EL09-SSD с процессором Intel Xeon E-2236, 16 Гб оперативной памяти, двух SSD-дисков по 480 Гб и операционной системой Ubuntu 20.04 LTS 64-bit.
После выбора сервера нажимаем кнопку Оплатить сейчас и ожидаем готовности сервера.
Примерно через 2 минуты физический сервер будет готов, а мы пока расскажем о возможностях Gitlab.
Возможности GitLab
Возможности GitLab делятся на следующие категории:
Мы расскажем про основные в каждой категории.
Управление
Планирование
Создание
Проверка
Упаковка
Безопасность
Релизы
Конфигурирование
Мониторинг
Защита
Полный список возможностей приведен на сайте GitLab. Там же можно узнать подробнее о каждой.
Как установить и настроить GitLab на Ubuntu
Пока вы узнавали о возможностях GitLab, сервер успешно установлен и готов к работе. Подключаемся по SSH к серверу, переходим в директорию /tmp и загружаем установочный скрипт репозиториев GitLab:
После загрузки скрипта, он необходимо добавить права на его исполнение:
Теперь скрипт готов к исполнению и можно его запускать:
После установки репозитория, можно запускать менеджер пакетов apt и начинать установку GitLab:
После выполнения установки, появится сообщение о готовности GitLab к работе:
Для доступа к GitLab через веб-интерфейс, его необходимо настроить. Для этого откроем для редактирования конфигурации в файле /etc/gitlab/gitlab.rb и укажем переменной external_url в качестве значения URL-адрес сервера.
В нашем демо вместо имени используется IP-адрес.
Теперь, чтобы новая конфигурация вступила в силу, необходимо выполнить реконфигурацию GitLab:
После окончания процесса конфигурации, откроется интерфейс GitLab и запрос на изменения пароля администратора.
После изменения пароля необходимо выполнить вход в GitLab:
GitLab полностью готов к работе и даже имеет тестовый проект.
Однако, GitLab по умолчанию работает по протоколу http. Чтобы переключить его на протокол https, необходимо изменить значения переменных letsencrypt[‘enable’], letsencrypt[‘contact_emails’] и в переменной external_url указать протокол https:
После внесения изменений в конфигурацию, выполним реконфигурацию GitLab:
После реконфигурации GitLab, появится возможность подключаться к веб-интерфейсу по протоколу https.
Если GitLab установлен во внутренней сети и к нему требуется доступ извне, одним из вариантов организации такого доступа может быть настройка проксирования на nginx-сервере (или proxy_pass) с установкой на него ключа Let’s Encrypt. В этом случае в настройках GitLab можно спокойно оставлять доступ по протоколу http.
Иногда, при попытке доступа через веб-интерфейс, GitLab возвращает ошибку 502. Причины могут быть разные, но основные это: нехватка оперативной памяти, остановка службы gitlab-workhorse и изменение прав доступа к файлу /var/opt/gitlab/gitlab-workhorse/socket. В первом случае проблему решит добавление оперативной памяти, во втором перезагрузка сервисов GitLab, а в третьем предоставление сервису nginx доступа к файлу.
Как работать с GitLab
Чтобы упростить работу с репозиториями из командной строки, необходимо добавить собственные ssh-ключи в GitLab. Генерируем пару ssh-ключей:
Следующий шаг — вывод содержимого публичного ключа и его копирование в буфер обмена:
В интерфейсе GitLab перейдем в раздел Settings:
Далее в раздел SSH Keys, где нужно вставить скопированный ключ. После этого можно нажать Add key.
Появится следующий экран:
На этом настройка к репозиториям через SSH-ключ завершена и пришло время создать новый проект. Для этого достаточно нажать на + в центральной части экрана и далее на New project.
Проекту нужно присвоить имя, а также выбрать тип проекта:
В первом случае проект будет доступен только вам, во втором всем пользователям данной инсталляции GitLab, в третьем случаем всем подряд и без авторизации.
Нажимаем на кнопку Create project:
После создания проекта можно перейти к его настройке. Например, на представлении Members в проект можно пригласить новых пользователей с различными ролями: Guest, Reporter, Developer, Maintainer:
Основы GitLab — это работа с репозиториями. Теперь загрузим в этот проект имеющийся на рабочей станции git-репозиторий. Для начала добавим ссылку на удаленный репозиторий:
Теперь загрузим репозиторий в GitLab:
Теперь через веб-интерфейс GitLab можно просмотреть исходный код локального репозитория:
GitLab позволяет также загружать исходный код обратно на рабочую станцию. Для этого нужно выполнить следующую команду:
Другой вариант загрузки — через веб-интерфейс. Для этого на странице проекта необходимо нажать кнопку ↓ и выбрать формат загружаемого архива:
Теперь разберемся, как в GitLab работать с ветками репозитория. По умолчанию работа ведется в ветке master и все предыдущие действия мы выполняли именно в ней. Для реализации изменений и их отслеживание, разработчику важно иметь собственную ветку, код из которой в дальнейшем можно будет передать в master-ветку.
Чтобы создать новую ветку, достаточно в выпадающем меню рядом с символом + нажать на пункт меню New branch:
Новую ветку также можно создать в локальном репозитории Git и затем загрузить её в GitLab. В веб-интерфейсе появится соответствующая запись о новой ветке.
Мы создали в проекте новую ветку development. В меню Settings — Repository можно выбрать ветку, используемую по умолчанию. После выбора нужно нажать на кнопку Save changes.
Поскольку разработка чаще всего ведется в нескольких ветках, в определенный момент времени появится необходимость выполнить их слияние. Cлияние веток — основа GitLab. В GitLab для реализации этого процесса предназначены запросы на слияние (Merge requests). Создадим в локальном репозитории новую ветку и назовем ее staging:
Создадим новый файл в репозитории и запишем туда произвольный текст:
Добавим этот файл к репозиторию:
Выполним коммит с комментарием:
И, наконец, загрузим новую ветку в GitLab:
Теперь можно проверить наличие новой ветки staging в интерфейсе GitLab. Перейдем в раздел Repository — Branches и обнаружим созданную ветку. Если перейти в нее, там будет созданный на предыдущих шагах файл new-staging.txt.
Перейдем в эту ветку и нажмем кнопку Create merge request:
Здесь нужно указать название слияния, его описание и, при необходимости, выбрать опцию уведомления заинтересованных пользователей. В нижней части этого экрана нужно нажать кнопку Submit merge request:
На следующем экране можно опционально нажать Approve, а затем нажать Merge:
Слияние веток репозитория выполнено.
Чем отличаются GitLab и GitHub
На специальной странице GitLab есть целая таблица сравнения в разрезе тех возможностей, о которых мы рассказывали в начале статьи. Ко всему этому можно добавить, что GitHub появился на 3 года раньше GitLab и является неким стандартом хранения репозиториев решений с открытым исходным кодом. А еще GitHub — полностью облачное решение, GitLab же может работать на локальном сервере или в облаке.
Использование того или иного инструмента обычно основано на предпочтениях людей, принимающих соответствующие решения. С каждым годом GitLab догонял по функционалу GitHub и сейчас уже во многом его превосходит.
Если говорить про отличия тарифов на GitLab и GitHub, оба решения имеют бесплатный тариф с возможностями использования приватных репозиториев. Все последующие тарифы оплачиваются в зависимости от количества пользователей в системе.
Какие существуют версии и тарифы GitLab
GitLab имеет две версии — Community Edition (CE) и Enterprise Edition (EE). У первой (именно ее мы устанавливали в этой статье) полностью открытый исходный код, а вторая построена на базе первой, но имеет дополнительные функции, код которых, увы, не открыт для всех желающих. Версия EE также бесплатная в базовой комплектации и производитель рекомендует использовать именно её, если планируется дальнейший переход на платные тарифы.
Линейка тарифов представлена на скриншоте ниже. Цена за пользователя зависит от тех функций, которые включены в подписку.
Ключевой особенностью подписок уровня Premium и Ultimate является поддержка производителя в режиме 24/7. По этой ссылке можно получить полное представление о возможностях каждой из подписок.
Заключение
Мы рассмотрели ключевые возможности GitLab. и основные моменты при установке и работе с этим инструментом. Самая полная документация доступна на странице производителя. Продукт активно развивается и его использование оправдано в проектах любой величины.