tестирование dot com
Шрифт:
• изменить и протестировать билд- и релиз-скрипты,
• запустить релиз-скрипты и проверить, насколько правильно они
сработали.
• Если в первом релизе у нас были десятки файлов, то с течением времени
их будут сотни!!!
В таком бедламе проходит двое безвылазных суток, и наконец
баги придушены, билд протестирован на тест-машине и срочно
организуется патч-релиз 2.01 на машину для пользователей.
После
нии, вносится предложение о создании бранчей (branch — ветвь)
Цикл разработки ПО
115
в CVS. Предложение принимается единогласно (тем более что от-
вечать в случае провала будет инициатор), и Митя рассказывает,
в чем суть этого подхода.
РАССКАЗ МИТИ
'В общем так, други. Допустим, у нас есть ребенок и его фото-
графии нужно раз в месяц по е-мейлу посылать теще. Если при-
сылается фотография ребенка в недовольном состоянии, то теща
приезжает и устраивает дома такой шухер, как будто она по-
пользовалась нашей версией 2.0. Соответственно нужно сохранить
фотографию ребенка, когда он улыбается, и если новая фото-
графия теще не нравится, то нужно просто послать ей старую
фотографию с улыбкой и сказать, что ошибка вышла".
Харитоныч:
— Да вот я помню... (далее следует 30-минутный рассказ о его
тещах с постепенным переходом к обобщениям и, наконец, дек-
ларативному изложению отношения ко всему прекрасному полу).
Да-а-а, вот так-то. Что ты там говорил про версию 2.0?
ПРОДОЛЖЕНИЕ МИТИНОГО РАССКАЗА
«Да, вот. Как я и говорил о хорошем и улыбающемся билде. Вот
мини-история нашего проекта со стороны релиз-инженера:
В один прекрасный день мы начали работать над кодом ПО, и по
мере написания этого кода стали добавлять в CVS новые файлы
,и изменять файлы, уже существующие в ней. В определенный
момент мы сказали "Стоп" и назвали совокупность файлов в
CVS "версия 1.0". Затем мы продолжили работу над кодом и
снова стали добавлять в CVS новые файлы и изменять файлы,
существующие в ней. В определенный момент мы снова сказали
"Стоп" и назвали совокупность файлов в CVS "версия 2.0".
Основной проблемой, которую мы взрастили, стала мешанина,
начавшаяся в тот момент, когда мы не разделили файлы версии
1.0 и версии 2.0.
Идем дальше.
Представьте
ствол, и
ветви, растущие из ствола.
116
Тестирование Дот Ком. Часть 1
Вот как мы должны были поступить с самого начала:
• файлы, созданные вплоть до момента релиза версии 1.0,
были основой, т.е. виртуальным стволом (trunk), нашего ПО;
• из этого ствола мы могли создать виртуальную ветвь
(или бранч, от англ. branch) под названием "версия 1.0",
которая включала бы все файлы версии 1.0 в редакциях
(версиях) на момент, когда мы сказали "Стоп " для версии
1.0. Мы говорим "Стоп" после того, как код написан и
готов для интеграции и тестирования;
• таким образом, у нас появились бы ствол и одна ветвь;
• программисты, пишущие код для версии 2.0, должны были
модифицировать код ствола (нарисунке — пунктиром);
• и когда код версии 2.0 был бы дописан, мы создали бы еще
одну ветвь и назвали ее "версия 2.0 ";
• таким образом, у нас был бы ствол, из которого сначала
рос бы бранч версии 1.0 и затем бранч версии 2.0;
• начиная работать над кодом релиза версии 3.0, мы снова
работаем со стволом (на рисунке — пунктиром);
• и т.д.
Цикл разработки ПО
117
Таким образом, код каждой версии живет в CVS в виде отдель-