В этой части будет обзор систем контроля версий, и способов управления правами доступа к репозиториям. Хотя не, обзора систем контроля версий не будет. Git и все.
Контроль версий.
Тут все просто. Git. Никаких SVN и уж тем более CVS.
Да, безусловно, я знаю про mercurial, bazaar, tfs и прочие штуки. Мы для себя выбрали гит и довольны, так что менять что-либо, смысла нет.
Настройка прав доступа к репозиториям.
В случае использования git, мне известно 2 проекта для настройки прав: это gitosis и gitolite. Мы у себя когда-то начали использовать gitosis. Но он сейчас почти не развивается, да и у gitolite есть несколько преимуществ. Так что в итоге мы перешли на gitolite.
Оба проекта используют авторизацию по ssh-ключам. Но в gitosis’е можно разграничить доступ только на уровне read/write по проектам и пользователям. В gitolite помимо всего прочего есть возможность запретить push force для некоторых пользователей, что может быть полезно для предотвращения подкладки свиней из серии checkout на старый коммит и push force на сервер. Так же в gitolite все названия сущностей гит (ветки/тэги) могут быть регулярными выражениями, что позволяет легко настроить, например, возможность коммитов в ветки с релизами только старшим разработчикам, если ветки именуются согласно утвержденным правилам. Еще, забегая вперед, скажу, что gitolite интегрируется с разными другими полезными продуктами, например Trac, но об этом чуть позже.
Также, не могу не сказать про GitLab, в котором изначально есть система настройки прав доступа. В ранних версиях GitLab’а использовался gitolite — и это было вообще здорово, но из-за сложности поддержки интеграции, разработчики гитлаба, начиная, кажется, с 5-й версии перешли на свой компонент для разграничения прав доступа под названием gitlab-shell. Он, к сожалению, не настолько гибкий как gitolite, по своему функционалу он ближе к gitosis. В гитлабе есть так называемые роли: master, developer, reporter, guest. Все права завязаны на эти роли. Так что нет возможности запретить push-force. Правда можно запретить сливания в защищенные ветки, это позволяет сделать так, чтобы в master и основную ветку разработки могли пушить мерджить и пушить только master’ы, что, в общем-то, по большей части, решает основные проблемы и опасения.
Понятно, что это вызвано несколько другой идеологией работы: в гитлабе предполагается, так же как и в гитхабе, подход с форканием проектов, и тогда запросы на сливание в проект смогут принять только разработчики с правами в основном репозитории. Но мы у себя как-то этот подход не приняли. У нас один репозиторий и все разработчики имеют к нему доступ, ведут свою работу в отдельных ветках, затем пушат свои ветки в репозиторий и старшие разработчики уже проверяют и сливают код в mainstream.
Есть еще такой проект как SCM-Manager, он тоже opensource, написан на java. Из приятных моментов стоит отметить простоту установки: ставим на сервер jdk, git, качаем scm-manager и запускаем — все. SCM-Manager из коробки поддерживает git/svn/mercurial репозитории. Дальнейшая настройка происходит из веб-интерфейса, все общение с репозиториями так же реализуется поверх http. В интерфейсе можно создать репозитории, установить плагины, настроить права доступа. По умолчанию там есть только READ/WRITE/OWNER права на репозитории. Но с помощью дополнительных плагинов можно получить функциональность настройки прав на отдельные ветки и даже пути. Сделано это, правда, на мой взгляд, не очень удобно и очевидно. Еще из плюсов — это интеграция с баг-трекерами, опять же через плагины. Есть поддержка jira, redmine, bugzilla. Так что можно при получении коммита с текстом определенного вида сразу закрывать баг в трекере. Это здорово. Есть еще возможность просмотра дифов изменений, но никакой возможности комментировать код, то есть функциональности код-ревью — нет. А было бы здорово.
Из минусов — это скудная документация, не очень удобный функционал гибкой настройки прав доступа к репозиториям.
И еще одна система, которую я попробовал — это rhodecode. По своей задумке, она очень близка к gitlab’у. Написана она на питоне, из коробки умеет работать с git & mercurial. При ее использовании предполагается, что репозитории хостятся на том же сервере, что и сама система. Доступ к репозиториям возможен только по http, поддержка ssh в планах.
С точки зрения настройки прав доступа, есть всего три варианта: read, write, admin. Админам можно управлять правами доступа, принимать мердж-реквесты и выполнять прочие административные функции. В парадигме rhodecode мердж-реквесты возможны только между репозиториями, то есть предполагаемый паттерн поведения — это форк репозитория, внесение изменений и затем создание мердж-реквеста. Делать реквесты из одной ветки в другую, в рамках одного репо возможности нет 🙁 Это печально. Есть возможности код-ревью. Но оно находится в зачаточном состоянии: можно комментировать код, то есть change-set’ы, этот комментарий улетит по почте всем причастным, но и все, никто не мешает сливать ветки при наличии write-доступа, то есть код-ревью носит исключительно рекомендательный характер. И даже если все хорошо и хочется уже слить эту ветку в дев нажав одну кнопку (как это делается в гитлабе) — не судьба. Но у разработчиков это в планах. Из приятных плюшек есть гисты, то есть возможность публиковать сниппеты. Но не знаю, насколько это нужно для приватных репозиториев и небольших команд. Так что в целом, проект интересный, но он находится, несмотря на версию 1.7.1, на ранней стадии своего жизненного цикла, там еще много чего предстоит сделать, чтобы догнать своих ближайших конкурентов/аналогов, тот же gitlab. Кстати говоря, буквально пару дней назад, проект RhodeCode был преобразован из свободного проекта в коммерческий продукт с частично открытым кодом. Так что все новые фичи уже будут доступны по платной подписке.
Если подводить итог исключительно со стороны контроля доступа к репозитариям, то лично мне больше всего понравился gitolite. Да, возможно надо потратить немного времени на его начальную настройку, но зато в дальнейшем все настраивается очень просто и быстро, а его гибкость позволяет обезопасить проект от случайных мерджей и напрасной траты времени на разгребание мусора. Но если смотреть на системы в целом, обращая внимание на другие функциональности, то такие системы как гитлаб, конечно, на порядок интереснее.