Система предварительного тестирования правок на сайте

Сегодня мы хотели бы поделиться с тобой своим опытом по внесению мелких и средних изменений на проекты наших клиентов.
Клиенты при этом — это небольшие сайты, с посещаемостью до 10к/день.

Сразу хотелось бы оговорить о каких правках пойдет речь:

• Изменение внешнего вида элементов сайта, будь то формы, логотип, верстка отдельной статьи, и тп.
• Изменение логики фронтенда: изменение логики форм, переделываем отправку через AJAX, добавляем валидацию элементов, добавляем какой-нибудь плагин, формы обратного звонка и многое другое.
• любые другие изменения на сайте не требующие изменения базы данных(обратно несовместимого).

Собственно о самих сайтах

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

• Известная CMS или хотябы FrameWork
• VCS, для контроля изменений
• Тестовый домен (поддомен)
• Документированный функционал

Но на самом деле, как правило, присутствуют только первый пункт.

Как бы выглядел процесс внесения изменений в идеальном случае?

1. Мы бы внесли изменения с тестовую ветвь VCS
2. Выложили бы их на тестовом домене
3. Дождались проверки заказчиком
4. После подтвержения перенесли изменения в основную ветвь VCS
5. Выложили изменения на сайт

Как выглядит процесс обычно?

1. Изменения вносятся на сайт сразу же (или как мы говорим наживую)
2. Все правки делаются напрямую на том же сайте

Конечно, в случае небольшой посещаемости или, возможно, на стадии запуска проекта такое вполне себе возможно. Но что делать если у сайта хорошая посещаемость, и клиенты не должны видеть “сырой” функционал?

Придуманный нами способ не является каким-то “новым” или “особенным”, наверняка он один из многих, но мы хотели бы рассказать о нем.

Что мы используем?

В принципе, вся логика умещается в одну очень простую блок схему:

Т.е. Мы добавляем на сайт скрипты, при помощи которых делим пользователей на разные типы, рядовой пользователь или тестовый, и в зависимости от того кто перед нами отдаем им разный контент.

Что может быть в качестве детерминанты? Да все что угодно, IP адрес, определенный логин, или кука. Мы перепробовали все варианты, и самым удобным для нас и клиента оказалось использование куки, т.к. с её помощью мы можем внедрять тестовый функционал и в frontend, и в backend.

Из каких частей состоит система?

• altera-test-system.html
• Условный блок в каждом шаблоне сайта

Файл лежащий в корне сайта, может иметь любое имя, все что он делает — устанавливает куку, или снимает её. Главное чтобы он был один, и не засорял проект, поэтому мы в него включили одновременно все (html, css, js).

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

Что в итоге мы получили?

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

Как выглядит процесс внесения изменений на сайт с системой?

1. Добавляем систему на сайт (единоразовое действие)
2. Вносим изменения в условный блок
3. Дождались проверки заказчиком
4. Убиваем условный блок, оставив новый функционал

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

• Любой пользователь знающий имя скрипта или куки может посмотреть тестовый функционал.
• Становится слишком трудозатратным внесение глобальных изменений в проект.

Пример того как выглядит система и сайт до включения

И соответственно после

Для удобства использования системы мы добавили следующий функционал:

• При клике по иконке в шаблоне сайта — переход на систему.
• При двойном клике на body системы — переход на сайт.
• Также реализована мультидоменная работа системы.

Очень бы хотелось узнать а что используют другие web студии при решении небольших и средних задач на клиентских проектах?

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