Рубрика:
Разработка /
Инструменты
|
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
ДМИТРИЙ ПОШЕХОНОВ, инженер-программист, г. Москва. Сфера интересов: сетевые технологии, веб-приложения, рок-н-ролл, mr@toycru.ru
Использование VCS для обновления и поддержки веб-сайтов
Организация веб-сервера с применением системы управления версиями поможет избежать ошибок слияния изменений и облегчит распределенную разработку сайта
Грегори Робертс в романе «Шантарам» писал, что зло бывает порождено стараниями людей изменить что-то к лучшему. При улучшении веб-ресурса таким злом может явиться возникновение регрессивных ошибок. Зачастую разработчик вооружается каким-либо движком с функциями публикации и резервного копирования, не задумываясь о дополнительном контроле обновлений. Но однажды, полдня потрудившись над серьезной доработкой, он обнаружит, что егогениальный скрипт затерт файлом незадачливого коллеги, не удосужившегося взглянуть на дату изменений.
Эта статья расскажет, как обезопасить веб-разработчиков от подобных неприятностей, используя систему управления версиями, и какую схему организации веб-сервера предпочтительнее использовать.
Как это работает
В общем случае системы управления версиями (Version Control System, VCS) предназначены для контроля изменений и возможности создания нескольких версий разрабатываемого проекта. При распределенной разработке они позволяют систематизировать работу с несколькими вариантами одних и тех же документов.
Вся история изменений проекта находится в структурированном хранилище (репозитории), через который взаимодействуют разработчики. Репозиторий содержит служебные файлы проекта – это проиндексированные и зашифрованные специальным образом обновления. Также он может содержать и рабочую версию проекта. Это позволяет всем разработчикам получать различные версии документов из репозитория, создавать свою ветвь изменений, фиксировать этиизменения (создавать ревизию), а также откатывать рабочую копию к любой предыдущей ревизии. Такой механизм обеспечивает синхронизацию обновлений.
Как это может помочь при сопровождении сайта?
Стандартная схема поддержки веб-проекта выглядит следующим образом: разработчики вносят изменения на веб-сервер сайта, который в то же время просматривают пользователи. Если несколько разработчиков изменяют один и тот же документ, то первое обновление будет стерто вторым, и пользователь получит некорректную информацию (см. рис.1). Потребуется найти предыдущие версии, чтобы откатить проект, и выяснить причину получившегося несоответствия.
Рисунок 1. Возникновение ошибок при распределенной веб-разработке
Возможность возникновения подобного конфликта приводит к необходимости дополнительного создания сложных правил обновления и сильно мешает распределенной веб-разработке.
И тут нам на помощь приходит система контроля версий, причем для поддержки веб-сайтов наиболее эффективна та схема, при которой на веб-сервере находится два репозитория.
Первый репозиторий служит местом сбора изменений, поступающих от всех разработчиков. Он содержит ветвь с основной версией сайта, master, и необходимое количество дополнительных, например, ветвь разработки dev и ветвь изменений hotfix. Разработчики взаимодействуют с репозиторием через консольные приложения и клиенты используемой VCS. Это связующее звено между ними и действующим проектом. Но на самом репозитории нет рабочих файлов сайта, только служебные, отображающие внесенные на сервер изменения (см. рис. 2).
Рисунок 2. Распределенная веб-разработка с использованием двух репозиториев VCS
Второй репозиторий содержит только ветвь master с рабочим каталогом, из которого запущен сайт. Он автоматически загружает изменения из основной ветви первого репозитория при создании ревизии и передает к нему же все свои изменения. Это сделано для подстраховки, потому что каталог обновляется в одностороннем порядке, а доступ разработчикам к нему следует закрыть. Однако и незаряженное ружье иногда стреляет.
Таким образом, происходит синхронизация и установка обновлений, а сайт всегда содержит самую свежую версию. В случае необходимости проект можно будет откатить на предыдущий этап средствами VCS.
Какую систему выбрать
В настоящее время существует множество систем управления версиями. Хотя схема настройки на веб-сайте описана в общем случае, чтобы показать ее универсальность, все-таки стоит упомянуть об основных разновидностях VCS.
Централизованные системы управления (например, Subversion [1], CVS [2]) предполагают наличие единого репозитория для всех разработчиков, на котором хранятся все ветви проекта.
В распределенных системах (Git [3], Mercurial [4], Bazaar [5]) история изменений хранится в локальных хранилищах разработчиков, и необходимые ее фрагменты синхронизируются между собой через центральный репозиторий.
Для работы с веб-проектами я рекомендую использовать распределенные системы, так как в них намного удобнее манипулировать ветвями разработки. Каждый программист может создавать свою ветвь в локальном хранилище, незагружая центральный репозиторий. Кроме того, благодаря распределенной модели в таких системах выше скорость выполнения операций и уровень безопасности.
Статью целиком читайте в журнале «Системный администратор», №6 за 2015 г. на страницах 63-65.
PDF-версию данного номера можно приобрести в нашем магазине.
- Сайт Subversion – https://subversion.apache.org.
- Сайт CVS – http://www.nongnu.org/cvs.
- Сайт Git – http://git-scm.com.
- Сайт Mercurial – http://mercurial.selenic.com.
- Сайт Bazaar – http://bazaar.canonical.com.
- Сайт GitHub – https://github.com.
- Установка Git – http://git-scm.com/book/ru/v2/Введение-Установка-Git.
- Сайт Capistrano – http://capistranorb.com.
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|