tестирование dot com
Шрифт:
программистов находится на той же тест-машине.
Дело в том, что на одном веб-сервере могут находиться сразу не-
сколько веб-сайтов. В нашем случае:
• www.mitya.testshop.rs — это адрес Митиного плэйграунда,
• www.dima.testshop.rs — это адрес Диминого плэйграунда, а
• www.main.testshop.rs — это веб-сайт, на который делается
каждый из билдов.
112
Тестирование Дот Ком. Часть 1
Следовательно,
www.main.testshop.rs для своего тестирования.
Соответствующие
• директория с ЯГЖ-файлами и картинками,
• директория с приложением (Python и C++ файлы) и
• база данных
слинкованы с каждым из сайтов, так что у нас есть три конфигу-
рации, независимые друг от друга.
Кстати, важный нюанс о плэйграундах, билдах и CVS. Основное правило
для checkin: сначала сделай быстрый юнит-тест и убедись, что твои
файлы компилируются по крайней мере на твоем плэйграунде,
и уже после этого делай их "публичными" через checkin в CVS.
Рациональное объяснение: билды строятся из кода, хранимого в
CVS. Если же код не компилируется, то билд будет сломан (build
is broken) и соответственно никакого тестирования не будет.
Мы касались этого правила, говоря об идее постоянной интегра-
ции кода.
Идем дальше.
Код написан, тестирование и ремонт багов закончены. Настало
время первого релиза www.testshop.rs!!!
Первый релиз происходит так:
1. Подготовка машины у хостинг-провайдера (production
server, просто production или live machine — машина для пользо-
вателей).
Когда говорили об аренде сервера хостинг-провайдера, то име-
лось в виду, что мы арендовали совершенно конкретный компью-
тер, который находится где-то у провайдера и имеет уникальное
(в общемировом масштабе) сетевое ID, которое называется IP
Address ("ай-пи адрес"). Используя этот IP Address, мы подсое-
диняемся к этой машине и настраиваем
а) провайдерский Линукс (например, создаем директории,
редактируем разрешения и т.д.);
б) провайдерский Apache (например, вносим изменения в
файл конфигурации и т.д.);
в) провайдерскую MySQL (например, определяем максималь
ное количество соединений и т.д.).
Цикл разработки ПО
113
2. Подготовка релиз-скрипта (release script) — программы, кото-
рая автоматизирует процесс релиза на машину для пользователей.
3. Исполнение релиз-скрипта:
а) релиз-скрипт запускает билд-скрипт, чтобы на тест-маши
не создался новый билд;
б) релиз-скрипт берет файлы этого нового билда и по прото
колу FTP ("эф-ти-пи" — File Transfer Protocol) пересылает
их в машину для пользователей;
в) релиз-скрипт:
• копирует из CVS на машину для пользователя скрипты
для базы данных (DB-scripts) и
• запускает эти скрипты.
Скрипты для базы данных создают или модифицируют схему
базы данных. Так как у нас первый релиз, то схема базы данных
только создается, а именно создаются три таблицы:
• user_info (для данных о пользователях);
• user_transaction (для данных о транзакциях пользователя);
• book_vault (для данных о наименованиях книг и их наличии).
Кстати, нужно различать
• схему базы данных (database, или просто DB, schema) и
• сами данные.
Схема базы данных — это совокупность виртуальных контейнеров
(над БД работают программисты и администраторы БД).
Данные — это начинка этих виртуальных контейнеров, которую своими
действиями на www.testshop.rs, например регистрацией, создают/из-
меняют пользователи (user_info и user_transaction) или другие лица
(например, Харитоныч, который через специальную программу, напи-
санную Митей, может добавить новые названия книг и их количество
в book_vault).
Небольшое отступление
По мере развития проекта машина для пользователей превратится в
десятки связанных между собой веб-серверов, серверов с приложением
и серверов с базами данных, образующих production pool, т.е. сово-
купность компьютеров, обслуживающих наших пользователей. Но это
будет потом. А пока...
Welcome to www.testshop.rs!!! Наш первый релиз состоялся!!!