Настраиваем площадку Битрикс правильно: простые советы для сохранения душевного здоровья тимлида

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Настройка любой площадки для CMS — это рутинный процесс, который должен быть доведен до автоматизма в каждой уважающей себя компании. А потому частенько воспринимается, как восход солнца — это происходит само собой. На самом деле, нельзя так относиться и надеяться на разработчиков, особенно если часть команды работает на субподряде. Они могут потратить кучу времени и денег проекта на переносах, багах и конфликтах кода.

Задача тимлида — создать команде среду для разработки и правильные условия для написания кода. Меня зовут Артем Первушин, я технический директор в компании Extyl. Чтобы помочь с этим я решил опубликовать напоминалку, основанную на внутренних регламентах нашей компании.

Итак, наша задача: развернуть рабочие стенды девелоперов (dev), тестовое окружение(stage), боевой сервер (prod), наладить процесс разработки и тестирования, доставки артефактов по цепочке и деплоя стабильной версии. Для этого необходимо формализовать, привести к единому алгоритму процесс настройки площадки для разработчика, чтобы не возникало ситуации, когда каждый сам решает, что и где «подкрутить». Золотое правило управленца — если процесс повторяется больше одного раза, на этот процесс должна быть инструкция или регламент.

Расскажу на примере архитектуры, которую используем мы: main — наша основная площадка для тестов и показов. В дополнение используем несколько площадок для каждого из разработчиков — d1, d2 и так далее. Настройкой среды для Битрикс-приложения в нашей компании занимается сисадмин. Здесь нет универсального способа настройки, поэтому подробности опущу.

Шаг 1. Разворачиваем ядро Битрикс (базовое или своей версии):

  • Проверить кодировки. Устанавливайте сайт СТРОГО в кодировке UTF-8. При проверке сайта (Инструменты – проверка системы) шестым пунктом проверки должно выводиться «Параметры настройки UTF».

  • Проверить ключи. Ни в коем случае не оставляйте сайт на демо-ключе. Нужно запрашивать некоммерческий ключ для разработки у менеджера проекта, а в случае непредставления — останавливать проект. Об этом должен позаботиться тимлид, иначе про ключ все забудут и в один прекрасный момент сайт перестанет работать.

  • Не забыть отключить допфункции. Запрет отправки почтовых сообщений на тестовой площадке. Если на странице задана константа ONLY_EMAIL и email из настроек почтового шаблона с ее значением не совпадает, то письмо не отсылать. Если мы хотим запретить посылать сообщения на всем сайте, то необходимо в файле bdconn.php установить константу define("ONLY_EMAIL", "admin@site.ru");

  • Поставить галку на версиях разработчиков. После установки продукта в админке нужно отметить, что сайт используется для разработки, а не для коммерческих целей.

  • Обновить до актуального состояния. Сразу после развертывания необходимо зайти в настройки Битрикс и установить все обновления системы, поскольку в аутсорс-продакшнах часто пользуются готовыми сборками (образами).

После разворачивания сайта необходимо пройти проверку системы и проверку тестирования конфигурации /bitrix/admin/site_checker.php?lang=ru. Ошибок и предупреждений не должно быть. По умолчанию агенты на тестовых площадках Extyl должны выполняться на хитах, а на бою переведены на cron (тимлид проекта решает, когда на тесте надо перевести агента на cron).

Шаг 2. Следим за тем, чтобы площадки для разработки не оказались в индексе поисковиков

Программисты, как правило, вообще не задумываются о поисковиках и последствиях индексации площадки для разработки. Нужно напоминать, что стенды разработки — это те же сайты в сети, а значит их видят роботы, Нам не нужно, чтобы служебная информация оказалась доступна в поиске. Сразу после установки не забываем изменить настройки на боевом сервере.

И в robots.txt прописать правило:

User-Agent: *
Disallow: /

#Все другие правила удалить

– запрещена индексация сайта;

Во время переноса сайта на боевой сервер, файл должен быть изменен (оставить запрет на индексацию только на системные папки, страницы, файлы, такие как bitrix, upload, auth и т.п.).

Шаг 3. Устанавливаем модуль миграции сущностей БД

Когда у нас уже есть ядро и мы начали делать сайт, появляются данные, с которыми нужно работать и не терять их. Возникает необходимость переноса на бой и обратно изменений сущностей БД (инфоблоки, формы и т.д.).

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

Для переноса изменения из БД теста на бой или наоборот надо сразу установить модуль миграции для разработчиков https://marketplace.1c-bitrix.ru/solutions/sprint.migration/

Не ленитесь и облегчите себе жизнь установкой мигратора. Он поможет восстановить работоспособность сайта, даже если кто-то удалил базу без возможности восстановления.

Шаг 4. Настраиваем Git

В современных реалиях без GIt не может существовать не один проект, даже очень маленький. Писать код без системы версионирования сегодня невозможно — командная работа на то и командная.

Сразу после развертывания Битрикс — надо установить Git на проект и правильно его настроить:

/bitrix/
/bitrix
/upload/
/upload
/local/vendor/
/local/vendor
/web.config
/.htaccess
/robots.txt
/*.xml
*.swp
*.log

Не все должно попадать в репозиторий, настраиваем gitignore.

.gitignore может быть изменен и дополнен в зависимости от потребностей проекта.

robots.txt, как и sitemap*.xml, .htaccess должен быть в .gitignore на бою и всех тестовых площадках.

Пара слов о гигиене процессов:

  • На предпроде должна быть включена ветка stage, а на бою master. В ветках stage и master мы не работаем.

  • Все ненужные страницы и разделы необходимо удалить перед первым коммитом.

  • В Git не должны попадать отладочные скрипты, логи, медиафайлы, регистрируемые в БД и др.

  • Очень важно первично правильно настроить Git и сделать площадку main (stage) чистой — без незакоммиченных файлов. Далее эта площадка будет копироваться на тестовые хосты, и если не выполнить эти предписания, то будут проблемы с тем, что невнимательные разработчики станут коммитить конфигурационные файлы, отладку, ядро и другие вещи, которые не должны попадать в Git. Вообще, когда в истории коммитов видно, как удаляют отладку или то, чего не должно там быть — это говорит о низкой квалификации разработчика. Подробнее о работе с Git я расскажу в следующей статье.

Шаг 5. Настраиваем CI/CD на проекте

CI/CD технология непрерывной интеграции и развертывания сегодня практически стандарт для отрасли, хотя единого алгоритма действий тут нет, и пожалуй быть не может — слишком много разных переменных для каждого проекта, каждый раз настраивать приходится по своему. Но общий алгоритм един — пишется код, покрывается тестами, отправляется в систему контроля версий (не обязательно Git), при поступлении нового коммита — тригерится запуск развертывания тестового окружения и самих тестов. Если все успешно — тригерится деплой артефактов на прод.

Разумеется, это только каркас, и этапов может быть гораздо больше, как и проверок (и автоматических и ручных) на возможность перехода к следующему этапу. Но в рамки этой статьи разбор CI/CD не укладывается, это отдельная и большая тема.

Большие проекты подразумевают настройку CI/CD, но процесс сильно зависит от потребностей проекта.


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

Давайте продолжим обсуждение в комментариях?

Источник: https://habr.com/ru/post/571744/

Интересные статьи

Интересные статьи

Статья о том, как упорядочить найм1. Информируем о вакансии2. Ведём до найма3. Автоматизируем скучное4. Оформляем и выводим на работу5. Отчитываемся по итогам6. Помогаем с адаптацией...
С каждым годом требования к in-app подпискам в мобильных приложениях в App Store и Google Play меняются, становится все сложнее учесть их с первого раза и не получить серию реджекто...
В предыдущей статье о проблемах внедрения ERP на промышленных предприятиях в качестве кейса к одному из пунктов был приведён «Программистский беспредел». У нас есть заказчик, сотрудники которо...
VUE.JS - это javascript фрэймворк, с версии 18.5 его добавили в ядро битрикса, поэтому можно его использовать из коробки.
Многие приобрели «голубую таблетку» на попробовать. Но из-за сложности программирования данная вещь оказалась где то на полке, до лучших времен. Будем считать, что «лучшие времена» — насту...