Дата последнего изменения: 23.09.2021
Введенный в эксплуатацию проект необходимо развивать вместе с клиентом. Чтобы правильно выстроить процесс работы, необходимо знать как должны передаваться изменения на «боевой» проект, как при этом избежать ошибок и как же правильнее обновлять проект.
Полезно иметь несколько тестовых серверов, причем тестовая конфигурация должна быть точной копией «боевого» сервера: версии Bitrix Framework, PHP, СУБД и другого ПО проекта должны совпадать. При наличии некоторых различий могут возникать ошибки в работе проекта, которые будет находить клиент.
Рассмотрим схему процесса эксплуатации и развития проекта:
На схеме кратко показано, что в первую очередь на тестовом сервере необходимо выполнить обновление (при наличии) системного ПО и системы Bitrix Framewok. Затем из системы контроля версий (репозитария) мы передаем обновление кода и базы данных тестового проекта на сервер тестирования. После чего выполняем модульное, функциональное и нагрузочное тестирование.
На «боевом» сервере обязательно выполняем резервное копирование. Затем ставим те же обновления системного ПО и Bitrix Framewok, что и на тестовый сервер. После чего из системы контроля версии передаем обновления кода и базы данных «боевого» проекта.
Для хорошей работы вашего проекта необходимо использовать дистрибутивы только стабильных версий. Кроме того, их следует выбирать с увеличенным сроком поддержки, поскольку при смене ПО могут возникнуть ошибки и сбои в работе проекта.
Не следует использовать «левые» репозитории пакетов и кастомные сборки, которые могут сломать систему при обновлении. Программное обеспечение не следует собирать и из исходников, если не собираетесь его поддерживать.
Доступ на сервер не должно быть ни у кого, кроме администратора. Программное обеспечение не должны устанавливать несколько человек. Должен быть наведен порядок с правами доступа к серверам.
Перед тем, как установить обновления программного обеспечения на «боевой» сервер, необходимо установить и проверить их на тестовом сервере. При этом полезно изучить логи пакетов обновлений, поскольку всегда нужно быть готовым к тому, что при обновлениях может сломаться проект. Для подстраховки можно сделать LVM shapshot. Конфигурации серверов необходимо держать под контролем версий (например, использовать пакет etckeeper).
Прежде чем приступать к обновлению системы Bitrix Framework, обязательно сделайте «горячий» бекап «боевого» проекта. Для максимально быстрого восстановления проекта можно сделать бекап через LVM shapshot файлов и базы данных. Сперва обновляем Bitrix Framework на тестовом проекте, проводим тестирование (см. схему выше) и только после удачного его завершения обновляем Bitrix Framework на «боевом» проекте при минимальной посещаемости.
В крайне маловероятном, но возможном случае нарушения работоспособности проекта после обновления по технологии SiteUpdate, постарайтесь как можно быстрее обратиться в техническую поддержку компании "1С-Битрикс" и предоставить доступ для восстановления, либо откатитесь к предыдущему состоянию, восстановив данные из бекапа.
При обновлении кода проекта всегда следите за тем, чтобы в стабильную ветку попадал только тщательно протестированный на тестовом сервере код. Нужно предусмотреть, чтобы в скриптах создания объектов Bitrix Framework не использовались внешние ключи, атрибут AUTO_INCREMENT
. Кроме того, нужно следить за синхронностью систем, иначе при отсутствии зависимостей объекты Bitrix Framework будут некорректно создаваться на «боевом» сервере. Все изменения файлов должны быть залогированы, а также для скриптов создания объектов Bitrix Framework должны вестись подробные логи работы и ошибок. Все скрипты обновлений должны быть привязаны к релизам и храниться в системе контроля версий.
Для выполнения модульного тестирования на крупном проекте, работающего на системе Bitrix Framework, желательно иметь Unit-тесты для своих модулей, классов, библиотек. Компоненты проще тестировать руками либо частично использовать программу Selenium. Но при этом не нужно целиком и полностью покрывать веб-проект модульными тестами, необходимо найти баланс между разными видами тестирования.
При проведении функционального тестирования нарисуйте графики зависимостей: укажите что от чего зависит и где искать. Это необходимо, чтобы не приходилось после любого изменения перетестировать весь проект полностью. Для сложного функционала пишите и актуализируйте подробные варианты тестирования («test cases») либо проводите тестирование вместе с аналитиком. Простые задачи по функциональному тестированию можно выполнить с помощью Selenium.
Для проведения нагрузочного тестирования на тестовом сервере следует держать большой набор данных, приближенный к «боевому». Нагрузочное тестирование необходимо выполнять для измененных компонентов, страниц, сервисов. Тестовые планы сохраняйте в системе контроля версий. Автоматически проверяйте настройки кеширования компонентов, автокеширования и другие параметры, сильно влияющие на производительность. Используйте на проекте программы Munin, Cacti и анализируйте их графики, чтобы иметь возможность корректировать конфигурации серверов.