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

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

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

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

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

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

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

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

• безлимит репозиториев Git как по количеству, так и размерам;
• безлимит юзеров;
• CI/CD;
• вебхуки;
• интеграции с трекерами и прочими корпоративными системами;
• вменяемый процесс бэкапирования.

На следующий день после блокировки доступа к 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 на новом месте. Это долгий процесс — у нас ушла почти неделя.

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

• уведомление руководства о событиях в репозиториях: все коммиты, мердж-реквесты, операции с ветками уходят письмами руководству компании;
• интеграция с Sentry: получение инцидентов из веб-приложений в реальном времени и заведение их автоматом в GitLab;
• заведение инцидентов через почту: аналогично Sentry, но инциденты создаются из писем на определенный ящик.

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

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

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

• Экономия (внезапно). Мощный сервер под GitLab CE обошелся нам в 1,5 раза дешевле, чем мы платили за Bitbucket Cloud, а у нас не такая уж большая команда — GitLab используют 20 сотрудников. Для большой команды разница будет еще существеннее.
• Независимость от политики и прочих мировых событий. GitLab CE — независимый веб-инструмент. А если хотите максимально минимизировать риски, можно выделить железный сервер в своем дата-центре под это дело. (Правда, с учетом реалий современного мира все равно ничто не гарантирует сохранность и доступность этого дата-центра).
• Широкие возможности кастомизации. GitLab CE можно гибко настроить под себя, начиная от простой настройки до дописывания интеграционных прослоек. При этом возможностей гораздо больше, чем у самых дорогих облачных решений, например Bitbucket и GitHub.
• Это просто приятно)

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

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

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

• Мы переехали на GitLab CE, потому что Atlassian не дал продлить платную подписку на наш облачный Bitbucket.
• Изучив альтернативы Bitbucket, мы поняли, что при выборе любого из этих вариантов сохраняется риск недоступности сервиса в случае каких-либо проблем — мы рискуем снова потерять возможность пушить туда свои изменения, а то и доступ ко всему репозиторию.
• Мы решили развернуть свое локальное хранилище репозиториев в GitLab CE, чтобы сделать его полностью независимым от действий сторонних компаний.
• Переезд на GitLab CE состоит из трех основных этапов: установка, конфигурация, настройка.
• Перед установкой GitLab на корпоративном сервере убедитесь, что у вашего сервера не менее 8 Гб оперативной памяти и 2 ядра процессора с нормальным большим дисковым хранилищем, у вас есть домен или поддомен, https стоят в external_url, а локали на Linux скофигурены должным образом.
• Главное на этапе конфигурирования — максимально сократить время, за которое команда сможет полностью возобновить работы на новых репозиториях.
• В процессе конфигурирования нужно пройти регистрацию и импортировать репозитории.
  
• После импорта репозиториев самое время настроить вебхуки и прочие интеграции, например уведомление руководства о событиях в репозиториях, интеграцию с Sentry и заведение инцидентов через почту.
• Главные плюсы переезда на GitLab CE — экономия, независимость и широкие возможности кастомизации.
• Переезд на GitLab CE занял у нас примерно 2 недели 7 часов.

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