Доброго времени суток.
Я работаю Ruby разработчиком в стремительно растущей IT-компании. И вот однажды нами было принято стратегическое решение смены сервиса для работы с Git. Всех, кому интересно, прошу под кат.
До этого момента мы использовали gitolite. Немного подамся в историю и расскажу тем, кто не знает, что это за зверь такой.
Вот здесь официальный сайт: gitolite
Краткое описание с git-scm.com:
Неплохая статья на Хабре: Знакомство с gitolite
Если очень в кратце, то это небольшая консольная утилита для помощи обычным разработчикам максимально безболезнено настроить минимальную защиту своих репозиториев и репозиториев своей комманды.
Начнем по порядку. Вот базовый пример config-файла, взятый с оф. сайта:
В этих строках обьявляются наборы пользователей (@staff) и репозиториев (@projects):
Этот блок устанавливает уровень доступа к репозиториям в наборе projects, а так же репозиторию baz.
Так же в нем описаны права, а в частности, что для группы пользователей staff установлены права полного доступа.
В следующе строке указан запрет доступа к ветке master для пользователя ashok. Видимо, где-то он крепко накосячил :)
Ну и так далее… Все это хорошо описано в документации, и все желающие могут посмотреть там подробности.
Продолжим!
Это все хорошо, изящно и подвластно только настоящим специалистам. Однажды нам очень захотелось смотреть README файлы прямо в браузере, без парсинга глазами markdown. И вспомнили, что видели где-то standalone решение под названием GitLab.
Теперь плавно перейдем к этому замечательному инструменту!
Официальный сайт: GtiLab
Ироничный репозиторий с GitLab на GitHub: repo
Я не буду приводить тонны скринов и обьсянений, так как это хорошо развитый и огромный продукт, и вся информация в первозданном виде прекрасно изложена в описаниях и документации на сайте.
Если кратко, то это своеобразный аналог GitHub (пусть меня закидают помидорами). В нем используется модель разграничения прав схожая с GitHub. Главным отличием от gitolite стали так называемые namespaces. Если в gitolite мы явно указывали какой набор юзеров имеет доступ к репозиторию, то в GitLab проект должен находиться в определенном простанстве и соответственно это влияет на URL. Пример:
gitolite
GitLab (допустим проекту достался namespace ruby)
Собственно говоря это и стало самой навязчивой проблемой в нашем переезде, так как это требовало смены remote в локальных репозиториях разработчиков.
Что касается подписок у GitLab, тут есть несколько вариантов. Первый из них это CE — Community Edition — открытрый исходный код продукта и omnibus-установка. Собственно этот вариант мы и используем, развернув на своем железе. Тем более учитывая, что проект написан на Ruby, то ты можем свободно модифицировать требуемые файлы (ну по-крайней мере те, кто знают Ruby).
Так же есть Enterprise Edition — следуя из названия, становится понятно, что это версия для больших и мощных общин гуру разработки. Но она стоит денег, да и не особо нужна для наших целей, потому что CE версия выполняет все требуемые задачи на ура!
Но не о подписках речь. Я бы очень хотел описать то, что я считаю отлично реализованым и полезным (сугубо для меня) функционалом:
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 (см. ниже).
Но, честно говоря, не все прошло гладко. Был и один курьез.
Ситуация: репозиторий с размером ~50MB неожиданно обожрался и растолстел до ~18.5GB! 18.5GB, КАРЛ!.
Скажу сразу, корень зла мы так и не обнаружили. Могу сказать лишь что проблема была в том, что pack-файлы не очищались должным образом, и каждый новый pack-файл содержал в себе изменения репозитория и предыдущий pack-файл. И все это происходило после дождя в четверг, шутка, при выполнении push одним из разработчиков через интерфейс популярной IDE.
Но в итоге с помощью магии, а именно одной комманды, мы смогли решить проблему (если что, то выполнять в папке с репозиторием на сервере).
Не могу сказать, как и писал выше, в чем конкретно была проблема, но есть предположение, что мы сами накосячили при импорте проекта.
Так же я разработал набор rake тасков для переезда из gitolite в GitLab.
По сути, это переработаный стандартный таск для импорта в GitLab. Можно положить его в папку lib/tasks в 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 и запускать его оттуда.
Найти можно здесь.
Заключение. Опросник
Каким инструментом контроля версий пользуетесь вы? Ответ в комменты. Самые интересные я попробую у себя и может быть сделаю сравнение. Все новые инструменты очень стремительно развиваются, за всеми не успеешь.
