Новый дом для репозитория или история переезда на GitLab

Доброго времени суток.
Я работаю Ruby разработчиком в стремительно растущей IT-компании. И вот однажды нами было принято стратегическое решение смены сервиса для работы с Git. Всех, кому интересно, прошу под кат.

Часть 1. Начало


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

Вот здесь официальный сайт: gitolite

Краткое описание с git-scm.com:

Gitolite представляет собой дополнительную прослойку поверх Git’а, обеспечивающую широкие возможности по управлению правами доступа.

Неплохая статья на Хабре: Знакомство с gitolite

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

Начнем по порядку. Вот базовый пример config-файла, взятый с оф. сайта:

# sample conf/gitolite.conf file

@staff              =   dilbert alice           # groups
@projects           =   foo bar

repo @projects baz                              # repos
    RW+             =   @staff                  # rules
    -       master  =   ashok
    RW              =   ashok
    R               =   wally

    option deny-rules           =   1           # options
    config hooks.emailprefix    = '[%GL_REPO] ' # git-config

В этих строках обьявляются наборы пользователей (@staff) и репозиториев (@projects):

@staff              =   dilbert alice           # groups
@projects           =   foo bar

Этот блок устанавливает уровень доступа к репозиториям в наборе projects, а так же репозиторию baz.
Так же в нем описаны права, а в частности, что для группы пользователей staff установлены права полного доступа.
В следующе строке указан запрет доступа к ветке master для пользователя ashok. Видимо, где-то он крепко накосячил :)

repo @projects baz                              # repos
    RW+             =   @staff                  # rules
    -       master  =   ashok
    RW              =   ashok
    R               =   wally

Ну и так далее… Все это хорошо описано в документации, и все желающие могут посмотреть там подробности.

Часть 2. Новая надежда


Продолжим!

Это все хорошо, изящно и подвластно только настоящим специалистам. Однажды нам очень захотелось смотреть README файлы прямо в браузере, без парсинга глазами markdown. И вспомнили, что видели где-то standalone решение под названием GitLab.

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

Официальный сайт: GtiLab

Ироничный репозиторий с GitLab на GitHub: repo

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

Если кратко, то это своеобразный аналог GitHub (пусть меня закидают помидорами). В нем используется модель разграничения прав схожая с GitHub. Главным отличием от gitolite стали так называемые namespaces. Если в gitolite мы явно указывали какой набор юзеров имеет доступ к репозиторию, то в GitLab проект должен находиться в определенном простанстве и соответственно это влияет на URL. Пример:

gitolite

git@git.yourcompany.com:some_repo

GitLab (допустим проекту достался namespace ruby)

git@git.yourcompany.com:ruby/some_repo

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

Что касается подписок у GitLab, тут есть несколько вариантов. Первый из них это CE — Community Edition — открытрый исходный код продукта и omnibus-установка. Собственно этот вариант мы и используем, развернув на своем железе. Тем более учитывая, что проект написан на Ruby, то ты можем свободно модифицировать требуемые файлы (ну по-крайней мере те, кто знают Ruby).

Так же есть Enterprise Edition — следуя из названия, становится понятно, что это версия для больших и мощных общин гуру разработки. Но она стоит денег, да и не особо нужна для наших целей, потому что CE версия выполняет все требуемые задачи на ура!

Часть 3. Benefits


Но не о подписках речь. Я бы очень хотел описать то, что я считаю отлично реализованым и полезным (сугубо для меня) функционалом:

1. Наличие Issues для проектов. Да-да, на GitHub есть, но теперь это на нашем внутреннем сервере.
2. Работы с Merge Requests. Не всегда используем, но графическое предсталвение гораздо удобнее просмотра кода в консоли.
3. Snippets — аналог Gist. Опять таки, зато свое.
4. GitLab CI — замечательный инструмент для Continuous Integration. Ставится из коробки, напрямую интегрирован с вашей системой версионизации, и поддержка Docker по умолчанию.
5. Deploy keys в проектах — ключи для чтения репозитория во время деплоя (например в связке с Capistrano). В gitolite для этих целей создавался отдельный пользователь с правами на чтение.
6. Service Templates — набора подготовленных настроек для интеграции с кучей сервисов (JIRA, Asana, HipChat и т.д.)
7. Использование GitLab в качестве SaaS — бесплатно. Отличная альтернатива Bitbucket. Спойлер, но кое-что я уже выложил на GitLab (см. ниже).

Часть 4. Реалность


Но, честно говоря, не все прошло гладко. Был и один курьез.

Ситуация: репозиторий с размером ~50MB неожиданно обожрался и растолстел до ~18.5GB! 18.5GB, КАРЛ! .

Скажу сразу, корень зла мы так и не обнаружили. Могу сказать лишь что проблема была в том, что pack-файлы не очищались должным образом, и каждый новый pack-файл содержал в себе изменения репозитория и предыдущий pack-файл. И все это происходило после дождя в четверг, шутка, при выполнении push одним из разработчиков через интерфейс популярной IDE.

Но в итоге с помощью магии, а именно одной комманды, мы смогли решить проблему (если что, то выполнять в папке с репозиторием на сервере).

git gc --auto

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

Часть 5. Вклад


Так же я разработал набор rake тасков для переезда из gitolite в GitLab.
По сути, это переработаный стандартный таск для импорта в GitLab. Можно положить его в папку lib/tasks в GitLab и запускать его оттуда.

Найти можно здесь.

Заключение. Опросник


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

© Habrahabr.ru