n
Как это работает
(Version Control System, VCS) системы управления версиями используются для контроля изменений и возможности создания нескольких версий разрабатываемого проекта. Во время распределенной разработки они помогают систематизировать работу с несколькими версиями одних и тех же документов.nnВсе изменения в проекте размещаются в структурированном хранилище (репозитории), с помощью которго взаимодействуют разработчики. Репозиторий содержит служебные файлы проекта – это проиндексированные и шифрованные изменения. Кроме того содержит рабочую версию проектов. Благодаря этому все разработчики могут получать различные версии документов из репозитория, создавать свою ветку изменений, фиксировать изменения (создавать ревизию), а также откатывать рабочую копию к любой предыдущей версии. Данный метод позволяет обеспечить синхронизацию обновлений.n
Как это используется при сопровождении сайта?
Стандартная схема поддержки веб-проекта выглядит следующим образом: разработчики вносят изменения на web-сервер сайта, который в свою очередь просматривают пользователи. Если несколько разработчиков изменяют один и тот же документ, то первое изменения будет стерто вторым, и пользователь получит некорректную информацию. Потребуется найти предыдущие версии, чтобы откатить проект, и выяснить причину получившегося несоответствия.nn
nnПодобные конфликты изменений приводят к надобности создания сложных правил изменения и мешает распределенной работе программистов.nnРешением данной проблемы является система контроля версий, причем для поддержки веб-сайтов наиболее эффективна та схема, при которой на веб-сервере находится два репозитория.nnПервый репозиторий используется для сбора изменений, приходящих от всех разработчиков. Который содержит ветку с основной версией сайта, master, и дополнительных, например, ветка разработки dev и ветка изменений hotfix. Программисты работают с репозиторием через VCS консоль и клиенты . Таким образом происходит связь разработчиков и проекта. В первом репозитории нет рабочих файлов сайта, только служебные, содержащие изменения.nn
nnВторой репозиторий содержит только ветку master с рабочим каталогом, где и запущен сайт. Репозиторий в автоматическом режиме применяет изменения из основной ветки первого репозитория при создании версиии изменения и передает к нему же все свои изменения. Данное решение для страховки, что бы каталог обновлялся в одностороннем порядке, а доступ программистам к нему нужно закрыть.nnПроисходит синхронизация и установка изменений, сайт содержит самую свежую версию. В случае проблем проект можно откатить на средствами VCS на предыдущую версию.n
Какую систему выбрать
В настоящее время существует множество систем управления версиями. Хотя схема настройки на веб-сайте описана в общем случае, чтобы показать ее универсальность, все-таки стоит упомянуть об основных разновидностях VCS.nnЦентрализованные системы управления (например, Subversion , CVS) предполагают наличие единого репозитория для всех разработчиков, на котором хранятся все ветви проекта.nnВ распределенных системах (Git, Mercurial, Bazaar) история изменений хранится в локальных хранилищах разработчиков, и необходимые ее фрагменты синхронизируются между собой через центральный репозиторий.nnДля работы с веб-проектами я рекомендую использовать распределенные системы, так как в них намного удобнее манипулировать ветвями разработки. Каждый программист может создавать свою ветвь в локальном хранилище, незагружая центральный репозиторий. Кроме того, благодаря распределенной модели в таких системах выше скорость выполнения операций и уровень безопасности.nnВторой репозиторий содержит только ветвь master с рабочим каталогом, из которого запущен сайт. Он автоматически загружает изменения из основной ветви первого репозитория при создании ревизии и передает к нему же все свои изменения. Это сделано для подстраховки, потому что каталог обновляется в одностороннем порядке, а доступ разработчикам к нему следует закрыть. Однако и незаряженное ружье иногда стреляет.nnТаким образом, происходит синхронизация и установка обновлений, а сайт всегда содержит самую свежую версию. В случае необходимости проект можно будет откатить на предыдущий этап средствами VCS.n
Какую систему выбрать
В настоящее время существует множество систем управления версиями. Хотя схема настройки на веб-сайте описана в общем случае, чтобы показать ее универсальность, все-таки стоит упомянуть об основных разновидностях VCS.nnЦентрализованные системы управления (например, Subversion, CVS) предполагают наличие единого репозитория для всех разработчиков, на котором хранятся все ветви проекта.nnВ распределенных системах (Git, Mercurial, Bazaar) история изменений хранится в локальных хранилищах разработчиков, и необходимые ее фрагменты синхронизируются между собой через центральный репозиторий.nnДля работы с веб-проектами я рекомендую использовать распределенные системы, так как в них намного удобнее манипулировать ветвями разработки. Каждый программист может создавать свою ветвь в локальном хранилище, незагружая центральный репозиторий. Кроме того, благодаря распределенной модели в таких системах выше скорость выполнения операций и уровень безопасности.n
$ cd ~/www # директория сайтаn$ git init # инициализация репозиторияn$ git add . # добавление содержимогоn# первая ревизияn$ git commit -m "first commit of site files"n$ cd ..n$ mkdir repo1.git # каталог для нового репозитория $ cd repo1.gitn$ git --bare init # инициализация bare-репозитория $ cd ~/wwwn# добавление удаленного репозитория $ git remote add repo1 ~/repo1.gitn$ git push hub master
nРепозитории готовы. Осталось автоматизировать их синхронизацию. Для этого будут использоваться перехватчики (hooks) — сценарии репозиториев, исполняющиеся после определенных действий.nnПонадобится два хука:nPost-update в первом репозитории. Вытягивает изменения из ветви master первого репозитория после ее обновления. Простой сценарий этого перехватчика синхронизирует обновление после ревизии:n
cd $HOME/www || exitnunset GIT_DIR # очистка переменной GIT_DIRngit pull hub master # извлечение данных из основной ветвиnexec git-update-server-info # обновление рабочих файлов
Post-commit во втором репозитории. После каждого изменения он отправляет содержимое в первый. Этот хук — страховка. Он должен потребоваться только в случае прямого изменения файлов в рабочем каталоге.n
git push hub
nТеперь необходимо разграничить доступ для разработчиков средствами сервера и VCS.nnСистемы управления версиями дают больше свободы разработчикам, уменьшая зависимость друг от друга.nnНастройка завершена. Для проверки необходимо создать ревизию в основной ветке первого репозитория, и обновления появятся на сайте.n
Преимущества и нюансы
Давайте с вами взвесим достоинства описанной нами схемы работы:n> Исключение конфликта слияния изменений. Благодаря синхронизации хранилищ не требуются специальные правила для выполнения обновлений.n> Распределенная разработка. Система управления версиями позволяет использовать ветвление, то есть создание различных вариантов документа с общей историей изменений до точки ветвления и с разными после нее. Когда ветвь достигает стабильности, происходит слияние. Параллельное выполнение нескольких задач является особенно актуальным для современной веб-разработки, так как обычно при создании и поддержке проекта точное планирование невозможно.n> Сохранение истории изменений. Так как основная информация об обновлениях фиксируется, и при необходимости имеется возможность одной командой восстановить любую из предыдущих версий документа.n> Простота управления исходным кодом. Средства системы позволяют сравнивать версии файлов построчно, контролируя их изменения.n> Простота интеграции. Данную систему можно применить к запущенному сайту без закрытия на обслуживание и перемещение файлов.n> Бесплатное программное обеспечение. Большинство систем управления версиями является свободно распространяемымиn
А что же на другой чаше весов?
Во-первых, необходимо продумывать и настраивать правила обновления и разграничения, воплощающие описанную схему. В зависимости от величины проекта и требований к безопасности может понадобиться добавить ре-позитории для разработки.nnВо-вторых, стоит озаботиться выделением места на сервере для репозиториев. Так как в них сохраняются все изменяемые файлы, то при наличии большого количества графики на сайте переполнение может оказаться неожиданной проблемой, несмотря на то что данные в хранилищах содержатся в сжатом виде. В этом случае необходимо правильно настроить проверку удаления старых ветвей и изменений.nТакже, если ваш сайт использует базы данных, может возникнуть вопрос с контролем их обновлений. Так как исходный код таких файлов не является наглядным, иногда имеет смысл использовать функции сохранения сценария запросов к СУБД. Наконец, не надо забывать о специализированных продуктах, служащих для развертывания и обновления приложений, например, Capistrano. В некоторых случаях лучше воспользоваться ими.n• • •nСистемы управления версиями дают больше свободы разработчикам, уменьшая зависимость друг от друга, и время, потраченное на понимание их функционирования, окупится при дальнейшей разработке.nО подобных системах можно говорить бесконечно, однако лучший способ оценить удобство использования — это перевести на VCS свой сайт, как уже сделали многие известные фирмы.nnИсточник: журнал «Системный администратор», №6 за 2015 nnЕсли Вам необходима установка и настройка систем контроля версий обращайтесь: [email protected]