Основной проблемой, которую мы взрастили, стала мешанина,
начавшаяся в тот момент, когда мы не разделили файлы версии
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) условно открытый, в нем можно сохранять файлы, НО
при определенном условии, например, программист дол-
