Читаем tестирование dot com полностью

Основной проблемой, которую мы взрастили, стала мешанина,

начавшаяся в тот момент, когда мы не разделили файлы версии

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 в виде отдель-

ного бранча или ствола.

Кстати, есть множество нюансов, например слияние бранча и

ствола, и ситуации, когда бранч сам становится стволом с вет-

вями и прочее, но я не буду вас этим загружать. Сейчас мне нуж-

<:но, чтобы вы поняли главное.

Теперь вернемся к нашим баранам. Что сделано — то сделано.

Сейчас в 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) условно открытый, в нем можно сохранять файлы, НО

при определенном условии, например, программист дол-