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