Как мы переехали на собственное хранилище репозиториев в GitLab CE

В один прекрасный летний день Atlassian не дал продлить платную подписку на наш облачный Bitbucket. Из-за этого наши разработчики больше не могли пушить изменения и создавать merge-реквесты. Все это грозило замедлить работу IT-компании Winfox на неопределенный срок. Поэтому мы быстренько развернули свое независимое локальное хранилище репозиториев в GitLab CE.

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

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

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

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

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

Самое нормальное бесплатное решение, которое есть на рынке и которое обладает всем необходимым доступным функционалом, — это GitLab CE. Под всем необходимым доступным функционалом мы понимаем следующее:

На следующий день после блокировки доступа к Bitbucket мы начали переезд на GitLab CE. Рассказываем по порядку.

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

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

Домен или поддомен. Они нужны изначально.

Установка на Ubuntu. Мы ставили GitLab на Ubuntu, использовали эту подробную инструкцию по установке.

Https в external_url. Обязательно ставьте https в external_url, так как GitLab умеет самостоятельно выпускать и использовать сертификаты от Let’s Encrypt. Если поставить https в external_url при установке, проблем в дальнейшем будет меньше.

Конфигурация ОС. Если локали на Linux не скофигурены должным образом, в процессе установки будут появляться ошибки. А именно невозможность поднять базу данных Postgres, локаль которой по умолчанию UTF-8.

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

После установки настало время сконфигурировать. Вот как делать изначальную настройку GitLab и как ее делали мы.

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

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

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

Еще одна проблема, которая у нас всплыла, — не все репозитории скопировались нормально. Из более чем 140 репозиториев один скопировался не полностью, поэтому пришлось вручную переносить ветки. Это затянуло процесс импорта.

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

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

В нашем процессе разработки вебхуки разделены по платформам/стеку. У других команд, например, они сгруппированы по проектам. Соответственно, надо сгруппировать репозитории. При этом путь к ним изменится. Именно поэтому до группировки не стоит раздавать доступы и скидывать URL репозиториев разработчикам, иначе им придется повторно менять эти URL у себя.

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

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

У нас вебхуки используются для информирования в каналах дискорда о коммитах, пушах и merge-реквестах. Соответствующим образом настраиваются вебхуки для групп репозиториев. Кстати, в Bitbucket Cloud сделать это без определенной прослойки у нас не получилось, а в GitLab CE это без проблем заработало из коробки.

Настройка пайплайнов. Теперь настраиваем пайплайны CI-CD на новом месте. Это долгий процесс — у нас ушла почти неделя.

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

На этом переезд на Gitlab CE закончен.

Теперь несколько слов про плюсы этого инструмента и примерный roadmap переезда.

Среди главных плюсов — экономия, независимость и широкие возможности кастомизации.

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

Важно. Чтобы возобновить работу команды на новых репозиториях, вам, скорее всего, потребуется 5-6 часов или 2-3 часа при хорошем раскладе.

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

На очереди — дальнейшее изучение возможностей GitLab CE и настройка новых интеграций, например интеграции с таск-трекерам, базами знаний, мониторингом Prometeus и рассылкой уведомлений через Pushover.