Какой бы сплоченной и дружной ни была команда, работа над общим проектом — это почва для потенциального конфликта. А если в команде — конфликт, проект — обречен на провал. Лебедь, рак и щука — не сдвинут повозку с места. Самый распространенный рабочий конфликт начинается с претензии: «Вы вот тут вчера правили, и у нас вот там — отвалилось». А дальше все оскорбляются и начинают выяснять отношения, национальность, гражданство, вероисповедание, пол и возраст в то время, как работа — простаивает. Думаю, такая ситуация знакома каждому.
Вероятность возникновения подобного рода конфликта в команде может быть сведена к нулю за счет использования системы контроля версий. В данной статье я хочу поделиться нашим опытом настройки системы контроля версий Git с использованием сервиса github.com для командной разработки под систему управления контентом 1С-Битрикс. Расскажу с точки зрения руководителя проекта, а не администратора сервера.
В простейшем варианте организации командной работы над проектом нам необходим — один основной сайт на сервере — будем называть его продакшеном, один сайт для тестирования (девелоперский сайт) — на сервере рядом с ним (дев. сайт) + по локальной копии сайта у каждого разработчика. (Девелоперских сайтов на сервере может быть несколько, но по поводу дополнительных дев. сайтов необходимо предварительно консультироваться с технической поддержкой Битрикс по поводу правомерности такой системы с точки зрения лицензионного договора).
Каждый разработчик будет работать над проектом в своей локальной копии сайта, в отдельной ветке Git для каждой решаемой задачи. В конце для каждый разработчик делает коммит в репозиторий, хранящийся на github.com и только один разработчик — ведущий, проверяет и объединяет ветки сначала на девелоперском сайте на сервере, а потом выкатывает полученный результат на продакшен. (По моему субъективному мнению, двоевластие на интернет-проекте — недопустимо. Даже если слияние веток и тестирование будет отнимать все рабочее время ведущего разработчика проекта — никто кроме него не должен вносить изменения на продакшен — сайт) В начале дня — разработчики обновляют свои репозитории с гитхаба.
В случае, когда необходимо изменение структуры БД, разработчики сначала вносят изменения в своих локальных копиях, пишут список изменений ведущему разработчику, ведущий разработчик вносит их на продакшене, делает бекап БД продакшена, который затем накатывается на дев-сайт и на все локальные дев-сайты. Дополнительно настраивается репликация БД (но это уже тема для другой статьи).
Итак, мы имеем выделенный сервер, два настроенных виртуальных хоста и установленное серверное ПО git — это, как правило, могут сделать для нас сотрудники хостинга, на котором мы покупаем сервер.
В директории основного сайта разворачиваем бекап сайта стандартными средствами Битрикс (или руками), директория девелоперского сайта пока пусть будет пустой.
Регистириуем корпоративный тариф на github.com Для системы, рассмотренной в данной статье, нам хватит тарифа за 25$ в месяц. Заводим приватный репозиторий, добавляем существующих пользователей githab к организации (или заводим новых пользователей) — это все делается очень прозрачно и удобно, поэтому не будем подробно заостряться на этом моменте.
После того, как корпоративный приватный репозиторий заведен, нам нужно сделать первый коммит в него.
Заходим по ssh на наш сервер под пользователем с правами на запись в папки сайтов, переходим в директорию, в которой мы намерены инициировать репозиторий.
Репозиторий можно инициировать непосредственно в папке сайта (тогда важно не забыть потом защитить папку .git в файле .htaccess от скачивания), а можно инициировать его в наддиректории (вариант, когда файлы каждого сайта лежат не сразу в директории www или директории dev, а в подкатологе, к примеру, dev/httpfiles, www/httpfiles А репозитории мы инициируем соответственно в директориях www и dev. Если сервер настраивается с нуля или если админу не лень перепрописать виртуальные хосты— этот вариант предпочтительнее).
Перед тем, как инициировать репозиторий для основного сайта, необходимо определиться, какие папки и файлы необходимо включать в репозиторий, а какие — нет — сформировать файл .gitignore.
Пример файла .gitignore для 1С-Битрикс для случая, когда репозиторий инициируется в директории сайта:
/bitrix/backup
/bitrix/cache
/bitrix/crontab
/bitrix/managed_cache
/bitrix/managed_flags
/bitrix/modules/*.log
/bitrix/php_interface/crontab
/bitrix/php_interface/dbconn.php
/bitrix/stack_cache
/logs
/upload
/.gitignore
/.htaccess
/urlrewrite.php
/*.log
/*.sql
/*.txt
/*.xml
/*.dt
Пример файла .gitignore для 1С-Битрикс для случая, когда репозиторий инициируется в наддиректории:
/httpfiles/bitrix/backup
/httpfiles/bitrix/cache
/httpfiles/bitrix/crontab
/httpfiles/bitrix/managed_cache
/httpfiles/bitrix/managed_flags
/httpfiles/bitrix/modules/*.log
/httpfiles/bitrix/php_interface/crontab
/httpfiles/bitrix/php_interface/dbconn.php
/httpfiles/bitrix/stack_cache
/httpfiles/logs
/httpfiles/upload
/httpfiles/.htaccess
/httpfiles/urlrewrite.php
/httpfiles/*.log
/httpfiles/*.sql
/httpfiles/*.txt
/httpfiles/*.xml
/httpfiles/*.dt
То есть мы не будем контролировать изменения в папке бекапов (/bitrix/backup), папках кеша (/bitrix/cache, /bitrix/managed_cache, /bitrix/managed_flags, /bitrix/stack_cache), папках с заданиями крону (/bitrix/crontab), папке с логами (/logs), папке с загрузками (/upload).
Папку с загрузками /upload на всех девелоперских копиях сайта, расположенных на одном с ним сервере, имеет смысл делать симлинком на папку /upload продакшен-сайта.
Символическую ссылку в директории /dev/ — корневой директории девелоперского сайта создаем командой
ln -s /path/to/www/upload К слову о символических ссылках. При конфигурировании многосайтовой системы на одном ядре 1С-Битрикс по 2му типу, папку bitrix мы так же должны будем исключить из основного репозитория. Потому что физически эта директория будет существовать только на одном сайте системы, а на других — будут символические ссылки на нее. Но так как контролировать изменения файлов этой папки все равно нужно, целесообразно будет завести для нее отдельный репозиторий.
Файл /bitrix/php_interface/dbconn.php содержит индивидуальные для каждого виртуального хоста настройки (в частности настройки соединения с БД), поэтому этот файл мы добавляем в исключения git.
Файл /urlrewrite.php — это файл с правилами обработки ЧПУ адресов Битрикс — он может быть перезаписан (сортируется внутри) самим движком, поэтому исключим и его.
Файлы .gitignore и .htaccess тоже должны лежать в исключениях. В исключения так же стоит добавить файлы логов, текстовые файлы, xml-файлы – все то, что не относится непосредственно к программному коду.
После того, как мы определились с содержимым .gitignore и создали файл .gitignore в директории будущего репозитория можно инициировать репозиторий для продакшен-сайта. Для этого нам сначала необходимо позаботиться об авторизации нашего серверного ssh-пользователя на githab — сгенерировать для него ключ.
Выполняем команду
ssh-keygen -t rsa -C "bitrix@имя.сайта" email можно вписать любой, но с email вида bitrix@имя.сайта легче идентифицировать ключ на гитхабе.
Переходим на github.com/settings/ssh и добавляем новый ключ — данные самого ключа берём из файла /path/to/.ssh/id_rsa.pub
Проверяем подключение:
ssh-T git@github.com Инициируем репозиторий в директории основного сайта (или в наддиректории):
переходим в /path/to/www/ и выполняем команды:
git add README.md git commit -m "first commit" git remote add origin git@github.com:организация/имя_репо.git git push -u origin master После того, как репозиторий для основного сайта инициирован, зальем все файлы проекта в репозиторий гитхаб:
git add . git commit -m “second commit” git push Теперь клонируем репозиторий в директорию девелоперского сайта:
cd git clone git@github.com:организация/имя_репо.git dev После этого в директории девелоперского сайта создадим символическую ссылку на папку upload как было описано выше. Затем стандартными средства Битрикс сделаем бекап БД основного сайта, и развернем его на девелоперском — файл, хранящий подключение к БД при этом создастся для дев сайта автоматически.
Теперь аналогичным образом можно создать клоны репозитория на локальных машинах разработчиков. Для этого им необходимо поставить любой комплект ПО git на свою локальную машину (командная Git строка идет в любом комплекте), запустить командную строку, сгенерировать ключ, добавить его на гитхаб, клонировать репозиторий в директорию виртуального хоста на локальной машине, а папку upload просто слить с основного сайта, накатить дамп БД с основного сайта.
После этого можно расслабиться и наслаждаться командной работой, выстраивая с коллегами дружеские отношения без ссор и споров, оперативно откатывая некорректные изменения — без поиска виноватых.
Ссылки по теме:
— Система контроля версий Git
— Что такое символические ссылки
— Руководство по установке и настройке 1С-Битрикс
ссылка на оригинал статьи http://habrahabr.ru/post/219569/