Нормально ли держать копию репозитория на хостинге?
Я привык к тому, что это удобно: положил копию репозитория на продакшн и делаю git pull при необходимости. Пишу на Питоне и Ruby, поэтому отдельно компилировать ничего не надо: на хостинге лежат те же исходники, что и на домашней машине. И распределенная система управления версиями работает еще и как система развертывания проекта. Бонус: если мой коммит завалил какую-то функциональность и тесты этого не выявили, то всегда можно откатиться на любую другую версию кода без дополнительных инструментов.
Если произошла какая-то экстремальная ситуация и в код на сервере были внесены изменения (мимо версионного контроля), то их легко отследить и даже закоммитить прямо оттуда (хотя, я считаю это неправильным).
В чем минусы такого подхода?
Понятно, что для развертывания проекта есть специальные инструменты. Понятно, что они удобны и необходимы при работе с Джавой, например. Но я не вижу, чем git и hg уступают им в этом плане, если разработка идет на интерпретируемом языке.
Я так понял, однажды кто-то собрал кучу исходников из .svn-директорий, открыто лежащих в веб-пространстве, и теперь все VCS на сервере считаются чем-то плохим. Но нужно же понимать разницу…
2. Откатиться на предудущую ревизию можно и в обычных системах деплоя (бывает symlink ставится на определённую ревизию).
3. Нужно не забыть убедиться что .git папка не была доступна из веба
4. Системы деплоя могут делать гораздо более сложные вещи — перезапускать серверные процессы по одному, использовать кастомные скрипты деплоя, выполнять миграции БД, отслеживать ошибки деплоя. А тут Вам придётся со своей системой всё делать самостоятельно.
Нужно отделять понятие исходного кода и развернутого приложения. Когда это вроде одно и тоже кажется что использовать систему контроля версий для деплоя можно. Но вообще система контроля версий придумана чтобы контролировать версии а не деплоить.
То есть концептуально такой подход неправильный.
Запахи данной проблемы будут проявляться например так: некоторые данные будут оказываться в продакшене, хотя там быть не должны (код для тестов например).
Перечисленные вами бонусы и плюсы использованного подхода на самом деле никакие не бонусы и не плюсы — специализированные системы деплоя все это позволяют делать.
Кроме этого они еще позволяют дофига всего.
Например автоматизированное заливание приложения на тестовый контур после чекинов, прогон длительных по времени тестов, сбор метрик кода, отслеживание истории деплоев, тестирования и т.д. Мгновенная сигнализация о любых проблемах с решением (вроде упавсего билда или теста) всем членам команды и еще много много всего.
Безусловно кое что можно сделать хуками системы контроля версий — но это на самом деле почесывание пяткой уха.
И дело тут вовсе не в том, на скриптовых языках проект или нет.
Вопрос в том серьезное ли это решение или поделка на коленке.
Как только ваш проект выйдет на определенный уровень (если это произойдет) — то вам придется использовать специализированные решения для деплоя и вы увидите в них необходимость.
Пока вы не видите в них необходимость — не парьтесь и используйте то, что привыкли.
Это нормальная ситуация, «я 100 раз так делал». Более того, если вы используете распределенную систему контроля версий (самые популярные представители DVCS — это git, hg и bzr), то копия репозитория есть у каждого участника проекта, поэтому вы получается в качестве бонуса резервную копию кода.
Я не сохраняю внутренние пароли в версионном контроле, они лежат в файле с локальными настройками. Если злоумышленник получит доступ к хостингу (или, хотя бы, к репозиторию), пароли — это десятый вопрос, который будет меня волновать.
Нормально, если вам не нужно что-то перезапускать или выкладывать больше чем на один хост.
Но, поверьте, для рельсов один раз настроить capistrano дело 15 минут. Выкатить сам код обычно только 10% задачи деплоя, нужно еще 1) обновить завимости 2) накатить миграции 3) перезапустить unicorn/passenger. Если работаете не один, не нужно объяснять каждому куда и как выкладывается код, что тоже достаточно большой плюс
Зависимости у меня без проблем накатываются один раз из трех. И в Руби, и в Питоне. То есть, я совершенно точно знаю: обновил список зависимостей — иди на сервер и запускай установку руками, меньше времени потеряешь.
Если будет большой проект, попробую capistrano, а пока у меня «поделки на коленке».
Простой
Средний
