Ящики, упаковочная лента и подъем тяжелых грузов: переход к ClearCase

Даррен Пулсифер (Darren Pulsipher), Кристиан Баклей (Christian Buckley)

Содержание

Планирование перехода
Обучение персонала
Изменение сценариев
Перенос данных
Подъем тяжелых грузов

Процесс переезда в новый дом является одной из лучших иллюстраций закона Мэрфи. Если какая-нибудь неприятность может случиться, она случается. Можно потратить недели, занимаясь подготовкой, упаковкой и маркировкой своих вещей в каждой комнате дома, выбрасывая ненужный хлам, каталогизируя все предметы, с максимальной осторожностью пакуя все хрупкие вещи. Однако, несмотря на все усилия, эти вещи все равно теряются, бьются и ломаются. Иногда, чтобы лучше справиться с переменами такого рода, нужно заранее подготовить себя к любым мелочам и иметь план решения таких вопросов с самого начала переезда в новый дом.

Невозможно плавно перейти от одной из бесплатных систем управления конфигурацией (Configuration Management, CM) к ClearCase так, чтобы при этом группа разработки вообще не заметила бы разницы. Переход к новой системе управления конфигурацией может сильно изменить мировоззрение некоторых инженеров компании. Он требует от них изменения образа мышления в отношении процесса разработки. По существу, это может повлиять и на их образ жизни.

Как правило, разработчики программного обеспечения очень сильно привязаны к своему способу разработки ПО. Очень часто приходится слышать такие высказывания: "Я занимаюсь разработкой ПО более 25 лет, так зачем мне нужно что-то менять?". Не будем обсуждать здесь проблему "качества ПО" в целом. Планируя изменение CM-системы, нужно помнить о том, что придется иметь дело с людьми, которым не нравятся изменения, а такой переход повлечет за собой существенное изменение их образа работы.

В данной статье планируется осветить следующие аспекты перехода к новой CM-системе:

понимание существующей системы и ее использования, включая стратегии ветвления, сборку и тестирование;
выполнение перехода в автономном режиме для проверки переносимости небольших частей системы;
выполнение перехода в автономном режиме для проверки переносимости всей системы в целом;
проведение бета-тестирования с некоторыми из разработчиков-испытателей компании для проверки того, что испытываемая система работает в нормальном режима (включая все конструкции, ветвления и т.д.);
реализация самого перехода, с сохранением старой системы для обеспечения совместимости.

Перед переходом к новой системе рекомендуется обратить внимание на следующие два совета.

Не поддавайтесь искушению написать сценарии, заставляющие ClearCase выглядеть так же, как предыдущая CM-система. Обычно это приводит к необходимости сопровождать большое количество запутанных сценариев, а также к замедлению работы системы или усложнению ее обслуживания. Старайтесь избегать такого подхода.
После перехода к ClearCase используйте эту систему по назначению. Это звучит достаточно просто, однако многие люди с самого начала пытаются модифицировать систему. Не следует рядить жирафа так, чтобы он был похож на слона. Жираф остается жирафом вне зависимости от цвета, в который его выкрасили. Прежде чем приступить к использованию, необходимо разобраться, как система работает, а затем вместе с инженерами компании провести необходимые изменения процессов для настройки данного инструмента.

Планирование перехода

Понимание текущей CM-системы

Хорошо, когда все вещи упакованы, дом продан, а машина заправлена и готова ехать, то есть, когда принято окончательное решение о переходе к ClearCase. Вне зависимости от предпринимаемых действий такой переход приведет к изменению парадигмы разработчиков компании. Им придется освоить новые способы работы. Например, изменится стандартный набор команд. Прежде чем переходить к ClearCase, лучше сначала разобраться, как эти системы работают, как они отображают текущие процессы, как их ограничения повлияют на группу разработки компании.

Ниже описаны некоторые наиболее распространенные системы управления версиями и приведена информация, которую следует знать при переходе с этих систем.

Файловая система: не имеет контроля версий

Такая ситуация является худшей с точки зрения управления изменениями конфигурации при работе в группе, однако, иногда это очень сильно ускоряет работу отдельных разработчиков. Использование файловой системы только для хранения программного кода не позволяет полностью реализовать все преимущества от использования функциональных возможностей CM-системы. Это не обязательно плохо, так как такое положение существенно облегчает процесс обучения группы разработчиков. В этом случае люди, не обладающие завышенными требованиями, склоны к более быстрому принятию системных обновлений. Однако проблема заключается в том, что необходимо не только обучать инженеров использованию ClearCase, но требуется также научить их основам управления конфигурацией.

Система контроля источников кода SCCS (Source Code Control System)

Система контроля источников кода обычно поставляется вместе с операционной системой. Для ОС UNIX она является начальной точкой для контроля версий. Стандартный набор команд является очень обширным и для многих инженеров намного проще использовать систему контроля измененных версий RCS, которая обсуждается в следующем пункте. Этот инструмент обычно используется для небольших проектов, так как он не позволяет нескольким разработчика одновременно работать с одним и тем же файлом. Отход от использования данного инструмента заключается в изучении нескольких новых команд и новой концепции представлений, вместо прямой работы с файловой системой. Кроме того, система SCCS не имеет контроля версий каталогов.

Система контроля измененных версий RCS (Revision Control System)

Эта система проще, чем SCCS, но она имеет большинство тех же самых ограничений, таких как однопользовательский доступ к одному файлу. Система RCS проще в настройке, и в ней легче найти обходные пути, если они понадобятся. И здесь кроется основная сложность, с которой столкнуться инженеры компании при переходе с системы RCS. Они будут продолжать пытаться получить прямой доступ к хранилищу представлений и каталогу VOB-хранилища для внесения ранее отложенных изменений. Так устроена система RCS. Необходимо быть внимательным в отношении таких конструкторских побуждений.

Параллельная система контроля версий CVS (Concurrent Versioning System)

Данная система является надстройкой над RCS и обладает дополнительными свойствами, дающими возможность маркировки кода и параллельного доступа к одному файлу. Этот инструмент намного ближе к ClearCase, но он не позволяет пользователям работать с динамическими представлениями. Все эти системы не дают разработчику увидеть изменения, вносимые его коллегами, до окончания их работы с файлами. В отличие от них ClearCase позволяет просматривать такие изменения в реальном времени. Опять-таки, в системе CVS отсутствует контроль версий каталогов.

Система Source Safe

Данная система была разработана компанией Microsoft для использования с Visual Studio и другими своими компиляторами, но она не поддерживает многие из тех возможностей, которые есть в ClearCase. Обычно, переход от Source Safe имеет много общих проблем с переходом от системы CVS, но только в этом случае они возникают у пользователей ОС Windows, а не UNIX.

Теперь, когда есть представление об основных различиях между этими CM-инструментами, можно обсудить процесс работы с ClearCase. Если кратко, то привычный способ использования модели должен изменится. Изменения коснутся всего - и того, как группа разработки будет использовать CM-систему, и того, как новая система будет работать с другими системами. Не нужно стараться подгонять ClearCase под старые способы работы. ClearCase не предназначена для того, чтобы работать как большинство других систем. Рекомендуется прочитать статью "Устранение разрыва между CM-системами: использование инструмента Case Analysis - новой системы управления конфигурацией", чтобы получить представление о том, как приступить к работе, проанализировав текущую систему. В зависимости от ранее использовавшейся CM-системы предстоящие изменения могут быть маленькими или большими. Есть несколько моментов, на которые нужно обратить внимание для того, чтобы понять, что же должно быть сделано, прежде чем перейти от текущей системы к чему-то новому.

Во-первых, нужно хорошо представлять себе то, как используется текущая CM-система. Следует с помощью языка UML смоделировать текущие процессы, чтобы разобраться с действующими субъектами, прецедентами и взаимоотношениями внутри этой системы.
Во-вторых, следует познакомиться с различными моделями Use Model системы ClearCase. В ClearCase предлагается несколько моделей на выбор. Система унифицированного управления изменениями UCM поставляется отдельно от ClearCase. Обе эти системы интегрированы с рядом других инструментов компании Rational Software, которые возможно придется использовать в будущем.
Далее следует выбрать нужную модель Use Model. Рекомендуется снова воспользоваться языком UML. Было бы ошибочно полагать, что можно использовать UCM сразу, как только будет получен продукт, без внесения изменений в сам процесс работы. Следует смоделировать процесс работы, чтобы выяснить, какая из моделей Use Model больше всего подходит для организации. Основной целью должна быть оптимизация производительности группы разработки компании, на этом нужно сосредоточить основное внимание.

Наконец рассмотрим план миграции к новой системе. Для этого необходимо помнить об основных требованиях при подготовке такого перехода. Ниже обсуждаются некоторые из них.

Аппаратные требования

Пространство на жестком диске

При переходе от любой системы к ClearCase нужно помнить о том, что для его выполнения нужно иметь достаточно большое количество свободного пространства на жестком диске. Как правило, свободного места должно быть, по крайней мере, в 2,5 раза больше, чем занимает текущая CM-система. Этого должно хватить и для текущей системы, и для файлов преобразования, и для новых данных системы ClearCase.

Центральный процессор

Следует помнить о том, что ClearCase отличается от большинства других систем. Система ClearCase является приложением типа клиент-сервер, поэтому нужно учитывать то, что она требует более мощного процессора, чем большинство подобных систем. Руководство по работе с ClearCase содержит полную информацию об аппаратных требованиях к VOB- и View-серверам и настольным компьютерам группы разработки. Необходимо тщательно разобраться с различиями между требованиями для этих серверов и надлежащим образом распределить имеющиеся ресурсы.

Пропускная способность каналов ввода-вывода

Системные задержки критически влияют на производительность ClearCase. Можно иметь очень быстрые компьютеры в качестве VOB- и View-серверов, а производительность ClearCase по-прежнему будет оставаться очень низкой. Тщательный анализ подобной ситуации обычно обнаруживает низкую пропускную способность локальной сети или каналов ввода-вывода жесткого диска. Ее просто может не хватать для обеспечения необходимой производительности. VOB-серверы должны иметь самую быструю сетевую магистраль, какую только может себе позволить компания. View-сервера должны иметь почти такую же быструю сеть. В настройках сетевого коммутатора необходимо запретить автоматическую регулировку пропускной способности сети. В противном случае скорость соединений по умолчанию установится на минимально возможную величину. Для обеспечения максимальной скорости работы коммутатора и сетевого интерфейса серверов необходимо найти и нейтрализовать все "узкие места" в корпоративной сети.

Сценарии системы создания и тестирования кода

Необходимо хорошо себе представлять, насколько действующая система создания и тестирования программного кода привязана к текущей CM-системе. Помимо всего прочего, нужно понимать, что эта система - нечто большее, чем просто инструмент для компиляции и тестирования кода. Она также выполняет и некоторые другие функции:

сбор кода от других разработчиков с помощью механизма слияния;
разметка кода для сборки;
упаковка бинарных файлов и библиотек после их сборки;
оповещение о ходе сборки;
запуск комплектов тестирования;
определение показателей качества;
и многое другое.

Нельзя забывать о том, что при переходе к новой CM-систем меняются как сам инструмент, так и основа протекающих процессов, с которыми изо дня в день работают разработчики компании.

Интеграция с системой отслеживания дефектов и модернизации

Интегрирована ли текущая CM-система с системой CRM (управление взаимодействием с заказчиками)? Имеется ли в ней система отслеживания дефектов и модернизации? Если старая CM-система интегрирована с системами такого типа, то точки интеграции останутся теми же или изменятся? В большинстве случаев способ использования этих систем будет другим после перехода к новой CM-системе. Если модели Use Model изменятся, то, скорее всего, изменится и имеющаяся интеграция. Поэтому, при планировании перехода к новой система необходимо выделить отдельное время на обновление интеграции со вспомогательными системами.

Время простоя

После того, как будут готовы новая модель Use Model и план реализации проекта понадобиться еще пара месяцев, чтобы завершить замену. К сожалению, руководство компании не может позволить себе приостановить процесс разработки на эти два месяца для перехода к новой CM-системе. Поэтому ответственному за переход персоналу придется сверхурочно работать в выходные дни.

Вот почему планирование так важно. Нужно заранее пытаться сделать как можно больше работы в "теневом" режиме наряду с текущими процессами разработки. Это даст возможность опробовать новую систему до перехода на нее всех разработчиков. Нужно помнить о том, что на окончательную настройку и запуск новой системы обычно уходит 3-4 дня. Таким образом, заблаговременное планирование и тестирование являются важными составляющими успешного перехода к новой системе.

Обучение персонала

Не следует делать никаких предварительных допущений об уровне подготовки группы разработки - каждый должен пройти определенную тренировку на новой системе, вне зависимости от своего опыта. Даже те, кто обладает 7 летним опытом работы с ClearCase, могли иметь дело с более старой версией, так что, для работы на новой системе им тоже понадобиться некоторая тренировка (хотя и не такая, как для тех, кто вообще не знаком с данной системой).

Во время создания новой модели Use Model следует привлечь к работе ответственных за изменения ключевых представителей отдела разработки компании. Они должны стать группой поддержки для остальных сотрудников при переходе на новую систему. Это значительно упростит процесс перехода для всех разработчиков.

Вполне вероятно, что переход на новую CM-систему окажет очень сильное влияние на разработчиков компании. Люди не любят изменения, но если правильно информировать их, они будут стремиться к лучшему стилю работы. Лучше всего за неделю до перехода от старой системы к новой провести обучение, ознакомив всех разработчиков с концепциями ClearCase, различиями между старой и новой системами, а также новой моделью Use Model. Однако не следует проводить такое обучение слишком рано, так как люди будут заняты другой работой, а в отсутствие возможности быстро применить новые знания они быстро утратят их, и тогда большинство преимуществ от тренировки будет упущено. Для обеспечения конструктивной обратной связи с персоналом и удовлетворения потребностей в дополнительном обучении оптимальным будет также проведение подобного обучения вскоре после окончательной настройки новой CM-системы. Эти дополнительные занятия следует запланировать заранее, чтобы избежать излишнего потока возникающих вопросов от каждого разработчика отдельно, что будет только мешать нормальной работе группы разработки.

Изменение сценариев

Хотя выше уже упоминалась опасность, связанная с текущими сценариями для разработок при переходе к только что развернутой среде ClearCase, об этом стоит упомянуть еще раз. Не стоит пытаться использовать ClearCase в точности таким же образом, как систему RCS. Такой подход заведомо неудачен. Это было бы подобно тому, как использовать столовый нож к качестве отвертки - нож неизбежно должен согнуться. Подобное использование ClearCase приведет к значительному ухудшению работы новой системы управления исходными программными кодами.

Сценарии очень удобны для автоматизации стандартных операций, но не следует полностью прятать за ними всю систему ClearCase. Лучше соответствующим образом обучить разработчиков компании, чем создавать у них представление, что ClearCase - это большой, черный ящик, о котором все знает только один его "маг-администратор". Многие склонны полагать, что создание и поддержка сценариев делает работу более безопасной. Однако в случае ClearCase такой стиль работы не эффективен, так как он требует слишком много внимания и усилий.

Следует избегать таких усложнений и следить за тем, что избранная модель Use Model использовалась должным образом.

Перенос данных

Во все версии ClearCase, начиная с 4.1 (http://www.interface.ru/rational/cc/rclearc4.htm), компания Rational добавила несколько миграционных сценариев, чтобы помочь выполнить перенос данных от одной CM-системы к другой. Такое перемещение происходит в два основных этапа.

Экспорт из текущей CM-системы (clearexport_*, см. подробности в Справочном руководстве для ClearCase).
Импорт в ClearCase (clearimport, см. подробности в Справочном руководстве для ClearCase).

Рисунок 1.

Не имеет значения, какая из команд clearexport_* используется. Каждая из них создает промежуточный файл под названием cvt_data. Формат этого файла является общеупотребляемым и команда clearimport его понимает. Она читает файл cvt_data для того, чтобы определить, как создать соответствующие элементы и сегменты.

Что нужно экспортировать

Прежде чем начать упаковку вещей в доме, нужно предварительно выяснить, какие ненужные вещи необходимо выкинуть, что и где находится, сколько упаковочных ящиков понадобится. Подобным образом, прежде чем экспортировать информацию необходимо решить, какую информацию необходимо хранить в ClearCase.

Нужно ли экспортировать полную историю файлов в ClearCase?
Нужно ли хранить резервную копию самой последней информации в ClearCase?

От ответов на эти вопросы зависит то, как будет проходить экспорт данных. Если нужно сохранить полную историю файлов, то экспорт и импорт данных будут долгими, к тому же не вся информация может оказаться совместимой с ClearCase. Каждая программа экспорта имеет различные ограничения. Поэтому сначала нужно прочитать руководство для программы экспорта, которую планируется использовать. После завершения импорта следует проверить, вся ли информация была перенесена корректно. В зависимости от того, как велика полная история файлов, планируемая для переноса, весь процесс может занять достаточно большое количество времени.

Прежде чем отказаться от хранения полной истории, следует обратить внимание на оборотную сторону хранения только резервной копии самой последней информации из старой CM-системы. Особенно новичкам следует знать о том, что даже в случае хранения резервной копии все равно какое-то время придется поддерживать обе системы. Более того, временная поддержка обеих систем необходима для того, чтобы предоставить инженерам необходимое время для завершения перехода. Поэтому не рекомендуется использовать данный выбор кроме случаев, когда разработка находится в состоянии, в котором поддержка предыдущих версий не нужна, или во время перехода от прототипа к первому выпуску продукта.

Экспорт данных

ClearCase поддерживает программы для экспорта, совместимые с версиями ClearCase 5.x. Следует отметить, что эти программы для экспорта в действительности не импортируют информацию в базу данных VOB, а создают специальный файл данных, который может быть преобразован с помощью команды clearimport.

clearexport_ccase - экспортирует информацию из одной базы данных VOB системы ClearCase в другую. Эту команду удобно использовать для разделения баз данных VOB. См. соответствующую страницу руководства для clearexport_ccase.
clearexport_cvs - экспортирует CVS-информацию в базу данных VOB системы ClearCase. Эта команда обрабатывает большинство символов CVS и конвертирует их в сегменты и ярлыки. См. соответствующую страницу руководства для clearexport_cvs.
clearexport_pvcs - экспортирует PVCS-информацию в базу данных VOB системы ClearCase. Эта команда преобразует PVCS-символы в ярлыки и сегменты, но с некоторыми ограничениями. См. соответствующую страницу руководства для clearexport_pvcs.
clearexport_rcs - экспортирует RCS-информацию в базу данных VOB системы ClearCase. Эта команда обрабатывает символы RCS и конвертирует их в сегменты и ярлыки. См. соответствующую страницу руководства для clearexport_rcs.
clearexport_sccs - экспортирует SCCS-информацию в базу данных VOB системы ClearCase. Эта команда обрабатывает SCCS-символы и преобразует их в сегменты. См. соответствующую страницу руководства для clearexport_sccs.
Clearexport_ssafe - экспортирует информацию из системы Source Safe в базу данных VOB. См. соответствующую страницу руководства для clearexport_ssafe.

Во всех этих случаях создается специальный файл данных. Этот файл используется для импорта информации в базу данных VOB системы ClearCase. Этот файл данных можно анализировать и модифицировать для того, чтобы привести в соответствие с запросами текущего переноса.

Тестирование перед переносом

Прежде чем переносить в ClearCase всю систему целиком, следует сначала проделать это для небольшой иерархии каталогов старой системы и убедиться, что преобразование дает ожидаемые результаты. Нужно помнить о том, что если результаты не оправдали ожидания, то всегда есть возможность внести соответствующие коррективы в файл данных прежде, чем производить импорт. Фактически, лучше всего пытаться это сделать несколько раз до того, как производить перенос всей системы. Кроме того, такие небольшие тесты дают возможность оценить время, необходимое для переноса всей системы.

Пробный запуск

После завершения тестирования каждого компонента следует убедиться в том, что вся система продолжает работать надлежащим образом. Сквозное тестирование должно проводиться без нарушения текущего процесса разработки. Нужно быть готовым время от времени запускать тестируемую систему в "теневом" режиме - параллельно с действующей системой. Следует привлечь пару разработчиков для работы с системой в режиме "обкатки" и проведения нескольких полноценных тестов. Нет ничего хуже ситуации, когда запущенная новая система не полностью работоспособна. Это не только пагубно сказывается на производительности и сбивает разработчиков с толку, но также может привести к выпуску некачественных продуктов с соответствующими кадровыми решениями со стороны руководства. Поэтому необходимо убедиться в том, что каждый сценарий был отработан, и все функциональные возможности новой системы были тщательно протестированы, включая процедуры разработки, сборки, тестирования и деблокирования. Фактически нужно сделать все возможное для проверки устойчивости системы. Самые суровые тесты сделают ее только надежнее.

Подъем тяжелых грузов

В начальный период привыкания персонала к новой системе появится много жалоб. К этому нужно быть готовым и запланировать время на проведение дополнительного обучения, учетом других возможных задержек. Опыт показывает, что до 50% всего времени развертывания новой системы нужно отвести на обслуживание такого рода жалоб. Обучение персонала должно быть основным приоритетом. Не стоит на каждую жалобу пытаться разработать отдельный сценарий.

Неизбежно некоторые разработчики будут испытывать неудобства при работе с новой системой. Это нельзя игнорировать и, в тоже время, следует убедиться, что они понимают, что система теперь действует именно таким образом, и что необходимо к этому приспособиться. Нужно твердо придерживаться своей позиции. Необходимо быть готовым к возникновению всестороннего давления, направленного на изменение, подгонку и модификацию новой системы с тем, чтобы все более-менее стало подобно старой системе. Опять-таки, обучение должно быть первым оружием в борьбе с этими жалобами. После того, как персонал столкнется с такой жесткой позицией в отношении новой системы ситуация начнет понемногу успокаиваться. Разработчики начнут по достоинству оценивать системные улучшения и расширение функциональности.

Переход от одной системы управления исходными программными кодами к другой никогда не был простой задачей. Однако при надлежащем планировании и подготовке группа разработки сможет справиться с изменениями при минимальных потерях.

Ссылки по теме