Тестирование сайтов с помощью сборок: что это такое и как работает

Тестировать на боевом сайте запрещено.

Если Вы создаёте сайты, то наверняка понимаете почему это так. И скорее всего Вы знакомы с проблемой, о которой пойдет речь.

Для чего нужны сборки



Представьте, что Вы сделали сайт и уже запустили его в боевую эксплуатацию: почистили всю грязь из таблиц, всё проверили и привели в порядок, чтобы клиенты увидели готовую работающую систему, а не непонятное “under construction” заполненное чёрти чем.

И вдруг откуда ни возьмись в Вашей конфетке начинают появляться какие-то Васи Пупкины, Биллы Гейтсы, Владимиры Путины или вообще непонятные слова в виде набора букв. А ещё хуже, когда эти непонятные персоны начинают выставлять счета на миллионы рублей, которые автоматически передаются в 1С-ку Вашей компании.

Выясняется, что кто-то из сотрудников проявил инициативу и решил “проверить” как работает сайт. Конечно. Ведь кроме него никто не может сделать это так же качественно. Только он на это способен.

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

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

А как же тогда тестировать, возникает вопрос?

А вот для этого можно использовать т.н. сборки.

Сборки — это полные копии боевого сайта, на которых можно и нужно производить тестирование.

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

Что представляет собой система сборок в целом


Как лучше организовать систему сборок и с помощью чего её делать?

Хорошо зарекомендовала себя конфигурация, когда делается сразу несколько сборок.

Т.е. создаются N отдельных сайтов-копий боевой системы: build1.site.ru, build2.site.ru,..., buildN.site.ru

При этом одна из сборок (например, 1-я) является специальной — на неё нельзя накатывать никаких изменений. Остальные же предназначены для того, чтобы отлаживать на них новые задачи, закодированные программистами.

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

А где и как Вы будет проверять сообщения об ошибках, присылаемых пользователями?

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

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

На этой тестовой копии не должно быть ничего накачено сверху. Должна быть именно полная и точная копия боевой системы. Только тогда тест будет точным.

1-ю сборку можно сделать автоматической, т.е. чтобы она сама ежедневно обновлялась (заливался свежий дамп БД и все скрипты). Ну и добавить возможность обновления прямо сейчас, чтобы можно было увидеть актуальные данные на текущий момент.

Остальные сборки не обязательно строить на ежедневной основе. Вполне достаточно строить их “on demand” — т.е. только тогда, когда это нужно программисту или тестировщику (правда для этого нужно хорошенько поработать над скоростью развёртывания сборки).

И не забудьте ввести такое понятие как блокировка.

Когда сборки используют сразу несколько программистов, неизбежны ситуации когда один программист накатит свои изменения на сборку, используемую другим программистом.

Чтобы этого не было, сделайте возможность блокировки сборки. Если сборка заблокирована, то её нельзя пересобрать вплоть до момента снятия блокировки.

Как сборки устроены технически


Реализация сборок достаточно проста с технической точки зрения. Они легко делаются с помощью обычных shell-скриптов + создаётся одна единственная веб-страница, запускающая shell-скрипт развёртывания сборки в режиме nohup.

Процедура развёртывания тоже не представляет сложности. Всё делается в три шага:
  • накатывается свежий дамп БД
  • на скрипты накатывается нужная ветка из svn
  • запускается скрипт, делающий изменения в БД (берется из той же ветки svn)


Конечно, не обязательно всё делать на shell. Можно использовать любой инструмент. Если есть готовый инструмент для сборок, то почему бы им не воспользоваться?

Кстати, заметьте, что при создании сборки не производится ни одного ручного изменения! Это сделано специально, чтобы избежать возникновения ошибок, вызванных человеческим фактором. Очень помогает, между прочим.

Стоит отметить, что программистам не следует использовать сборки для кодирования. Просто это очень сильно замедлит разработку.

Правильнее использовать сборки как инструмент финального тестирования задачи.

У каждого программиста на компьютере лучше всего иметь собственную копию сайта и кодировать именно в ней. И только потом, когда задача будет готова, проверять её на сборке.

Какие ещё преимущества они дают


Т.к. сборки собираются (развёртываются) автоматически, ручное влияние на них минимизировано.

Сделать руками ничего нельзя вообще. Не поменять скрипт, ни поправить БД, вообще ничего.

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

Итоги


Использование сборок для тестирования сайтов показало свою эффективность на практике, поэтому если Вы разрабатываете сайт, не забудьте создать к нему и систему сборок.
Метки:
  • –1
  • 2,7k
  • 8
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 8
  • +3
    накатывается свежий дамп БД

    А если БД 500 Гб весит?
    А ещё — лежит на удалённом сервере, бэкапится на удалённом сервере, копируется на сервер сборок и там долго и уныло разворачивается.
    • –1
      что за сайт такой, что у него БД под террабайт весит? или вы в БД всю статику сложили?
      • +1
        может быть просто огромное количество пользователей и их операций
    • 0
      у нас так и весит. можно рассмотреть варианты с частичным дампом или зеркалированием в реальном времени. мы делали так
      • 0
        В том же посте написано:
        > Для таких задач очень хорошо подходит точная копия боевого сайта

        Частичный дамп — не есть «точная копия».
        • +1
          да. но как вариант решения подходит вполне в тех случаях когда важны не все части сайта. Например, когда важна только база пользователей и их транзакции.

          мы у себя все картинки и файлы отрубали + статистику использования сайта.

          а вообще, зеркалирование БД в реальном времени вполне решает проблему
          • 0
            зеркалирование БД в реальном времени


            Зеркалирование или репликация? Если зеркалирование, то какая у вас СУБД?
            • +2
              я всегда думал, что одно — просто способ другого. А вообще этим админ занимался, не я. Мне не надо в подробности настройки влезать.
              MySQL

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.