Добрейшего.
Я достаточно давно работаю в отрасли разработки приложений для веба, поэтому всегда с двойным интересом читаю материалы о применении SCM для веб-разработки. Поэтому этот материал особенно порадовал: Using Git to manage a web site, что означает примерно "Как с помощью гита управлять веб-сайтом".
Идея, в общем-то, не нова. Берём git, создаем репо у себя и репо на сервере, где лежит сайт. Далее с помощью напильника и механизма хуков (hooks) настраиваем, чтобы при получении очередной дельты через push, локальная копия исходников сайта обновлялась из репозитория. Разработчик меняет код, делает push на сервер, там срабатывает хук, который разворачивает новые исходники в ту директорию, где у вашего сайта DocumentRoot.
Думаю, что-то аналогичное можно придумать и для Mercurial.
Для тех, кто использует распределённые системы контроля и пишет под веб, это хорошее решение.
Я достаточно давно работаю в отрасли разработки приложений для веба, поэтому всегда с двойным интересом читаю материалы о применении SCM для веб-разработки. Поэтому этот материал особенно порадовал: Using Git to manage a web site, что означает примерно "Как с помощью гита управлять веб-сайтом".
Идея, в общем-то, не нова. Берём git, создаем репо у себя и репо на сервере, где лежит сайт. Далее с помощью напильника и механизма хуков (hooks) настраиваем, чтобы при получении очередной дельты через push, локальная копия исходников сайта обновлялась из репозитория. Разработчик меняет код, делает push на сервер, там срабатывает хук, который разворачивает новые исходники в ту директорию, где у вашего сайта DocumentRoot.
Думаю, что-то аналогичное можно придумать и для Mercurial.
Для тех, кто использует распределённые системы контроля и пишет под веб, это хорошее решение.
Чтот я не понял, с чего вдруг дельта затерётся?
ОтветитьУдалитьЕсли второй не сделает git pull перед этим, то его git push тупо не прокатит, DVCS же всё-таки...
Чёрт, и то верно. Давно не брал я в руки DVCS.
ОтветитьУдалитьТогда возражение снимается, абзац затираю :)
А вот в одной хорошей статье написано:
ОтветитьУдалить"Да и сама компиляция и линковка теперь – задача непростая, каждый раз вылазят специфичные для среды ошибки. При наличии нескольких человек трудно понять, кто и когда залил на сервер новый релиз и кто готовит инсталляционный пакет для клиентов. Проблемы пока решаются, ибо команда всё ещё невелика, и все находятся рядом. Однако давление уже изменяется: проект “всплывает”, последствия начального выбора процессов и инструментов скоро начнут «пузыриться»"
;)
Не вижу противоречий :)
ОтветитьУдалитьА будет разве не "трудно понять, кто и когда залил на сервер новый релиз и кто готовит инсталляционный пакет для клиентов" ?
ОтветитьУдалитьЭто уже оргвопрос :)
ОтветитьУдалитьВообще, мне заметка чем приглянулась - интересным техническим решением развёртывания исходников на сайте.
К слову, как-то был скандал, связанный с такой технологией
ОтветитьУдалитьhttp://habrahabr.ru/blogs/infosecurity/70330/
Правда, задействована была subversion, в git этот эффект не проявляется. Еще один камень в огород subversion :)
Ну, это следствие кривых рук, не сабвершна :) Люди тупо заливали по FTP рабочую дирку целиком вместо того, чтобы заливать только изменённое.
ОтветитьУдалитьУ git и Hg тоже есть служебка - уж не знаю, можно ли по ней что-то получить - которую так же можно случайно залить на сервер руками по ФТП.
А если ещё и правильно организовать структуру директорий - то даже такая утечка не будет страшна, т.к. пароли и т.п. будут храниться в невидимой вовне части.
Да не, думаю, скорей тупо сайт как рабочая папка SVN, т.е. для обновления делают svn up, а не svn export или как там его...
ОтветитьУдалитьДа, тоже может быть, судя по тому, что служебка SVN-а содержала актуальные данные.
ОтветитьУдалитьДак просто я сам такое делал, правда там сам код на mod_rewrite сидел, поэтому до .svn вроде доступа не должно было быть
ОтветитьУдалитьА чем закидывал изменения в SVN, который крутился на сервере?
ОтветитьУдалитьты удивишься - svn-ом :)
ОтветитьУдалитьну точней svn+ssh
"-Ааа! -Семен Семеныч..." (с)
ОтветитьУдалитьКак-то забыл про вариант, когда работаешь напрямую с сервером с локального компа :)))))
Почему? Не обязательно:
ОтветитьУдалитьфигачу всё локально, делаю svn commit и оно отправляет по ssh изменения на сервак
Ну, я об этом и говорю - с локального компа работаешь с сервером - по ssh :)
ОтветитьУдалитьну с таким подходом с копированием по ftp тоже работа с сервером, тока не по ssh
ОтветитьУдалитьFTP только кладёт файлы. Описанное в статье, да и работа через SSH - это ещё и выполнение определённых действий помимо выкладывания.
ОтветитьУдалитьИмхо ты запутался.
ОтветитьУдалитьЯ говорил про мой вариант - там был только svn commit который по сути и есть выкладывание файлов, правда не на сайт, а в репу.
Всё правильно, я этого не отрицал :)
ОтветитьУдалить>Ну, это следствие кривых рук, не сабвершна :) Люди тупо заливали по FTP рабочую дирку целиком вместо того, чтобы заливать только изменённое.
ОтветитьУдалитьДумаю, для обновления сайта использовалась команда svn update, которая синхронизовала сайт с исходниками, попутно создавая .svn каталоги с рабочей информацией.
Технологии такого типа, на мой взгляд, как раз раскритикованы в статье про пузырьки. Надо бы, конечно, формировать пакеты развертывания/ обновления и их уже накатывать при помощи процедур развертывания/обновления. К примеру, довольно часто требуется обновление базы.