2011-02-12

Используем git для управления сайтом

Добрейшего.

Я достаточно давно работаю в отрасли разработки приложений для веба, поэтому всегда с двойным интересом читаю материалы о применении SCM для веб-разработки. Поэтому этот материал особенно порадовал: Using Git to manage a web site, что означает примерно "Как с помощью гита управлять веб-сайтом".

Идея, в общем-то, не нова. Берём git, создаем репо у себя и репо на сервере, где лежит сайт. Далее с помощью напильника и механизма хуков (hooks) настраиваем, чтобы при получении очередной дельты через push, локальная копия исходников сайта обновлялась из репозитория. Разработчик меняет код, делает push на сервер, там срабатывает хук, который разворачивает новые исходники в ту директорию, где у вашего сайта DocumentRoot.

Думаю, что-то аналогичное можно придумать и для Mercurial.

Для тех, кто использует распределённые системы контроля и пишет под веб, это хорошее решение.

21 комментарий:

  1. Чтот я не понял, с чего вдруг дельта затерётся?
    Если второй не сделает git pull перед этим, то его git push тупо не прокатит, DVCS же всё-таки...

    ОтветитьУдалить
  2. Чёрт, и то верно. Давно не брал я в руки DVCS.
    Тогда возражение снимается, абзац затираю :)

    ОтветитьУдалить
  3. А вот в одной хорошей статье написано:

    "Да и сама компиляция и линковка теперь – задача непростая, каждый раз вылазят специфичные для среды ошибки. При наличии нескольких человек трудно понять, кто и когда залил на сервер новый релиз и кто готовит инсталляционный пакет для клиентов. Проблемы пока решаются, ибо команда всё ещё невелика, и все находятся рядом. Однако давление уже изменяется: проект “всплывает”, последствия начального выбора процессов и инструментов скоро начнут «пузыриться»"

    ;)

    ОтветитьУдалить
  4. А будет разве не "трудно понять, кто и когда залил на сервер новый релиз и кто готовит инсталляционный пакет для клиентов" ?

    ОтветитьУдалить
  5. Это уже оргвопрос :)
    Вообще, мне заметка чем приглянулась - интересным техническим решением развёртывания исходников на сайте.

    ОтветитьУдалить
  6. К слову, как-то был скандал, связанный с такой технологией
    http://habrahabr.ru/blogs/infosecurity/70330/

    Правда, задействована была subversion, в git этот эффект не проявляется. Еще один камень в огород subversion :)

    ОтветитьУдалить
  7. Ну, это следствие кривых рук, не сабвершна :) Люди тупо заливали по FTP рабочую дирку целиком вместо того, чтобы заливать только изменённое.

    У git и Hg тоже есть служебка - уж не знаю, можно ли по ней что-то получить - которую так же можно случайно залить на сервер руками по ФТП.

    А если ещё и правильно организовать структуру директорий - то даже такая утечка не будет страшна, т.к. пароли и т.п. будут храниться в невидимой вовне части.

    ОтветитьУдалить
  8. Да не, думаю, скорей тупо сайт как рабочая папка SVN, т.е. для обновления делают svn up, а не svn export или как там его...

    ОтветитьУдалить
  9. Да, тоже может быть, судя по тому, что служебка SVN-а содержала актуальные данные.

    ОтветитьУдалить
  10. Дак просто я сам такое делал, правда там сам код на mod_rewrite сидел, поэтому до .svn вроде доступа не должно было быть

    ОтветитьУдалить
  11. А чем закидывал изменения в SVN, который крутился на сервере?

    ОтветитьУдалить
  12. ты удивишься - svn-ом :)
    ну точней svn+ssh

    ОтветитьУдалить
  13. "-Ааа! -Семен Семеныч..." (с)

    Как-то забыл про вариант, когда работаешь напрямую с сервером с локального компа :)))))

    ОтветитьУдалить
  14. Почему? Не обязательно:
    фигачу всё локально, делаю svn commit и оно отправляет по ssh изменения на сервак

    ОтветитьУдалить
  15. Ну, я об этом и говорю - с локального компа работаешь с сервером - по ssh :)

    ОтветитьУдалить
  16. ну с таким подходом с копированием по ftp тоже работа с сервером, тока не по ssh

    ОтветитьУдалить
  17. FTP только кладёт файлы. Описанное в статье, да и работа через SSH - это ещё и выполнение определённых действий помимо выкладывания.

    ОтветитьУдалить
  18. Имхо ты запутался.
    Я говорил про мой вариант - там был только svn commit который по сути и есть выкладывание файлов, правда не на сайт, а в репу.

    ОтветитьУдалить
  19. Всё правильно, я этого не отрицал :)

    ОтветитьУдалить
  20. >Ну, это следствие кривых рук, не сабвершна :) Люди тупо заливали по FTP рабочую дирку целиком вместо того, чтобы заливать только изменённое.

    Думаю, для обновления сайта использовалась команда svn update, которая синхронизовала сайт с исходниками, попутно создавая .svn каталоги с рабочей информацией.

    Технологии такого типа, на мой взгляд, как раз раскритикованы в статье про пузырьки. Надо бы, конечно, формировать пакеты развертывания/ обновления и их уже накатывать при помощи процедур развертывания/обновления. К примеру, довольно часто требуется обновление базы.

    ОтветитьУдалить