Нормально ли держать копию репозитория на хостинге?

Я привык к тому, что это удобно: положил копию репозитория на продакшн и делаю git pull при необходимости. Пишу на Питоне и Ruby, поэтому отдельно компилировать ничего не надо: на хостинге лежат те же исходники, что и на домашней машине. И распределенная система управления версиями работает еще и как система развертывания проекта. Бонус: если мой коммит завалил какую-то функциональность и тесты этого не выявили, то всегда можно откатиться на любую другую версию кода без дополнительных инструментов.


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


В чем минусы такого подхода?


Понятно, что для развертывания проекта есть специальные инструменты. Понятно, что они удобны и необходимы при работе с Джавой, например. Но я не вижу, чем git и hg уступают им в этом плане, если разработка идет на интерпретируемом языке.


Я так понял, однажды кто-то собрал кучу исходников из .svn-директорий, открыто лежащих в веб-пространстве, и теперь все VCS на сервере считаются чем-то плохим. Но нужно же понимать разницу…
  • Вопрос задан
  • 4244 просмотра
Решения вопроса 1
vsespb
@vsespb
Тоже иногда такое практикую (когда это оправдано экономией времени малым риском)

Некоторые мысли:

1. А если злоумышленник попадёт на сервер и получит права на запись в Git репозиторий — он сможет его уничтожить — видимо да stackoverflow.com/questions/2006172/how-to-reset-a-remote-git-repository-to-remove-all-revisions

2. Откатиться на предудущую ревизию можно и в обычных системах деплоя (бывает symlink ставится на определённую ревизию).

3. Нужно не забыть убедиться что .git папка не была доступна из веба

4. Системы деплоя могут делать гораздо более сложные вещи — перезапускать серверные процессы по одному, использовать кастомные скрипты деплоя, выполнять миграции БД, отслеживать ошибки деплоя. А тут Вам придётся со своей системой всё делать самостоятельно.
Ответ написан
Пригласить эксперта
Ответы на вопрос 4
pletinsky
@pletinsky
Нужно отделять понятие исходного кода и развернутого приложения. Когда это вроде одно и тоже кажется что использовать систему контроля версий для деплоя можно. Но вообще система контроля версий придумана чтобы контролировать версии а не деплоить.
То есть концептуально такой подход неправильный.
Запахи данной проблемы будут проявляться например так: некоторые данные будут оказываться в продакшене, хотя там быть не должны (код для тестов например).

Перечисленные вами бонусы и плюсы использованного подхода на самом деле никакие не бонусы и не плюсы — специализированные системы деплоя все это позволяют делать.
Кроме этого они еще позволяют дофига всего.
Например автоматизированное заливание приложения на тестовый контур после чекинов, прогон длительных по времени тестов, сбор метрик кода, отслеживание истории деплоев, тестирования и т.д. Мгновенная сигнализация о любых проблемах с решением (вроде упавсего билда или теста) всем членам команды и еще много много всего.

Безусловно кое что можно сделать хуками системы контроля версий — но это на самом деле почесывание пяткой уха.
И дело тут вовсе не в том, на скриптовых языках проект или нет.
Вопрос в том серьезное ли это решение или поделка на коленке.

Как только ваш проект выйдет на определенный уровень (если это произойдет) — то вам придется использовать специализированные решения для деплоя и вы увидите в них необходимость.
Пока вы не видите в них необходимость — не парьтесь и используйте то, что привыкли.
Ответ написан
a11aud
@a11aud
Это нормальная ситуация, «я 100 раз так делал». Более того, если вы используете распределенную систему контроля версий (самые популярные представители DVCS — это git, hg и bzr), то копия репозитория есть у каждого участника проекта, поэтому вы получается в качестве бонуса резервную копию кода.
Ответ написан
Anastasia_K
@Anastasia_K
не боитесь, что внутренние пароли, данные, удаленные из репозитария и т.п. окажутся в руках у злоумышленника?
Ответ написан
mgyk
@mgyk
Нормально, если вам не нужно что-то перезапускать или выкладывать больше чем на один хост.
Но, поверьте, для рельсов один раз настроить capistrano дело 15 минут. Выкатить сам код обычно только 10% задачи деплоя, нужно еще 1) обновить завимости 2) накатить миграции 3) перезапустить unicorn/passenger. Если работаете не один, не нужно объяснять каждому куда и как выкладывается код, что тоже достаточно большой плюс
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы