Грамотное разворачивание сайта без VCS

02 сентября 2009, обновлена 01 октября 2009

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

Ну да, не совсем без системы контроля версий, а при наличии отсутствия ее на сервере.

UPD: Еще проще и удобнее выливать сайты через sshfs.

Способ первый. Используем Capistrano

Для тех, кто в танке: Capistrano – это такая штука для выполнения команд на удаленных серверах с помощью SSH. Например, с ее помощью можно одной командой залезть на сервер, вытянуть туда код из репозитария, выполнить миграции и перезапустить сервер. Удобно.

К сожалению, вытянуть код прямо с сервера у нас не получится – там не знают о VCS.
«Папа, а правда, есть люди, которые не пользуются VCS? Нет, сынок, это фантастика.»

Для таких случаев у Capistrano есть стратегия copy.

#config/deploy.rb
 
set :deploy_via, :copy
set :copy_strategy, :export
 
set :scm, :git
set :branch, 'master' # или любая другая ветка
set :repository, 'git@my.server:repo/location.git'
 
set :deploy_path '/path/to/app/on/deploy/server'
role :web, 'the.deploy.server'

Все, вызываем cap:deploy, Capistrano вытягивает содержимое ветки, зажимает в gzip-архив и отправляет на сервер. Снова удобно.

К сожалению, на конкретном сервере у меня возникла проблема с использованием дерева каталогов Capistrano, а точнее, с симлинками в этом дереве. Если можно как-то обойтись без /current и /releases – напиши об этом в комментах, а я расскажу о дедовском способе.

Способ второй. Не такой модный, зато простой и тоже работающий

Shell-скрипт, который вытягивает содержимое репозитария и запихивает его на сервер rsync-ом. Его, наверное, можно было бы начинить переменными и комментариями, но мне лень.

#!/bin/sh
cd /tmp
rm -rf site_checkout
git clone git@my.server:repo/location.git site_checkout
cd site_checkout
git checkout master
rm -rf .git
rsync -zr -e ssh . the.deploy.server:/path/to/site/on/deploy/server
cd ..
rm -rf site_checkout

Кажись, это требует настройки параметров доступа к the.deploy.server в ~/.ssh/config, у меня так и есть.

Если что непонятно – я уточню.



Двенадцать комментариев. Напиши еще один
  1. 6882a468bbcdd4edc01959711c5f3be7 # 24 сентября 2009 gituliar (git.tx97.net) написал:

    Не работал с git, но в mercurial есть команда push, которая изменения с текущего репозитория заливает на удаленный:
    > hg push DEST

    Единственная проблема — чтобы обновить файлы все равно наужно заходить на сервер и делать
    > hg update

    1. 777894ea5153122bfa6b83f5bbf23622 # 24 сентября 2009 Леонид Шевцов (автор) написал:

      Без обновления использование VCS теряет смысл.

    2. 514f1b439f404f86f77090fa9edc96ce # 21 марта 2012 rr написал:

      в .hg/hgrc
      [hooks]
      changegroup = hg update

  2. 86601e5039ba231c5e529f29c56f86c2 # 27 сентября 2009 Василий написал:

    а вот когда меняется структура базы – все намного сложней. Возможно даже конвертеры придется писать :(.

    и вот еще идея: создаем diff-path от ревизии на сервере до той ревизии, на которую хотим обновиться/откатиться. Если есть доступ по SSH и на сервере установлена утилита diff – патчим). Если SSH-доступа нет, но разрешена shell_exec – пробуем патчить.

    В самом крайнем случае – пишем парсер, который будет патчить.

    1. 777894ea5153122bfa6b83f5bbf23622 # 27 сентября 2009 Леонид Шевцов (автор) написал:

      На Rails ничего сложного в изменении базы нет – заливаешь на сервер новые миграции, выполняешь их, и все.

      По поводу diff: rsync делает то же самое, но автоматически. :)

  3. 6882a468bbcdd4edc01959711c5f3be7 # 01 октября 2009 gituliar (git.tx97.net) написал:

    Итак, вот как это работает с mercurial:

    1. Создаем репозиторий на сервере (или клонируем уже существующий с локальной машины) и открываем к нему доступ.
    
    2. Добавляем в .hgrc след. строки (source: http://mercurial.selenic.com
    

    /wiki/FAQ/CommonProblems):

    [hooks]
    changegroup = hg update >&2

    3. Вносим изменения и делаем коммит.
    
    4. Теперь после вызова "hg push" на сервере автоматически будет вызываться "hg update >&2".
    
    1. 777894ea5153122bfa6b83f5bbf23622 # 01 октября 2009 Леонид Шевцов (автор) написал:

      А если на сервере нет Mercurial?

  4. 6882a468bbcdd4edc01959711c5f3be7 # 01 октября 2009 gituliar (git.tx97.net) написал:

    Если нет mercurial, то понятно что ничего работать не будет. Зачем тогда юзать VCS —– юзай scp )))

    1. 777894ea5153122bfa6b83f5bbf23622 # 01 октября 2009 Леонид Шевцов (автор) написал:

      Как это – зачем? Затем, что удобнее.

  5. 6882a468bbcdd4edc01959711c5f3be7 # 01 октября 2009 gituliar (git.tx97.net) написал:

    Раз удобней, то юзай VCS на полную (в том числе и на сервере), как говориться «жить хорошо, а хорошо жить — еще лучше».

    PS. По поводу отсутствия mercurial на сервере, это довольно странно, потому как mercurial написан на Python'e, который в свою очередь стоит на большинстве UNIX-систем по умолчанию.

    1. 777894ea5153122bfa6b83f5bbf23622 # 01 октября 2009 Леонид Шевцов (автор) написал:

      Дык мораль в том, что сервер – это shared-хостинг, я туда ничего устанавливать не могу, а VCS использовать хочется, чтобы упростить себе жизнь.

      И кроме всего прочего, надо не Mercurial, а git. :)

  6. 37d953b779140f975e85ff64b6459471 # 30 мая 2010 Костег написал:

    сеня зарелизил прототип прожки
    http://pyha.ru/forum/topic/4520.msg97106#msg97106

    Пока только ftp, mercurial. Потом будет больше протоколов и других систем контроля версий. И планируется добавить работу не в интерактивном режиме.

(нужна разметка?)

  • **жирный**
  • > цитата

отменить