SVN для развертывания веб-приложения

Система управления версиями Subversion настолько обширна, что подходит не только для разработки, но и развертывания (выкатки) всего сервиса/приложения/сайта на продакшн-сервер.

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

Используя SVN Hooks

Хуки (hooks) – это, по сути, скрипты, которые запускаются по определенным событиям, изменении ревизии, к примеру.

Они выполняются в автоматическом режиме, поэтому как нельзя лучше подходят для автоматического развертывания приложений.

Шаблоны хуков

Репозиторий SVN по умолчанию содержит директорию hooks, в которой размещены шаблоны различных хуков:

$ ls repos/hooks/

post-commit.tmpl post-unlock.tmpl pre-revprop-change.tmpl

post-lock.tmpl pre-commit.tmpl pre-unlock.tmpl

post-revprop-change.tmpl pre-lock.tmpl start-commit.tmpl

## Содержимое директории hooks по умолчанию

Их названия кратко описывают, когда эти скрипты запускаются. В данном случае нас интересует post-commit, который запускается сразу же после коммита новой ревизии, когда уже есть номер ревизии.

Схема работы

Вероятнее всего вы не захотите сбрасывать версию из разработки сразу же в продакшн. Логичнее сначала ее запустить и проверить на тестовом сервере, чтобы провести всю необходимую отладку и вовремя избавиться от багов, если они есть. А уже после этого разворачивать приложение на общедоступном сервере.

Так что процесс будет примерно таким:

1. разработка на стороне клиента;
2. коммит изменений в репозиторий;
3. автоматическое внесение изменений на тестовый сервер;
4. отладка, проверка работоспособности;
5. развертывание обновления (по команде, в автоматическом режиме) на продакшн сервер.

Реальные примеры

Для начала нужно составить скрипты для SVN, которые могут быть написаны на любом понятном серверу языке (Bash, Python и т.д.).

Фактически потребуется всего два скрипта: один для отправки на тестовый сервер и проверки команды на развертывание; и второй для непосредственной выгрузки на продакшн-сервер.

Скрипт post-commit будет иметь следующий вид:

#!/bin/bash

REPO=”$1″

REV=”$2″

TEST_SERVER=”192.168.1.55″

PROD_SERVER=”146.185.138.162″

# Обновление рабочей копии на тестовом сервере

ssh -l root $TEST_SERVER -t “cd /var/www && svn up”

# Проверка команды на деплоймент

if ( svnlook log -r $REV $REPO | grep “~~deploy~~” )

then

/usr/local/bin/svn-deploy $REPO $REV “root@${PROD_SERVER}:/var/www”

fi
## Сигнал на развертывание может быть любым, но должен содержаться в комментарии к коммиту

В данном примере все версии, которые прошли коммит, выгружаются на тестовый сервер, но если в сообщении коммита содержится комманда на деплоймент, то файлы дополнительно выгружаются и на общедоступный сервер. В этом случае запускается второй скрипт:

#!/bin/bash

REPO=”$1″

REV=”$2″

TARGET=”$3″

ssh root@[146.185.138.162]

# экспорт репозитория

rm -rf /tmp/export

svn export -r $REV “file://$REPO” /tmp/export

# синхронизация

rsync -az -e ssh /tmp/export/* $TARGET
## Используется команда svn export, которая делает чистую копию репозитория без файлов .svn

Полуавтоматическое развертывание приложений

Деплоймент при помощи Subversion может быть таким же простым, как выполнение svn up. Для этого нужен установленный клиент svn на продакшн-сервере, чистый репозиторий и пара дополнительных мер безопасности.

Сокрытие конфигов

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

Теперь можно удалить конфиги сайта из svn:

$ svn remove --keep-local wp-config.php

$ svn commit

## Локальные копии файлов будут сохранены

Затем рекомендуем заставить svn игнорировать эти файлы, чтобы они не появлялись в командах типа svn status:

$ cd /path/to/config_file/directory

$ echo “wp-config.php” > .svn_ignore

$ svn add .svn_ignore

$ svn propset svn:ignore -F .svn_ignore .

$ svn commit
## Все внесенные в .svn_ignore файлы будут игнорироваться

Безопасность

Директории .svn по умолчанию доступны широкому интернету, если они лежат на сервере. Так что самым лучшим и одновременно простым решением будет запрет на доступ к этим папкам на стороне веб-сервера. Для этого в файле конфигурации Nginx в секцию http нужно добавить подобное:

...

location ~ /(.svn) {

deny all;

return 404;

} …

## Запрет доступа ко всем файлам с требуемым расширением

А в Apache это делается так:

Order allow,deny

Deny from all

## Настраивается блок <VirtualHost> сайта или главный конфиг веб-сервера

Деплоймент

Теперь достаточно подключиться к своему продакшн-сервреру по SSH, перейти в директорию document_root и выполнить:

$ svn update
## Все файлы и изменения будут скопированы на сервер

Примечательно, что такой способ позволит быстро откатиться на требуемую ревизию и вообще производить все необходимые манипуляции с svn прямо на продакшн-сервере.

Самое главное

После небольшой настройки и написания пары скриптов, вы сможете разворачивать веб-приложение или сайт на производственный сервер в автоматическом режиме. Главное не забывать проверить работоспособность разработки перед выкаткой.