| СТАТЬЯ |
17.07.03
|
© Даррен Пулсифер (Darren Pulsipher),
компания Cadence Design Systems
© Кристиан Баклей (Christian Buckley),
компания Red Hill Partners
Содержание
Процесс переезда в новый дом является одной из лучших иллюстраций закона Мэрфи. Если какая-нибудь неприятность может случиться, она случается. Можно потратить недели, занимаясь подготовкой, упаковкой и маркировкой своих вещей в каждой комнате дома, выбрасывая ненужный хлам, каталогизируя все предметы, с максимальной осторожностью пакуя все хрупкие вещи. Однако, несмотря на все усилия, эти вещи все равно теряются, бьются и ломаются. Иногда, чтобы лучше справиться с переменами такого рода, нужно заранее подготовить себя к любым мелочам и иметь план решения таких вопросов с самого начала переезда в новый дом.
Невозможно плавно перейти от одной из бесплатных систем управления конфигурацией (Configuration Management, CM) к ClearCase так, чтобы при этом группа разработки вообще не заметила бы разницы. Переход к новой системе управления конфигурацией может сильно изменить мировоззрение некоторых инженеров компании. Он требует от них изменения образа мышления в отношении процесса разработки. По существу, это может повлиять и на их образ жизни.
Как правило, разработчики программного обеспечения очень сильно привязаны к своему способу разработки ПО. Очень часто приходится слышать такие высказывания: "Я занимаюсь разработкой ПО более 25 лет, так зачем мне нужно что-то менять?". Не будем обсуждать здесь проблему "качества ПО" в целом. Планируя изменение CM-системы, нужно помнить о том, что придется иметь дело с людьми, которым не нравятся изменения, а такой переход повлечет за собой существенное изменение их образа работы.
В данной статье планируется осветить следующие аспекты перехода к новой CM-системе:
Перед переходом к новой системе рекомендуется обратить внимание на следующие два совета.
Хорошо, когда все вещи упакованы, дом продан, а машина заправлена и готова ехать, то есть, когда принято окончательное решение о переходе к ClearCase. Вне зависимости от предпринимаемых действий такой переход приведет к изменению парадигмы разработчиков компании. Им придется освоить новые способы работы. Например, изменится стандартный набор команд. Прежде чем переходить к ClearCase, лучше сначала разобраться, как эти системы работают, как они отображают текущие процессы, как их ограничения повлияют на группу разработки компании.
Ниже описаны некоторые наиболее распространенные системы управления версиями и приведена информация, которую следует знать при переходе с этих систем.
Такая ситуация является худшей с точки зрения управления изменениями конфигурации при работе в группе, однако, иногда это очень сильно ускоряет работу отдельных разработчиков. Использование файловой системы только для хранения программного кода не позволяет полностью реализовать все преимущества от использования функциональных возможностей CM-системы. Это не обязательно плохо, так как такое положение существенно облегчает процесс обучения группы разработчиков. В этом случае люди, не обладающие завышенными требованиями, склоны к более быстрому принятию системных обновлений. Однако проблема заключается в том, что необходимо не только обучать инженеров использованию ClearCase, но требуется также научить их основам управления конфигурацией.
Система контроля источников кода обычно поставляется вместе с операционной системой. Для ОС UNIX она является начальной точкой для контроля версий. Стандартный набор команд является очень обширным и для многих инженеров намного проще использовать систему контроля измененных версий RCS, которая обсуждается в следующем пункте. Этот инструмент обычно используется для небольших проектов, так как он не позволяет нескольким разработчика одновременно работать с одним и тем же файлом. Отход от использования данного инструмента заключается в изучении нескольких новых команд и новой концепции представлений, вместо прямой работы с файловой системой. Кроме того, система SCCS не имеет контроля версий каталогов.
Эта система проще, чем SCCS, но она имеет большинство тех же самых ограничений, таких как однопользовательский доступ к одному файлу. Система RCS проще в настройке, и в ней легче найти обходные пути, если они понадобятся. И здесь кроется основная сложность, с которой столкнуться инженеры компании при переходе с системы RCS. Они будут продолжать пытаться получить прямой доступ к хранилищу представлений и каталогу VOB-хранилища для внесения ранее отложенных изменений. Так устроена система RCS. Необходимо быть внимательным в отношении таких конструкторских побуждений.
Данная система является надстройкой над RCS и обладает дополнительными свойствами, дающими возможность маркировки кода и параллельного доступа к одному файлу. Этот инструмент намного ближе к ClearCase, но он не позволяет пользователям работать с динамическими представлениями. Все эти системы не дают разработчику увидеть изменения, вносимые его коллегами, до окончания их работы с файлами. В отличие от них ClearCase позволяет просматривать такие изменения в реальном времени. Опять-таки, в системе CVS отсутствует контроль версий каталогов.
Данная система была разработана компанией Microsoft для использования с Visual Studio и другими своими компиляторами, но она не поддерживает многие из тех возможностей, которые есть в ClearCase. Обычно, переход от Source Safe имеет много общих проблем с переходом от системы CVS, но только в этом случае они возникают у пользователей ОС Windows, а не UNIX.
Теперь, когда есть представление об основных различиях между этими CM-инструментами, можно обсудить процесс работы с ClearCase. Если кратко, то привычный способ использования модели должен изменится. Изменения коснутся всего - и того, как группа разработки будет использовать CM-систему, и того, как новая система будет работать с другими системами. Не нужно стараться подгонять ClearCase под старые способы работы. ClearCase не предназначена для того, чтобы работать как большинство других систем. Рекомендуется прочитать статью "Устранение разрыва между CM-системами: использование инструмента Case Analysis – новой системы управления конфигурацией", чтобы получить представление о том, как приступить к работе, проанализировав текущую систему. В зависимости от ранее использовавшейся CM-системы предстоящие изменения могут быть маленькими или большими. Есть несколько моментов, на которые нужно обратить внимание для того, чтобы понять, что же должно быть сделано, прежде чем перейти от текущей системы к чему-то новому.
Наконец рассмотрим план миграции к новой системе. Для этого необходимо помнить об основных требованиях при подготовке такого перехода. Ниже обсуждаются некоторые из них.
При переходе от любой системы к 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-системы к другой. Такое перемещение происходит в два основных этапа.
Рисунок 1.
Не имеет значения, какая из команд clearexport_* используется. Каждая из них создает промежуточный файл под названием cvt_data. Формат этого файла является общеупотребляемым и команда clearimport его понимает. Она читает файл cvt_data для того, чтобы определить, как создать соответствующие элементы и сегменты.
Прежде чем начать упаковку вещей в доме, нужно предварительно выяснить, какие ненужные вещи необходимо выкинуть, что и где находится, сколько упаковочных ящиков понадобится. Подобным образом, прежде чем экспортировать информацию необходимо решить, какую информацию необходимо хранить в ClearCase.
От ответов на эти вопросы зависит то, как будет проходить экспорт данных. Если нужно сохранить полную историю файлов, то экспорт и импорт данных будут долгими, к тому же не вся информация может оказаться совместимой с ClearCase. Каждая программа экспорта имеет различные ограничения. Поэтому сначала нужно прочитать руководство для программы экспорта, которую планируется использовать. После завершения импорта следует проверить, вся ли информация была перенесена корректно. В зависимости от того, как велика полная история файлов, планируемая для переноса, весь процесс может занять достаточно большое количество времени.
Прежде чем отказаться от хранения полной истории, следует обратить внимание на оборотную сторону хранения только резервной копии самой последней информации из старой CM-системы. Особенно новичкам следует знать о том, что даже в случае хранения резервной копии все равно какое-то время придется поддерживать обе системы. Более того, временная поддержка обеих систем необходима для того, чтобы предоставить инженерам необходимое время для завершения перехода. Поэтому не рекомендуется использовать данный выбор кроме случаев, когда разработка находится в состоянии, в котором поддержка предыдущих версий не нужна, или во время перехода от прототипа к первому выпуску продукта.
Экспорт данных
ClearCase поддерживает программы для экспорта, совместимые с версиями ClearCase 5.x. Следует отметить, что эти программы для экспорта в действительности не импортируют информацию в базу данных VOB, а создают специальный файл данных, который может быть преобразован с помощью команды clearimport.
Во всех этих случаях создается специальный файл данных. Этот файл используется для импорта информации в базу данных VOB системы ClearCase. Этот файл данных можно анализировать и модифицировать для того, чтобы привести в соответствие с запросами текущего переноса.
Прежде чем переносить в ClearCase всю систему целиком, следует сначала проделать это для небольшой иерархии каталогов старой системы и убедиться, что преобразование дает ожидаемые результаты. Нужно помнить о том, что если результаты не оправдали ожидания, то всегда есть возможность внести соответствующие коррективы в файл данных прежде, чем производить импорт. Фактически, лучше всего пытаться это сделать несколько раз до того, как производить перенос всей системы. Кроме того, такие небольшие тесты дают возможность оценить время, необходимое для переноса всей системы.
После завершения тестирования каждого компонента следует убедиться в том, что вся система продолжает работать надлежащим образом. Сквозное тестирование должно проводиться без нарушения текущего процесса разработки. Нужно быть готовым время от времени запускать тестируемую систему в "теневом" режиме – параллельно с действующей системой. Следует привлечь пару разработчиков для работы с системой в режиме "обкатки" и проведения нескольких полноценных тестов. Нет ничего хуже ситуации, когда запущенная новая система не полностью работоспособна. Это не только пагубно сказывается на производительности и сбивает разработчиков с толку, но также может привести к выпуску некачественных продуктов с соответствующими кадровыми решениями со стороны руководства. Поэтому необходимо убедиться в том, что каждый сценарий был отработан, и все функциональные возможности новой системы были тщательно протестированы, включая процедуры разработки, сборки, тестирования и деблокирования. Фактически нужно сделать все возможное для проверки устойчивости системы. Самые суровые тесты сделают ее только надежнее.
В начальный период привыкания персонала к новой системе появится много жалоб. К этому нужно быть готовым и запланировать время на проведение дополнительного обучения, учетом других возможных задержек. Опыт показывает, что до 50% всего времени развертывания новой системы нужно отвести на обслуживание такого рода жалоб. Обучение персонала должно быть основным приоритетом. Не стоит на каждую жалобу пытаться разработать отдельный сценарий.
Неизбежно некоторые разработчики будут испытывать неудобства при работе с новой системой. Это нельзя игнорировать и, в тоже время, следует убедиться, что они понимают, что система теперь действует именно таким образом, и что необходимо к этому приспособиться. Нужно твердо придерживаться своей позиции. Необходимо быть готовым к возникновению всестороннего давления, направленного на изменение, подгонку и модификацию новой системы с тем, чтобы все более-менее стало подобно старой системе. Опять-таки, обучение должно быть первым оружием в борьбе с этими жалобами. После того, как персонал столкнется с такой жесткой позицией в отношении новой системы ситуация начнет понемногу успокаиваться. Разработчики начнут по достоинству оценивать системные улучшения и расширение функциональности.
Переход от одной системы управления исходными программными кодами к другой никогда не был простой задачей. Однако при надлежащем планировании и подготовке группа разработки сможет справиться с изменениями при минимальных потерях.
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
