Организация командной разработки интернет-проекта (с использованием Git и 1С-Битрикс)

    Помнится, в 90-х годах существовала такая профессия (или призвание) — вебмастер. Так называли человека, который занимался разработкой интернет-сайтов: дизайнер, верстальщик, программист и контент-менеджер — в одном лице. Времена меняются. Современные интернет-проекты — это, зачастую, плод труда 5 — 10 человек. Командный труд.

    Какой бы сплоченной и дружной ни была команда, работа над общим проектом — это почва для потенциального конфликта. А если в команде — конфликт, проект — обречен на провал. Лебедь, рак и щука — не сдвинут повозку с места. Самый распространенный рабочий конфликт начинается с претензии: «Вы вот тут вчера правили, и у нас вот там — отвалилось». А дальше все оскорбляются и начинают выяснять отношения, национальность, гражданство, вероисповедание, пол и возраст в то время, как работа — простаивает. Думаю, такая ситуация знакома каждому.

    Вероятность возникновения подобного рода конфликта в команде может быть сведена к нулю за счет использования системы контроля версий. В данной статье я хочу поделиться нашим опытом настройки системы контроля версий 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С-Битрикс

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 31

      +3
      Эта статья уже не актуально, т.к. в Bitrix 14, свои компоненты, модули, темплейты можно хранить в каталоге local, а каталог bitrix можно полностью запихать в .gitignore
        –4
        Для новых проектов — да. Но включать каталог bitrix в .gitignore целиком — опасно в любом случае. Где гарантия, что разработчики не залезут в ядро? Ядро должно так же контролироваться системой.
          +6
          В команде должно быть строго запрещено вносить правки в ядро.
            –2
            Однозначно, должно быть. Но контролировать автоматически — нужно обязательно. Конечно, есть битриксовский тест на модификации ядра. Но, я думаю, важно заметить правки в ядре сразу, как только они были внесены.
              –1
              Помимо команды есть риск получения доступа и вмешательства ЗЛОУМЫШЛЕННИКА (чтобы 1С-Битрикс не говорили о безопасности, ведь всегда может утечь логин/пароль от ФТП или админки и не быть ограничения на доступ по IP или ещё какая беда).
              А всегда приятно видеть вовремя появление таких вот «нежданчиков».
                –2
                Кстати, да. Бывают еще случаи, когда на сервере — вирус — перезаписывает файлы в папке ядра. Сталкивались — только благодаря системе контроля версий и обнаружили его наличие — вовремя.
                  –1
                  В продукте есть инструмент «контроль целостности» в модуле проактивной защиты.
                  Он хранит хеши, названия и даты модификации — в принципе этого достаточно для того чтобы обнаружить.

                  P.S. но инструмент конечно устарел… контроль версий лучше в 100 раз. =)
                0
                Обновления опять же. Бывает, что их нужно быстро откатить. Да и смотреть, что там новенького добавили — интересно, а в коммите — сразу это все наглядно видно.
                  0
                  Простите, а где Вы откатываете обновления? На продакшене?
                    0
                    На деве, как правило. А в многосайтовой системе — на продакшене.
                      0
                      А вы того, смелые, я последнее время даже у нас на сайте сразу битрикс не обновляю, так через пару тройку месяцев, версии 12, 12.5 и 14 очень подкосили мою веру в обновления битрикс, надеюсь с приходом Юрия Волошина ситуация поменяется.
                        0
                        Мы тоже сначала стараемся пробовать «в сторонке». Но сказать, что в продакшен никогда не попадает того, что следует откатить — было бы враньем. На то и система контроля версий — она страхует.
                    0
                    И как вы откатываете базу? При обновлениях меняется не только код.
                      0
                      Базу бекапим перед обновлением, естественно. Причем, для интернет-магазинов стандартного битриксовского механизма бакапа базы — не хватает, потому что за время, пока принимается решение накатить бекап базы — могут новые заказы нападать. Мы используем и битриксовский инструмент бекапа, и реплицируем файлы БД, и отдельно дампы таблиц снимаем.
                    –1
                    У вас идеализированное представление о сферической команде в вакууме. Запреты и правила не означают, что никто и никогда не попытается их нарушить. Контроль должен быть четкий. Во всем. Когда разработчик знает, что вечером весь его код пересмотрят и перечитают — у него и соблазна не возникнет делать что-то, что запрещено правилами. А вот если инструментов контроля нет — вы можете хоть 300 раз что-то запретить, а нарушать ваши запреты — будут снова и снова.
                      0
                      Давайте тогда камеры поставим, направим объективы этих камер в мониторы разработчиков и будем их контролировать.
                      Есть четкий паттерн которым вся команда должна руководствоваться и грамотный разработчик никогда не полезет в ядро системы и не будет его трогать, но если мы говорим за кучку «рас… ев» называемой командой, то тут надо в принципе менять всю идеологию производства и разработки.
                        0
                        Команда — это динамически развивающийся организм. Есть стажеры, есть новички. Не все сразу рождаются гуру с усами. И это нормально. А камеры при наличии системы контроля версий — это лишнее.
                          0
                          В некоторых компаниях — ставят и камеры, хотя это, на мой взгляд, уже перегиб. Знаете, управлять «грамотными разработчиками» — может любой. Но в том и заключается талант грамотного руководителя проекта, чтобы эффективно контролировать, направлять разработчиков. И в итоге добиться высокого качества работы вне зависимости от исходных данных каждого члена команды.
                      0
                      Для этого есть монитор качества, регламенты внутри компании и банальный # find -ctime
                        0
                        Да, и зачем система контроля версий, когда можно обязать разработчиков в блокнотик записывать, какие изменения и в каких файлах они делали. Ваш «банальный # find -ctime» позволит определить, кто правил файл и какие именно правки были в него внесены?
                          0
                          Нет конечно. Если вы заранее готовитесь к отлову таких кодеров, правящих ядро, то добавляйте в гит всё что пожелаете.
                          Но вообще проблема решает регламентом и запретом править ядро.
                      –1
                      Можно подумать, появление в Битрикс директории local снимает необходимость в системе контроля версий. Какие директории включать, а какие не включать в .gitignore — это личное, внутренне дело каждой команды. В статье приведены примеры файлов, которые вполне имеют право на существование.
                      0
                      но по поводу дополнительных дев. сайтов необходимо предварительно консультироваться с технической поддержкой Битрикс по поводу правомерности такой системы с точки зрения лицензионного договора).

                      По лицензионному соглашению битрикса можно создавать два сайта на одной копии движка.
                      БД можно только одну, т.е. она будет общая. Тут мы имеем проблему с разработкой, ибо базу нужно резать по-живому, если не нарушать лицензию.
                      Временно еще можно создавать сайт с другой БД, но он должен быть скрыт из паблика. А тут проблема в том, что в скрытом сайте может быть только один пользователь админ. Т. е. всем тестерам нужно давать админские права.
                        0
                        Для этих целей у битрикса есть специальный тип лицензий NFR
                          0
                          NFR — лицензия для партнёров для внутреннего использования. Свой сайт, тестовые площадки и т.п.
                          Их ограниченное количество, так что если у вас 10-20 клиентов хотя бы, то поставить тестовый\разработческий сайт на NFR просто не удастся.
                          см. ниже про установку копии боевого сайта в тестовой среде. Это разрешено. Можете удостовериться у саппорта.
                            0
                            Я не буду афишировать количество проектов, которое находится в разработке, но их больше 20, везде мы используем NFR ключи.
                            Для каждой редакции битрикса у нас свой NFR ключ. Когда то были проблемы с тем, что их банили и надо было писать в саппорт, сейчас же таких проблем не испытываем.
                            И да, в битриксе всегда идут на уступки.
                            0
                            Это вариант только для студий. А у нас своя команда разработчиков.
                            0
                            не-не-не!
                            Локальную копию (живущую у вас в офисе и закрытую файрволом от интернета, например) они вполне себе разрешают!
                            Вот ежели понадобится 3 копия (схема тест-прелайв-бой), то придётся или докупать или договариваться с саппортом.
                              0
                              Разрешают.
                              Но я говорю про то, что в соглашении написано, а не негласно делается.
                              Кроме того, такое негласное положение дел ведет к ошибкам error_wrong_code при обновлении.
                            –1
                            Спасибо за статью — давно искал вот такое простое, ясное и последовательное руководство по начальным настройкам Git.
                              0
                              Насколько мне известно, держать директорию .git доступной через веб небезопасно: http://habrahabr.ru/post/70330/ https://bo0om.ru/vzlom

                              Only users with full accounts can post comments. Log in, please.