tестирование dot com
Шрифт:
были основой, т.е. виртуальным стволом (trunk), нашего ПО;
• из этого ствола мы могли создать виртуальную ветвь
(или бранч, от англ. branch) под названием "версия 1.0",
которая включала бы все файлы версии 1.0 в редакциях
(версиях) на момент, когда мы сказали "Стоп " для версии
1.0. Мы говорим "Стоп" после того, как код написан и
готов
• таким образом, у нас появились бы ствол и одна ветвь;
• программисты, пишущие код для версии 2.0, должны были
модифицировать код ствола (нарисунке — пунктиром);
• и когда код версии 2.0 был бы дописан, мы создали бы еще
одну ветвь и назвали ее "версия 2.0 ";
• таким образом, у нас был бы ствол, из которого сначала
рос бы бранч версии 1.0 и затем бранч версии 2.0;
• начиная работать над кодом релиза версии 3.0, мы снова
работаем со стволом (на рисунке — пунктиром);
• и т.д.
Цикл разработки ПО
117
Таким образом, код каждой версии живет в CVS в виде отдель-
ного бранча или ствола.
Кстати, есть множество нюансов, например слияние бранча и
ствола, и ситуации, когда бранч сам становится стволом с вет-
вями и прочее, но я не буду вас этим загружать. Сейчас мне нуж-
<:но, чтобы вы поняли главное.
Теперь вернемся к нашим баранам. Что сделано — то сделано.
Сейчас в CVS y нас есть
• весь код версии 1.0;
• весь код версии 2.0;
• часть кода версии 3.0.
Пусть все это содержимое CVS будет нашим стволом. Я берусь
найти совокупность файлов с редакциями, которые были у нас на мо-
мент релиза 2.0, и обратным числом создать из них бранч 2.0, что-
бы в случае фиаско с версией 3.0 мы могли быстро вернуться к коду
версии 2.0 и вообще начали хорошую традицию создания бранчей».
Выслушав Митю и мысленно поаплодировав ему, разберемся,
что даст реализация Митиного предложения:
Во-первых, мы
всегда сможем вернуться к предыдущей версии,если новая версия окажется некачественной.
Во-вторых, программисты
• смогут работать одновременно над различными версиями,
например ремонтировать баги для 2.0 (бранч 2.0) и писать
код для 3.0 (ствол) и
• результаты их работы над каждой из версий будут в CVS
отделены друг от друга.
В этом случае www.main.testshop.rs будет веб-сайтом с кодом для
3.0 и вообще площадкой для билдов каждого нового релиза, а,
скажем, www.old.testshop.rs будет веб-сайтом с кодом для 2.0 и
вообще площадкой с кодом каждого предыдущего релиза.
В-третьих, мы сможем руководить состоянием бранчей.
У бранча есть три состояния:
1) открытый, т.е. в нем можно сохранять файлы;
2) условно открытый, в нем можно сохранять файлы, НО
при определенном условии, например, программист дол-
118
Тестирование Дот Ком. Часть 1
жен написать номер реального бага в комментарии при со-
хранении файла; 3) закрытый. В этом случае файл может
быть сохранен в соответствии с процедурой о неотложном
ремонте багов (о процедуре через минуту).
Кстати, когда мы говорили о замораживании спеков, используя CVS,
нужно понимать, что бранчи, в которых сохраняются спеки, не имеют
никакой связи с бранчами, в которых сохраняется код. Как правило, это
даже две CVS, установленные на двух разных машинах, но если даже
используется одна и та же CVS на одной и той же машине, то бранчи
для спеков и бранчи для кода — это как два сына одной женщины
(т.е. CVS), один из которых мочит одноклассников в сортирах, а другой
в это время читает Артура Шопенгауэра.
Кстати, часто возникает ситуация, когда программист сохранил код в
бранче для патч-релиза и забыл сохранить исправленный код в стволе,
т.е. в коде, из которого будет сделан бранч для следующего релиза.
Таким образом, может получиться ситуация, когда баг, патч для кото-
рого уже был выпущен на машину для пользователей в предыдущем
релизе, вновь появляется в следующем релизе. Чтобы избежать таких
казусов, тестировщики придерживаются железного правила: на каж-
дый баг, для которого был произведен патч-релиз, должен быть