Использование VCS для обновления и поддержки веб-сайтов

в романе «Шантарам» Грегори Робертс писал, что зло бывает порождено стараниями людей изменить что-то к лучшему. При попытке улучшить web ресурс таким злом является возникновение регрессивных ошибок. Обычнок разработчики используют какое-то ПО с функциями публикации и резервного копирования, не задумываясь о контроле обновлений версий. Но иногда, потрудившись над сложной доработкой, он видит, что его чудо скрипт затерт файлом коллеги, который не посмотрел на дату изменений.

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

Как это работает

(Version Control System, VCS) системы управления версиями  используются для контроля изменений и возможности создания нескольких версий разрабатываемого проекта. Во время распределенной разработки они помогают систематизировать работу с несколькими версиями одних и тех же документов.

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

Как это используется при сопровождении сайта?

Стандартная схема поддержки веб-проекта выглядит следующим образом: разработчики вносят изменения на web-сервер сайта, который в свою очередь просматривают пользователи. Если несколько разработчиков изменяют один и тот же документ, то первое изменения будет стерто вторым, и пользователь получит некорректную информацию. Потребуется найти предыдущие версии, чтобы откатить проект, и выяснить причину получившегося несоответствия.

Подобные конфликты изменений приводят к надобности создания сложных правил изменения и мешает распределенной работе программистов.

Решением данной проблемы является система контроля версий, причем для поддержки веб-сайтов наиболее эффективна та схема, при которой на веб-сервере находится два репозитория.

Первый репозиторий используется для сбора изменений, приходящих от всех разработчиков. Который содержит ветку с основной версией сайта, master, и дополнительных, например, ветка разработки dev и ветка изменений hotfix. Программисты работают с репозиторием через VCS консоль и клиенты . Таким образом происходит связь разработчиков и проекта. В первом репозитории нет рабочих файлов сайта, только служебные, содержащие изменения.

Второй репозиторий содержит только ветку master с рабочим каталогом, где и запущен сайт. Репозиторий в автоматическом режиме применяет изменения из основной ветки первого репозитория при создании версиии изменения и передает к нему же все свои изменения. Данное решение для страховки, что бы каталог обновлялся в одностороннем порядке, а доступ программистам к нему нужно закрыть.

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

Какую систему выбрать

В настоящее время существует множество систем управления версиями. Хотя схема настройки на веб-сайте описана в общем случае, чтобы показать ее универсальность, все-таки стоит упомянуть об основных разновидностях VCS.

Централизованные системы управления (например, Subversion , CVS) предполагают наличие единого репозитория для всех разработчиков, на котором хранятся все ветви проекта.

В распределенных системах (Git, Mercurial, Bazaar) история изменений хранится в локальных хранилищах разработчиков, и необходимые ее фрагменты синхронизируются между собой через центральный репозиторий.

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

Второй репозиторий содержит только ветвь master с рабочим каталогом, из которого запущен сайт. Он автоматически загружает изменения из основной ветви первого репозитория при создании ревизии и передает к нему же все свои изменения. Это сделано для подстраховки, потому что каталог обновляется в одностороннем порядке, а доступ разработчикам к нему следует закрыть. Однако и незаряженное ружье иногда стреляет.

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

Какую систему выбрать

В настоящее время существует множество систем управления версиями. Хотя схема настройки на веб-сайте описана в общем случае, чтобы показать ее универсальность, все-таки стоит упомянуть об основных разновидностях VCS.

Централизованные системы управления (например, Subversion, CVS) предполагают наличие единого репозитория для всех разработчиков, на котором хранятся все ветви проекта.

В распределенных системах (Git, Mercurial, Bazaar) история изменений хранится в локальных хранилищах разработчиков, и необходимые ее фрагменты синхронизируются между собой через центральный репозиторий.

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

Репозитории готовы. Осталось автоматизировать их синхронизацию. Для этого будут использоваться перехватчики (hooks) — сценарии репозиториев, исполняющиеся после определенных действий.

Понадобится два хука:
Post-update в первом репозитории. Вытягивает изменения из ветви master первого репозитория после ее обновления. Простой сценарий этого перехватчика синхронизирует обновление после ревизии:

Post-commit во втором репозитории. После каждого изменения он отправляет содержимое в первый. Этот хук — страховка. Он должен потребоваться только в случае прямого изменения файлов в рабочем каталоге.

Теперь необходимо разграничить доступ для разработчиков средствами сервера и VCS.

Системы управления версиями дают больше свободы разработчикам, уменьшая зависимость друг от друга.

Настройка завершена. Для проверки необходимо создать ревизию в основной ветке первого репозитория, и обновления появятся на сайте.

Преимущества и нюансы

Давайте с вами взвесим достоинства описанной нами схемы работы:
> Исключение конфликта слияния изменений. Благодаря синхронизации хранилищ не требуются специальные правила для выполнения обновлений.
> Распределенная разработка. Система управления версиями позволяет использовать ветвление, то есть создание различных вариантов документа с общей историей изменений до точки ветвления и с разными после нее. Когда ветвь достигает стабильности, происходит слияние. Параллельное выполнение нескольких задач является особенно актуальным для современной веб-разработки, так как обычно при создании и поддержке проекта точное планирование невозможно.
> Сохранение истории изменений. Так как основная информация об обновлениях фиксируется, и при необходимости имеется возможность одной командой восстановить любую из предыдущих версий документа.
> Простота управления исходным кодом. Средства системы позволяют сравнивать версии файлов построчно, контролируя их изменения.
> Простота интеграции. Данную систему можно применить к запущенному сайту без закрытия на обслуживание и перемещение файлов.
> Бесплатное программное обеспечение. Большинство систем управления версиями является свободно распространяемыми

А что же на другой чаше весов?

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

Во-вторых, стоит озаботиться выделением места на сервере для репозиториев. Так как в них сохраняются все изменяемые файлы, то при наличии большого количества графики на сайте переполнение может оказаться неожиданной проблемой, несмотря на то что данные в хранилищах содержатся в сжатом виде. В этом случае необходимо правильно настроить проверку удаления старых ветвей и изменений.
Также, если ваш сайт использует базы данных, может возникнуть вопрос с контролем их обновлений. Так как исходный код таких файлов не является наглядным, иногда имеет смысл использовать функции сохранения сценария запросов к СУБД. Наконец, не надо забывать о специализированных продуктах, служащих для развертывания и обновления приложений, например, Capistrano. В некоторых случаях лучше воспользоваться ими.
• • •
Системы управления версиями дают больше свободы разработчикам, уменьшая зависимость друг от друга, и время, потраченное на понимание их функционирования, окупится при дальнейшей разработке.
О подобных системах можно говорить бесконечно, однако лучший способ оценить удобство использования — это перевести на VCS свой сайт, как уже сделали многие известные фирмы.

Источник: журнал «Системный администратор», №6 за 2015 

Если Вам необходима установка и настройка систем контроля версий обращайтесь: [email protected]