Как я перестал беспокоиться и стал коммитить в GIT на большом 1С-Битрикс проекте

Мне довелось продолжительное время работать менеджером-админом (эдакий играющий тренер) на большом 1С-Битрикс веб проекте: более 40 сайтов для разных организаций холдинга из разных стран, Oracle БД, редакция «Веб-Кластер», более 100 Гб файлов, несколько лет истории, более 20 правок ядра переживших множество обновлений Ядра, параноидальный режим безопасности и… прямые изменения функционала «руками» на боевом сервере без каких либо намёков на версионный контроль…
Очень грустная картина, вызывающая множество «несчастных случаев на производстве», которую после очередного инцидента была приказано исправить.

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

Собственно все наши беды были из-за 2 основных причин:

1. Большой проект нёсся на полном ходу по своей узкоколейке в светлое будущее, и менять рельсы под ним в этот момент было немного затруднительно.
2. Несмотря на огромное количество литературы, посвящённой системам контроля версий и GIT в частности, почти вся она страдает от отсутствия сценариев и чётких указаний. Например, великолепный Pro Git прекрасно описывает каждую отдельную функцию и операцию, но почти не даёт представления о том, с какого конца начать этим богатством пользоваться.

Повествование будет разбито на части:

• Описание обстановки
• Инструменты
• Инструкции
  
  • 3.1 Инициализация Репозитория
  • 3.2 Накат обновления задачи
  • 3.3 Фиксация ежедневных изменений (в конце дня)
  • 3.4 Откат изменений
• Заключение
• FAQ

Часть 1 — Описание обстановки

Я нахожусь непосредственно на территории Заказчика и служу своеобразной перемычкой между ним и Разработчиком.

Добрые безопасники Заказчика ограничивают доступ ко всему, что может быть хоть чем-то заменено.
Вероятно, эта статья никогда бы не появилась (а скрывающиеся за ней проблемы были бы гораздо меньше), если бы у меня и у Разработчика были SSH/FTP доступ.
Однако, такого доступа не было, нет, и вероятно не будет, поскольку чисто формально внесение изменений возможно 2 путями:

• Удалённо через админку 1С-Битрикс
• Непосредственно на территории Заказчика (под чутким присмотром)

Поэтому при накате некоторых задач я периодически получал от менеджера Разработчика звонок:

Алексей, мы тут хотим накатить задачу ХХХ. Забекапьте пожалуйста init.php, а то мало ли...

Естественно «мало ли» порой наступало, и просьба восстановить указанный файл шла по всей цепочке, а сайт был в это время недоступен…

Аналогично доступ к Центральному Репозиторию (GitLab), когда он был создан, был ограничен полностью территорией Заказчика. Это приводит к важным ограничениям по внедрению GIT:

• Разработчик не может получить репо с серверов Заказчика (только если руками скопирует папку .git)
• Разработчик не может накатить обновление средствами GIT. Накат происходит вручную.

Системы контроля версий Заказчика и Разработчика фактически изолированы друг от друга (сообщение происходит исключительно в ручном режиме через админку 1С-Битрикс).

А ещё административный доступ (1 группа 1С-Битрикс) ограничен по времени. Есть специальный скрипт, который на уровне БД (Oracle) раздаёт права мне и Разработчику в 9.00 и отбирает в 17.50 по Москве.

Я знаю, что это кошмар. Не стоит напоминать мне об этом в комментариях. =)

Часть 2 — Инструменты

2.1 Сервера

Prod — основной боевой сервер.

По указанию Начальства были созданы помимо Боевого сервера 2 копии:

• Test — может быть пересоздан по запросу (процесс продолжительный, поскольку требует задействования людей из других управлений, ориентировочный срок реализации — сутки). Сервер доступен только из сети Заказчика и Разработчика.
• Prelive — автоматически пересоздаётся 1 раз в сутки (ночью), затирая все внесённые изменения, берёт актуальную на момент создания версию Боевого сервера. Сервер доступен только из сети Заказчика и Разработчика.

Доступ ко всем 3 серверам как у меня, так и у Разработчика только по https (при этом по сертификату происходит автоматическая авторизация в 1С-Битрикс).
Доступ по SSH/FTP только у моего непосредственного начальника. =(
GitLab — отдельный сервер для развёртывания GitLab, используется в качестве Центрального Репозитория. Сервер доступен только из сети Заказчика по прямому IP (предположим, что 172.***.***.61 для конкретики данной статьи, но на самом деле это может быть любой IP или домен, в вашем случае, например github.com).
Все 3 веб-сервера (Prod/Test/Prelive) имеют ssh доступ к GitLab.
Я имею доступ к GitLab только по http (фактически могу лишь создавать/удалять репозитории и смотреть красивую картинку с ветками).
DEV — Условное обозначение сегмента серверов и рабочих станций Разработчика. В рамках статьи не рассматривается. Все изменения из сегмента переносятся на сервера Заказчика руками через админку 1С-Битрикс мною, либо Разработчиком.

Первоначальная схема наката Задач предполагала прохождения всей цепочки:
DEV → TEST → PRELIVE → PROD
Предполагалась финальная проверка на «максимально актуальном» Прелайве перед накатом задачи на бой. Схема естественно оказалась очень муторной и малополезной.
В настоящий момент я отказался от неё в пользу использования 2 серверов для проверки Задач (на Test'е требующие длительной проверке, на Prelive'е быстро проверяемые):
DEV → TEST/PRELIVE → PROD
Передача кода с одного сервера на другой в сегменте Заказчика происходит ТОЛЬКО через Центральный Репозиторий (GitLab), так что схему наката можно представить в таком виде:

2.1.1 GIT на сервере

Устанавливается системным администратором. К сожалению, не могу ничего на эту тему действительно полезного рассказать (вопрос выходит за пределы моей компетенции).
Никаких особых манипуляций, кроме генерации SSH ключей (для связи между серверами и Центральным Репозиторием (GitLab)).
Инструкция легко гуглится, либо находится в разделе помощи GitLab.

2.1.2 Веб консоль на сервере (git_console.php)

Как уже было сказано выше, ни у меня, ни у Разработчика нет SSH доступа к серверам, поэтому для передачи команд GIT пришлось поставить отдельный скрипт, реализующий в браузере консоль.
Спасибо за него Elfet (статья про консоль на Хабре)
Мы внесли совсем незначительные изменения:

• Положили саму консоль в недоступную для Разработчика директорию в недрах сервера (чтобы ни Разработчик, ни я, ни «потенциальный Злоумышленник не могли внести изменения в код консоли). При этом в ядре мы положили доступный администраторам файл git_console.php, который просто подключает скрипт из недр;
• В настройках скрипта поставили ограничение на выполнение команд (только git, pwd и cd);
• Поменяли цвет фона консоли (Test — зелёный, Prelive — серый, Prod — чёрный). Это сделали после того как я пару рад запулил задачу „не туда“ =)
• Добавили ограничение доступа по сертификату (т.е. не каждый Админ имеет доступ к консоли. В тестовый период доступ был только у меня, после перевода в промышленную эксплуатацию доступ дали 1 программисту Разработчика).

Важное преимущество такого решения — автономность консоли! Т.е. даже если Разработчик неудачным росчерком пера изменением в init.php положит сайт, то консоль будет по прежнему работать (т.к. она не использует 1С-Битрикс) и Разработчик сам сможет откатиться.

2.1.3 Структура Репозиториев

К сожалению, далеко не все сайты в системе находятся под системой контроля версий, а только „головы“ холдинга. Это вызывает определённые неудобства и проблемы (например, когда Разработчик вносит правку в Ядро для кого-то из Дочек), однако в основном это проблема владельцев самих этих сайтов „на местах“. Возможно, в будущем несмотря на накладные расходы и они будут добавлены в GIT.
Схема реальной структуры репозиториев (названия и адреса частично затёрты):

Как видим в нашей структуре:

• Ядро вынесено в отдельный каталог
• Папки некоторых сайтов сгруппированы в отдельных каталогах „по смыслу“
• Некоторые сайты имеют свой персональный каталог /local/
• Некоторые сайты имеют групповой каталог /local/
• Некоторые репозитории имеют субмодули (репозитории внутри репозитория) — это как правило спец-проекты, которые редко обновляются после завершения, однако имеют серьёзные отличия как по логике, так и по контенту (на них часто распространяются серьёзно отличающиеся правила для .gitignore). Поэтому они вынесены отдельно, чтобы не создавать кашу.

Ни один репозиторий (даже в худшие свои времена) не превышал 300Мб.
Это достигнуто политическим решением не включать определённые типы контента (бинарных файлов, вроде PDF, avi, jpg и т.п.) в такие репозитории без необходимости и соответствующим запретом в .gitignore.

2.1.4 Документация

Все картинки (кроме КдПВ конечно) для этой статьи взяты из Документации, которая находится на специальном ресурсе, доступном Заказчику, мне и Разработчику.
Изначально (на период тестовой эксплуатации) черновики документации хранились у меня на машине, однако сейчас вся документация опубликована для доступа всей команды.

Часть 3 — Инструкции

Вот мы и добрались до самого интересного.
Если всё, что написано в части 1 — сугубо для создания контекста (дабы снискать снисхождение опытных пользователей), а в части 2 больше для углубления в вопрос (как раз для тех, у кого так же как у нас большой проект, стремительно приближающийся к Горизонту Событий), то часть 3 — это как раз те элементарные примеры инструкций, которых лично мне так не хватало для начала.
Я надеюсь, что те, кто не пользовался GIT, но хотят начать (даже если у них небольшой интернет-магазин на shared-хостинге) смогут попросить о настройки GIT техподдержку, а в качестве Центрального репозитория использовать GitHub или BitBucket и с помощью описанных ниже сценариев начнут работу. А в процессе уже смогут начать изучать документацию Pro Git и адаптируют свои методы работы, сделают их более гибкими и совершенными.
Всё вышеописанное родилось не в один день. Но даже когда оно наконец появилось, то остался вопрос КАК использовать всё это богатство.
Все приведённые ниже инструкции были написаны кровью и потом мною „для себя“.

3.1 Инициализация Репозитория

3.1.1 Инициализация Репозитория на Prod (и пересоздание Prod/Prelive)

Наиболее простой и правильный метод.
Заключается в том, что вы создаёте репозиторий на Бою, а потом копируете весь сайт (включая репозиторий) с Боя на Тест и Прелайв.
На примере каталога /local/ (общего для нескольких сайтов)

Web консоль (на PROD) – https://********.ru:1119/bitrix/admin/git_console.php
cd /u-app/bitrix/Apache/htdocs/site/******/local/ (переходим в каталог /local/ общий для сайтов Пресс-Службы из любого другого места)
pwd – определяем текущий каталог (проверяем местонахождение)
git status – проверка статуса GIT (должен показать отсутствие репозитория)
Положить .gitignore (см. образец в приложении)
git init
git config user.name "Zadoiny Alexey"
git config user.email "aleksey.zadoiny@******.ru"
git add -A .
git commit -m 'initital'
Создаём, если не был создан репо в GitLab (с именем local-******)
git remote add origin git@172.***.***.61:Alexey.Zadoiny/local-******.git
git push -u origin master

После создания репозитория в папку .git необходимо положить файл .htaccess со
следующим содержанием:

deny from all

3.1.2 Инициализация Репозитория на Prod (и перенос на пустой TEST/PRELIVE)

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

3.1.3 Инициализация Репозитория на Prod (и перенос на НЕпустой TEST/PRELIVE)

Зачем это нужно? Например, тестовые и боевые сервера уже созданы и настроены, а синхронизация между ними в ближайшее время не возможна, а директория содержит большое количество контента, не синхронизуемого с помощью системы контроля версий (например, бинарных файлов контента: pdf, jpg, swf, avi и т.д.)

3.1.4 Инициализация Репозитория Субмодуля на Prod (и перенос на НЕпустой TEST/PRELIVE)

Сложность с субмодулем заключается в том, что вам необходимо внести правку внутрь уже имеющейся экосистемы (Т.е. репозиторий уже существует, и вдруг вы хотите ему сказать „э, не, дорогой, вот тут будет забор, а за забором будет жить Вася!“)
В частности, если вы сперва развернёте какой-то функционал, закоммитите его, то чтобы создать на этом месте субмодуль все созданные файлы/каталоги придётся удалить (вопрос на TOSTER'е на эту тему).

3.2 Накат обновления задачи

Напомню, изначально данный процесс должен был идти по схеме:
DEV → TEST → PRELIVE → PROD
Поэтому схема обновления содержала 11 основных и 4 дополнительных шага и имело несколько разветвлений:

Сейчас схема упрощена до
DEV → TEST/PRELIVE → PROD


Примечание. На самом деле во всех инструкциях у меня не 1 адрес (cd ХХХХХ), а табличка со списком всех адресов. Т.е. при выполнении действия можно выбрать 1 любое и скопировать целиком (а не вспоминать пусть к дирректории того или иного репо)

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

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

3.2.0 Накат обновления задачи — Шаг 0

cd /u-app/bitrix/Apache/htdocs/bitrix/ — переходим в папку проекта. Проверяем себя с помощью команды pwd
git status — не должно быть незакоммиченных изменений.
git log — последний коммит должен соответствовать последнему коммиту Master ветки центрального репозитория GitLab
Если git log показал не последний коммит — переходим к шагам 3,4 и после наката актуального состояния с боя на тест/прелайв начинаем процедуру с начала.
Накат — переносим на тест/прелайв функционал задачи любыми средствами (FTP, админка).

3.2.1 Накат обновления задачи — Шаг 1

cd /u-app/bitrix/Apache/htdocs/bitrix/
git add -A .
git commit ­-m 'TIKET ######'
git push origin master:TIKET_######
Коммитим изменения, отправляем из ветки разработки (мастер на тестовом/прелайв сервере) в ветку задачи в центральном репозитории.

3.2.2 Накат обновления задачи — Шаг 2

cd /u-app/bitrix/Apache/htdocs/bitrix/
git status
git add -A .
git commit ­-m 'Prod changes #дата#'
git push origin master
Проверяем состояние боя.
Если Состояние боя изменилось (и тест/прелайв находятся в более неактуальном состоянии), то коммитим изменения и отправляем в центральный репозиторий для синхронизации.
Если изменений нет → перейти на Шаг 4.

3.2.3 Накат обновления задачи — Шаг 3

cd /u-app/bitrix/Apache/htdocs/bitrix/
git pull origin master
Если за время наката задачи на Тест/Прелайв Бой успел измениться (см. Шаг 2), следует накатить изменения с боя (через центральный репозиторий) на Тест/Прелайв и смерджить изменения.
Если GIT не удастся произвести мердж веток самостоятельно (возникнут конфликты, например в силу изменения в одних и тех же файлах), следует вручную разрешить конфликты.
В завершение шага → вернуться на Шаг 1.

3.2.4 Накат обновления задачи — Шаг 4

cd /u-app/bitrix/Apache/htdocs/bitrix/
git pull origin TIKET_######
Накатываем обновление задачи на Бой из центрального репозитория

3.3 Фиксация ежедневных изменений (в конце дня)

К сожалению, несмотря на описанный выше процесс у нас постоянно возникают изменения прямо на бою из-за 2 основных причин:

• Есть множество контент-редакторов, имеющих доступ к изменению файлов в публичной части боевого сервера (естественно с ограниченными правами, без доступа к редактированию php кода, но с возможностью изменения html разметки)
• Есть задачи Дочек, которые зачастую затрагивают ядро /bitrix/ (как правило появляются или изменяются шаблоны и компоненты)

Поэтому ежедневно в конце рабочего дня (а как вы помните из начала статьи после 17.50 по Москве Разработчик и я теряем возможность к редактированию php на Бою) я подвожу итог и коммичу все накопившиеся правки, произведённые вне моих задач.

Процесс полностью идентичен фиксации изменений на бою (см 3.1.2):
cd /u-app/bitrix/Apache/htdocs/bitrix/
git status
git add -A .
git commit ­-m 'Prod changes #дата#'
git push origin master

3.4 Откат изменений

1. Есть 3 типа ситуаций, когда необходимо произвести откат изменений (по мере ухудшения ситуации):
2. Откат на Тесте/Прелайве (не важно внесена ошибка или задача успешно проверена — нужно „освободить площадку“, никаких правок на Тесте/Прелайве не предвидится)
3. Откат на Бою незначительной ошибки, пришедшей через GIT (ключевое слово — незначительной. История версий представляет ценность например для анализа в GitLab, но на бой необходимо вернуть стабильную версию. Практикуется только для СВЕЖИХ правок)
4. Откат на Бою критической ошибки (ситуации из серии „Шеф, всё пропало!!!!1111одинодин“, когда работоспособность проекта критичнее чем красивая история в GitLab)

3.4.1 Тест — Откат к последнему стабильному состоянию

Никакой работы на тестовых серверах с задачами по „доведению до ума“ не проводится. Для этого у разработчиков есть Dev среды, сюда приходим только тестировать перед сдачей Заказчику, поэтому стерильной условий критичнее истории (именно поэтому флаг hard, и именно reset, а не checkout или что-то иное).
git reset --hard HEAD

Если надо откатить не на 1 коммит, то берём хеш конкретного коммита из GitLab и откатываемся к нему:
git reset --hard #HASH#


3.4.2 Бой — Накаченная задача вносит ошибку (пришла через GIT)

Если правка не положила сервер и 100% пришла с последним коммитом, а не была внесена 2 месяца назад и уже ассимилировалась, создав зависимость с какой-нибудь другой задачей, вот тогда можно сделать встречный коммит, отменяющий правку.
Преимущество в том, что вы сохраняете в GitLab историю этой правки и Разработчик (при наличии доступа) может ещё раз осмотреть коммит, пошевелить мозгами. Да и если коммит уже попал в master ветку GitLab нет никаких заморочек.
Если правка была сделана сразу на бою (кому руки оторвать?), то для этой стратегии придётся сперва сделать коммит, что явно не рационально.

git revert HEAD

Создаёт встречный коммит, отменяющий изменения из последнего.

3.4.3 Бой — Правка сломала бой (полностью)

Если всё очень плохо (сервер лежит, либо вдруг выяснилось что „очень важный функционал“ был сломал давным-давно, то особо деваться некуда:
git reset --hard HEAD

Если надо откатить не на 1 коммит, то берём хеш конкретного коммита из GitLab и откатываемся к нему:
git reset --hard #HASH#

Если в результате такого отката выясняется, что уничтоженный коммит уже попал в master ветку на GitLab, то для восстановления порядка проще зачастую удалить весь репо на GitLab и создать заново. =)

Заключение

Описанные мною сценарии очень просты. В этом их преимущество и недостаток одновременно.

• Преимущество — они позволяют даже начинающему пользователю GIT осуществлять работу с системой контроля версий (проверено на моём начальнике за 2 недели моего отпуска)
• Недостаток — опытный пользователь видит некоторые более гибкие и интересные сценарии, которые сложно формализовать под набор простых правил применения. Именно поэтому я рекомендую после их успешного освоения и внедрения прочитать книгу Pro Git.

Однако даже такой ограниченный инструментальный набор позволяет наблюдать в GitLab вот такие замечательные картины:


Несколько коммитов названы не по моим правилам правилам — это результат быстрой настройки Разработчиком функционала на Test/Prelive сервере при накате задачи. Я в таких случаях писал TIKET_###### Patch_## (номер Тикет и порядковый номер патча), чтобы проще опознавать к какой задаче в трекере относится та или иная правка.


Часть задач реализуется непосредственно мною, а не Разработчиком. В этом случае я называю из Task, а не Tiket и указываю ID связанной задачи в другой учётной системе.

На самом деле такие ветвления и пересечения — это совсем не здорово. Выглядит прикольно, но в действительности каждая отложенная на неделю-месяц для проверки задача создаёт геморрой тому, кто потом всё это будет мерджить.
Не то чтобы у нас что-то ломалось (хотя пару раз возникали конфликты, которые не мог исправить GIT и их приходилось разрешать мне). Но нервничать заставляет.