Некоторое время назад мы рассматривали вопрос о размещении тестового окружения.
Изначально, тестовое окружение у нас располагалось рядом с рабочим – т.е. удаленно у нашего
ISP.
Схематично это выглядело так:
Как видно на схеме, разработка происходила локально, затем происходило периодическое обновление тестовой системы, где выполнялись все тесты. И, в конце концов, происходило обновление рабочих систем.
Это дает максимальную приближенность тестовой системы к рабочим условиям: быстрый доступ к сторонним поставщикам данных, схожая конфигурация железа и пр.
Однако, такой подход не был лишен и недостатков: он замедлял процесс тестирования и весь процесс разработки.
Происходило это по нескольким причинам:
1. Тратилось очень длительное на время на сравнение
схем всех
баз данных – около двух часов.
Происходило это потому, что схемы были довольно большие и баз было несколько. Поэтому, приходилось скачивать локально большое количество
DDL-скриптов.
2. Очень медленно работало
регрессионное тестирование веб-интерфейса. Из-за низкой скорости доступа через интернет на выполнение всех автоматизированных скриптов, которые выполнят все
варианты тестирования требовалось около 2-х суток. Конечно, варианты тестирования можно запускать параллельно, но это не решает проблему кардинально.
Было решено перенести тестовое окружение локально, т.е. получить в итоге следующую схему работы:
Это должно в разы ускорить выполнение скриптов
регрессионного тестирования веб-интерфейса и ускорить частый процесс обновления тестовой системы и, в конечном итоге, ускорить процесс разработки как таковой.
При таком подходе, правда, тоже есть подводные камни: в частности не так явно видны проблемы передачи больших объемов данных через интернет –
“тяжелый” HTML или большие данные веб-форм и т.п.