В последнее время разработчики платного и даже бесплатного программного обеспечения закрывают доступ к своим продуктам пользователям и компаниям из России. А ведь для IТ-компаний проблемы с тем же трекером или хранилищем репозиториев грозят частичной или полной остановкой работы. В зоне повышенного риска — распределенные команды, для которых данные системы — место силы всей компании.
На связи Саша Хрущев, технический директор IT-компании WINFOX. Рассказываю, как мы быстренько развернули свое независимое локальное хранилище репозиториев в GitLab CE, сколько времени это заняло и какие особенности вам нужно учитывать при переезде, чтобы все прошло гладко.
Как все началось
В один прекрасный летний день Atlassian не дал нам продлить платную подписку на наш облачный Bitbucket. Из-за этого наши разработчики больше не могли пушить свои изменения и создавать merge-реквесты. Все это грозило замедлить нашу работу на неопределенный срок.
Подумав про себя «А нас-то за что?..», мы бросились искать варианты продления подписки. Это оказалось напрасно: варианты с VPN и прочими хитростями не сработали, и мы просто потратили наше драгоценное время впустую. Плюс все понимали: даже если сейчас этот фокус прокатит, то уже завтра ситуация гарантированно повторится.
Решение нужно было принимать очень быстро, так как любая проволочка грозила прямыми финансовыми потерями.
Мы поискали различные облачные альтернативы Bitbucket, включая отечественные облачные репозитории. Изучив доступные сервисы, поняли, что при выборе любого из этих вариантов сохраняется риск недоступности сервиса в случае каких-либо проблем. То есть мы рискуем снова потерять возможность пушить туда свои изменения, а то и доступ ко всему репозиторию.
В общем, мы решили разворачивать свое локальное хранилище репозиториев и сделать его полностью независимым от действий сторонних компаний.
Почему мы выбрали GitLab CE
Самое нормальное бесплатное решение, которое есть на рынке и которое обладает всем необходимым доступным функционалом, — это GitLab CE. Под всем необходимым доступным функционалом мы понимаем следующее:
безлимит репозиториев Git как по количеству, так и размерам;
безлимит юзеров;
CI/CD;
вебхуки;
интеграции с трекерами и прочими корпоративными системами;
вменяемый процесс бэкапирования.
На следующий день после блокировки доступа к Bitbucket мы начали переезд на GitLab CE. Об этом по порядку.
Этап 1. Установка
Прежде всего надо было установить 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.
Если вы столкнулись с подобным, помогут уже расписанные решения. Вот одно из таких решений.
Этап 2. Конфигурация
После установки настало время сконфигурировать. Немного расскажу, как делать изначальную настройку GitLab и как ее делали мы.
Главное на этом этапе — минимизировать время, за которое команда сможет полностью возобновить работы на новых репозиториях.
Регистрация. Чтобы ускорить регистрацию всех членов команды, мы оставили открытой регистрацию на главной странице.При этом мы ограничили возможности регистрации по строго определенному доменному имени e-mail. Таким образом, вся команда зарегистрируется сама, нам же останется сделать аппрув и доступы, после чего открытую регистрацию можно закрывать.
Импорт репозиториев. Пока команда регистрируется, импортируем репозитории. Этот процесс специфический для каждого из облачных репозиториев, но он подробно описан в документации для GitLab.
Большая часть репозиториев нормально импортируется автоматом, однако GitLab автоматически неправильно ставит имена репозиториев в которых есть «_» (нижнее подчеркивание). В сложных именах репозиториев вместо этого символа появляется пробел и система не может импортировать эти репозитории. Для таких репозиториев надо будет руками ввести нормальное имя, что немного задержит автоматический импорт.
Еще одна проблема, которая у нас всплыла, — не все репозитории скопировались нормально. Из более чем 140 репозиториев один скопировался не полностью, поэтому пришлось вручную переносить ветки. Это затянуло процесс импорта.
Этап 3. Настройка
После импорта репозиториев не стоит сразу раздавать доступы и приступать к работе. Если вам надо настроить вебхуки или прочие интеграции, самое время это сделать.
Группировка вебхуков. Для правильной настройки вебхуков надо правильно сгруппировать проекты.
В нашем процессе разработки вебхуки разделены по платформам/стеку. У других команд, например, они сгруппированы по проектам. Соответственно, надо сгруппировать репозитории. При этом путь к ним изменится. Именно поэтому до группировки не стоит раздавать доступы и скидывать URL репозиториев разработчикам, иначе им придется повторно менять эти URL у себя.
Раздача доступов. Как только группировка закончена, можно возобновлять работу с репозиторием и раздавать разработчикам доступы.
Можно считать, что с этого момента работа команды продолжится в нормальном режиме. Нам же ничто не мешает продолжать настройку.
Настройка вебхуков. После того, как мы перенесли все репозитории и раздали доступы, переходим к настройке GitLab, то есть настройке вебхуков.
У нас вебхуки используются для информирования в каналах дискорда о коммитах, пушах и merge-реквестах. Соответствующим образом настраиваются вебхуки для групп репозиториев. Кстати, в Bitbucket Cloud сделать это без определенной прослойки у нас не получилось, а в GitLab CE это без проблем заработало из коробки.
Настройка пайплайнов. Теперь настраиваем пайплайны CI-CD на новом месте. Это долгий процесс — у нас ушла почти неделя.
Настройка других полезных фич. Далее мы настроили несколько полезных вещей, которых не было ранее. Вот они:
уведомление руководства о событиях в репозиториях: все коммиты, мердж-реквесты, операции с ветками уходят письмами руководству компании;
интеграция с Sentry: получение инцидентов из веб-приложений в реальном времени и заведение их автоматом в GitLab;
заведение инцидентов через почту: аналогично Sentry, но инциденты создаются из писем на определенный ящик.
На этом переезд на Gitlab CE закончен.
Бонусом скажу про плюсы этого инструмента и покажу примерный roadmap переезда исходя из опыта.
Плюсы переезда на GitLab CE
Среди главных плюсов — экономия, независимость и широкие возможности кастомизации.
Экономия (внезапно). Мощный сервер под GitLab CE обошелся нам в 1,5 раза дешевле, чем мы платили за Bitbucket Cloud, а у нас не такая уж большая команда — GitLab используют 20 сотрудников. Для большой команды разница будет еще существеннее.
Независимость от политики и прочих мировых событий. GitLab CE — независимый веб-инструмент. А если хотите максимально минимизировать риски, можно выделить железный сервер в своем дата-центре под это дело. (Правда, с учетом реалий современного мира все равно ничто не гарантирует сохранность и доступность этого дата-центра).
Широчайшие возможности кастомизации. GitLab CE можно гибко настроить под себя, начиная от простой настройки до дописывания интеграционных прослоек. При этом возможностей гораздо больше, чем у самых дорогих облачных решений, например Bitbucket и GitHub.
Это просто приятно)
Примерный roadmap переезда на GitLab CE
Я посчитал, сколько времени занял переезд у нас. Это поможет вам спланировать время в своей команде.
Важно. Чтобы возобновить работу команды на новых репозиториях, вам, скорее всего, потребуется 5-6 часов или 2-3 часа при хорошем раскладе.
Полностью продублировать функционал своего предыдущего хранилища репозиториев, включая вебхуки и интеграции, вы сможете в течение 1-2 недель.
Что дальше
На очереди — дальнейшее изучение возможностей GitLab CE и настройка новых интеграций, например интеграции с таск-трекерам, базами знаний, мониторингом Prometeus и рассылкой уведомлений через Pushover.
Если интересно про это почитать, пишите в комментариях — буду рад поделиться опытом.
