Доброго времени суток.
Я работаю 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 и запускать его оттуда.

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

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


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

Комментарии (54)


  1. FRWHate
    04.04.2016 23:54
    +5

    Попробуй Gogs. Написан на Go и ввиду этого быстрее и жрёт оперативы поменьше
    gogs.io


    1. mxgoncharov
      04.04.2016 23:54
      -1

      Оу. Люблю Go. Посмотрю. Спасибо)


    1. SL_RU
      05.04.2016 00:32

      Нам тоже gogs больше понравился.
      После нескольких месяцев использования gitlab'a попробовали его, да и переехали. Он простой, быстрый и нет всяких ненужных нам лишностей. И ещё опенсорсный.


      1. mxgoncharov
        05.04.2016 00:33

        На GitLab мы не так давно переехали, и пока очередной переезд точно не грозит. Но для себя я точно Gogs изучу.
        А если не секрет, что именно сподвигло уйти с gitlab'a?


        1. voidnugget
          05.04.2016 00:37
          +1

          Количество сожранной рельсами оператвы и вечные подтекания sidekiq'a.
          Довольно сложная установка и потребность в RVM'e.


          1. creker
            05.04.2016 12:00
            +1

            Вы из сорсов что ли ставили? Куда проще из пакетов ставить. Тогда gitlab устанавливается и обновляется в один клик. Проще некуда его администрировать.


            1. voidnugget
              05.04.2016 12:42

              Я не ленюсь в этом плане — у готовых omnibus'ов есть свои недостатки, особенно что касается экстренных обновлений Ruby и всяких Security патчей. Количество съеденной оперативки от способа установки не зависит. В omnibus'e те же исходники и теже init скрипты, и тот же костыль на перезапуск sidekiq по таймауту и в случае съедения всей памяти.

              Единственной причиной по которой я до недавних пор пользовался gitlab'ом являлось наличие хорошего ci.
              Сейчас же можно спокойно пользоваться https://github.com/drone/drone c gogs'ом.


              1. creker
                05.04.2016 13:01
                +1

                Gitlab сами быстро патчат уязвимости, так что недостаток этот отпадает. А все остальное не причиняет мне неудобств. Оно просто работает и работает хорошо, им удобно пользоваться, дофига функционала. Собственно, ничего лучше Gitlab на рынке и нет. Только платные решения.


            1. pav5000
              05.04.2016 15:31

              Можно еще проще, запустив официальный докер-контейнер.


              1. Sys_Admin
                05.04.2016 21:34

                github.com/sameersbn/docker-gitlab гораздо функциональнее.


          1. Botkin
            06.04.2016 10:25

            GitLab сейчас ставится и обновляется при помощи apt-get install gitlab-ce


    1. zelenin
      05.04.2016 01:58

      я безуспешно пытался несколько раз завести на своем digitalocean docker с гитлабом, но ему не хватает самого дешевенького тарифа, т.к. прожорлив он весьма.
      Около пары месяцев назад открыл для себя gogs — это чудо. Весь базовый функционал есть, а памяти жрет в десятки раз меньше. Только что поднятый инстанс, если не ошибаюсь, занимал всего 8 мб памяти (гитлабу не хватало 512-ти).
      В общем присоединяюсь и советую.


    1. pav5000
      05.04.2016 15:33
      +1

      Выглядит вкусно, а какой-нибудь CI имеется, чтобы тоже на Go и легко интегрировался с gogs?


  1. Zapped
    05.04.2016 00:00

    две беды у GitLab'а есть. как только встречаются:

    1. не-UTF8 кодировка имён файлов
    2. не-UTF8 кодировка содержимого файлов
      то тут-то он и не справляется

    и если первое можно победить одномоментной миграцией, переименовав файлы
    то со второй у него долгая и, судя по всему, так и не исправленная, история…
    а патчить каждую версию (или, тем более, просить админов) — увольте


    1. mxgoncharov
      05.04.2016 00:32

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


      1. Zapped
        05.04.2016 00:35

        да в том-то и дело, что поднимался, и не раз )) только предлагавшейся настройки "кодировка файлов" так и нет )
        З.Ы. GitLab юзает gem charlock-holmes, который автоопределяет кодировку, но на малом объёме входного текста — неверно


        1. btd
          05.04.2016 08:42

          chalock-holmes использует libmagic, ее же использовал ранее гитхаб, он тоже на ваших данных не работает?


          1. Zapped
            05.04.2016 09:00

            Без понятия. У меня уже нет времени (да и желания особо) ещё раз разворачивать GL, чтобы это проверить.
            Есть простой синтетический тест проверить libmagic?


            1. btd
              05.04.2016 09:11

              Скорее всего команда file может выдавать кодировку (вообще там довольно ограниченный набор). По хорошему вместо libmagic они должны были использовать icu chardet или mozillaовский uchardet.
              Еще неплохой идей было бы поддерживать файлик на подобии .gitignore или ini где указывались бы глобы и соответствующие кодировки.


              1. Zapped
                05.04.2016 13:41

                Еще неплохой идей было бы поддерживать файлик на подобии .gitignore или ini где указывались бы глобы и соответствующие кодировки.

                уже всё есть
                .gitattributes encoding
                только что до этого GitLab'у? )


                1. btd
                  05.04.2016 13:49

                  .gitattributes это тема, не знал про этот файлик. Спасибо огромное!
                  Интересно, хоть какой нибудь хостинг реп его использует?


    1. oYASo
      05.04.2016 00:34

      Что за проблемы?
      В свое время пару лет сидели на чисто Open Source версиях (когда Enterprise еще не было) — никаких проблем, полет отличный.
      Уже давно ушли на стек продуктов Atlassian, но, чисто субъективно, GitLab бегал намного шустрее и жрал на серваке куда меньше ресурсов.


      1. mxgoncharov
        05.04.2016 00:37

        Я использовал для pet'ов Bitbucket, но по ощущениям как-то GitLab приятнее. Хотя я не нашел супер-отличий. Может дело в том, что Atlassian это все таки по большей части enterprise сегмент, и в нем мало духа авантюризма)


        1. oYASo
          05.04.2016 02:49
          +2

          Ну когда есть все эти Jira, Bamboo, Confluence, Crucible и прочее, проще и быстрее развернуть BitBucket и в пару кликов их подружить.
          Да простят меня адепты Java, но у меня аллергия на продукты, написанные этим языком. Если Java, то это сразу надо выделять тонны оперативки и несколько процов, сразу чувствуется какая-то неповоротливость и задумчивость. Но увы и ах, весь интерпрайз на нем, приходится страдать со всеми.


          1. grossws
            05.04.2016 10:05
            +1

            Скажите спасибо поголовью индусов, которые пишут это так дешево. Со всеми вытекающими требованиями к памяти и cpu. Хотя на руби тоже относительно прожорливые поделия получаются.
            Тот же youtrack работает шустро и довольно удобен. Хотя тоже на яве (возможно, частично, и на котлине, не знаю).


            1. oYASo
              05.04.2016 16:51

              Дык я же не спорю. Мало того, тенденция продолжается, так что дальше только хуже будет (или лучше, тут смотря с какой стороны смотреть).

              Jira/BitBucket тоже относительно шустро работает, если ресурсов выделить. Но тот же GitLab с той же командой наших разработчиков комфортно работал (да и работает, на самом деле — мы просто его не поддерживаем) при десятикратно меньшей выделенной оперативы. У нас внутренних железок хватает с избытком, так что никаких проблем нет, но вот для других команд тут может быть проблема.


      1. Zapped
        05.04.2016 02:46

        проблема отображения diff'ов файлов в кодировке, отличной от UTF-8 (привет из Windows),
        также их имён (привет из Cygwin), ну и текстов сообщений коммитов


        1. oYASo
          05.04.2016 02:51

          Хоть один аргумент в пользу неиспользования UTF-8?
          Сами вот уже три в пользу назвали.


          1. Zapped
            05.04.2016 08:56

            Есть один… мощный: legacy


            1. oYASo
              05.04.2016 16:56

              Сорцы-то зачем в непонятных кодировках держать?

              Я тоже работал со всякими лохматыми МСВС, где koi8-r (на Linux, черт возьми!) поставлена по умолчанию. Ну это не повод самому говнокодить и держать все в непонятно чем.


              1. Zapped
                05.04.2016 17:09
                +1

                а кто говорит про «самому»?
                я же сказал: legacy! на 200000 строк кода основного проекта (без учёта библиотек)
                IDE 10-тилетней давности, без поддержки Юникода
                миграция на «современную IDE» = время = деньги, их ни у кого на это нет


        1. xRay
          06.04.2016 08:39

          Тоже примерно таким https://github.com/xRayDev/gitlab_windows1251/commit/ac65ae9bbafe528566324e6065bf867658ec4dec костылем пользуетесь?


          1. Zapped
            06.04.2016 10:39

            да-да, только
            мы так и не пользуемся, ибо на тот момент, когда я тестил GL, были ещё баги
            PR мой отвергли ))
            а поддерживать патчи после обновлений мне не улыбалось )
            так что пока gitolite…
            но лёгкого управления доступом к проектах, уведомления, построчных комментов к коммитам хотелось бы ))


            1. xRay
              06.04.2016 10:48

              Надо посмотреть упомянутый в комментариях Gogs. Может у него с этим проблем нет.


              1. Zapped
                06.04.2016 10:53

                надо )) но сомневаюсь ))
                сейчас «все» почему-то думают, что UTF-8 единственная возможная кодировка ))


          1. Zapped
            06.04.2016 10:52

            1. xRay
              06.04.2016 11:40

              Хе всего одна строчка :)
              Еще пачте правится второй файлик и там точно такой же баг в геме gitlab_git от разработчиков GitLab.


              1. Zapped
                06.04.2016 11:47

                кругом костыли ))
                я тут надысь на похожую тему FlexGet фиксил ))
                там, правда, ситуация в обратную сторону ))) текст приходит в UTF-8, а его перекодируют в latin1 зачем-то


    1. xRay
      05.04.2016 16:09

      Да. Так есть. Накладываю патч (в пару строк на два файла) на каждую. Версию GitLab.
      И у GitHub та же самая проблема имеется.


  1. StamPit
    05.04.2016 01:23
    +3

    А ведь изначально же gitlab, если мне не изменяет память, был как раз веб-интерфейсом для gitolite, так что переезд для нас (5Gb репозиторий, большая часть — PHP) был безболезненным.
    Но самый большой плюс GL — это потрясающая документация, спасибо dzaporozhets и команде GL за это.


    1. mxgoncharov
      05.04.2016 07:34

      Да. Вы правы. Я тоже помню когда GL был еще на gitolite. Но как по мне, если реально нужен подобный инструмент, то gitolite — пережиток прошлого, ИМХО.


  1. mjr27
    05.04.2016 01:39

    А подскажите, мэтры гитлаба, какой issue tracker к нему наиболее кошерно подключается? Встроенный, конечно, не ужас-ужас, но всё-таки ужас.
    Хочу категории и нормальный flow для тасков (открыта, заассайнена, оттестирована и т.п) хотя бы.


    1. StamPit
      05.04.2016 02:21
      +1

      В зависимости от того, что Вам надо. Jira и Redmine (используем второй)


    1. Botkin
      06.04.2016 10:27

      Мы YouTrack вполне успешно юзаем
      confluence.jetbrains.com/display/YTD65/Integration+with+GitLab


  1. norlin
    05.04.2016 09:38

    Каким инструментом контроля версий пользуетесь вы?
    На нынешнем месте работы – CVS.
    :trollface:


    1. vayho
      05.04.2016 10:46

      -не туда-


  1. vayho
    05.04.2016 10:54

    Еще есть https://github.com/gitbucket/gitbucket для JVM.


  1. Godless
    05.04.2016 11:04

    а вы пробовали/смотрели scmmanager? Развернули его на работе и дома для домашних проектов — очень нравится. У нас правда, команда не большая, но проектов около 20. Единственное но — оно на java. Пока нареканий не было...


    1. SabMakc
      05.04.2016 11:49

      Стоит добавить, что SCM-Manager работает не только с Git, но и с Mercurial / SVN.


  1. Amomum
    05.04.2016 12:14

    Мы используем gitblit. Выбрали его в основном из-за возможности создавать сложную иерархию проектов на сервере. Основные недостатки (для нас), то что по этой иерархии не очень удобно ходить и создавать новые репы. Она в общем списке всегда полностью развернута :)
    Но в целом норм.


  1. dmitry_no
    05.04.2016 14:34

    Есть ещё rhodecode.com. Управляет правами доступа на уровне пользователей, групп или отдельных репозиториев (Git, Subversion и Mercurial). Бонусом — code review функционал и интеграция с issue trackers/CI. Бесплатный до 25 пользователей.


    1. SabMakc
      05.04.2016 14:57

      Не забываем про его open source форк Kallithea.


  1. 10E137
    05.04.2016 15:31

    Вся прелестность GitLab заканчивается тогда, когда с ним надо работать в корпоративной среде, с необходимостью интеграции issue tracker и все это сдобрено толикой SSO. В моем случае в качестве issue tracker`а была JIRA. Даже Enterprise предлагает только «создание специального пользователя» в JIRA с доступом к JIRA Core. И коменты оно пишет из разряда «mentioned» а не то, что было в коммите.


    1. Kudja
      06.04.2016 12:46

      Ну тогда в вашем случае полагаю Jira Server использовался, а тогда https://marketplace.atlassian.com/plugins/com.xiplink.jira.git.jira_git_plugin/server/overview чем плох?