Иногда сайт работает нормально, и его начинают бояться трогать.
Нужно поменять текст, добавить фотографию или обновить информацию, но возникает мысль: а вдруг после этого что-то сломается?
У разных систем свои риски. В визуальном конструкторе при редактировании страницы можно случайно затронуть расположение элементов. В WordPress после обновления ядра, темы или плагинов иногда возникают проблемы совместимости.
Поэтому я организую работу так, чтобы часть проблем обнаруживалась ещё до публикации, а при неудачном изменении можно было вернуться к предыдущей версии.
Как сайт можно случайно сломать
Даже небольшое изменение иногда затрагивает больше, чем кажется сначала.
Например, разработчик меняет компонент карточки товара, который используется на десятках страниц. Если не учесть один из вариантов отображения, проблема появится сразу в нескольких местах.
Или меняется логика оформления заказа. Корзина продолжает выглядеть правильно, но при определённом сочетании товаров стоимость рассчитывается с ошибкой.
Есть и обычный человеческий фактор: можно забыть проверить страницу на телефоне, допустить опечатку в коде или не учесть редкий сценарий.
Поэтому важно не только аккуратно вносить изменения, но и иметь способ проверить результат до публикации.
Контент отдельно от оформления
В моих проектах тексты, фотографии, товары, цены и статьи меняются через CMS.
Менеджер работает с содержимым сайта, но не редактирует структуру и оформление страниц. Чтобы изменить цену товара или добавить фотографию, ему не нужно двигать блоки, настраивать отступы и разбираться в устройстве страницы.
Это уменьшает вероятность случайно нарушить оформление при обычной работе с контентом.
Но полностью исключить визуальные проблемы нельзя. Например, слишком длинный заголовок или изображение с необычными пропорциями могут выглядеть неудачно на мобильном экране.
Когда владелец обновляет контент через CMS, изменения сохраняются в репозитории и запускается автоматическая сборка сайта. Новая версия публикуется после успешной сборки и предусмотренных проверок.
Подробнее о различиях между таким подходом и визуальным конструктором я написал в статье «Конструктор или разработка кодом: что выбрать для бизнеса».
Сначала проверка, потом публикация
Изменения в коде не становятся рабочей версией сайта сразу после редактирования.
Перед публикацией сайт автоматически проходит проверку данных и сборку. Если обнаруживается ошибка, новая версия не публикуется.
Такие проверки помогают обнаружить ошибки в коде, некорректные данные и проблемы, из-за которых сайт невозможно правильно собрать.
Для критичных функций я дополнительно пишу тесты. Например, в интернет-магазине они проверяют расчёт суммы, создание заказа, защиту от повторных запросов и обработку уведомлений от банка. Эти тесты помогают проверять работу серверной части после доработок.
Автоматизация не заменяет проверку человеком. Она не определит, насколько удачно написан текст, и не гарантирует, что страница будет хорошо выглядеть на каждом устройстве. Также она не защищает от всех проблем со сторонними сервисами.
Но ошибки, для которых предусмотрены проверки, можно обнаруживать раньше, чем их заметят посетители.
История изменений и возврат к рабочей версии
В моих проектах сохраняется история изменений исходного кода и данных, которые хранятся в репозитории.
По смыслу это похоже на историю изменений в Google Docs. Можно посмотреть, что менялось раньше, сравнить версии и понять, после какой доработки появилась проблема.
Только здесь история относится не к одному документу, а к файлам проекта.
Если после обновления обнаружилась ошибка, можно найти предыдущую рабочую версию, вернуть нужные изменения и снова опубликовать сайт.
Не приходится восстанавливать файлы по памяти или пытаться вспомнить, что именно менялось несколько дней назад.
Но такой откат помогает прежде всего с ошибками в самом проекте. Если перестал отвечать внешний сервис, изменилась информация в отдельной базе данных или возникла проблема у платёжной системы, возврат старого кода не обязательно поможет.
Что это даёт владельцу сайта
Разделение контента и оформления, автоматические проверки и история изменений позволяют безопаснее обновлять сайт. Если после доработки обнаружится проблема, проще найти её причину и вернуться к предыдущей рабочей версии.
Полностью исключить ошибки невозможно. Хороший сайт - это не тот, который ни разу не ломался, а тот, который легко обновлять и быстро чинить.