Вести с передовой: 10 советов, которые помогут вам рационально поддерживать вашу реализацию ClearQuest

IBM Rational ClearQuest предоставляет исключительно эффективную и настраиваемую платформу для управления изменениями программного обеспечения (Software Change Management, SCM) на уровне организации. Но в каких ситуациях необходимо использовать ClearQuest MultiSite, а когда достаточно ClearQuest Web? Когда правила для электронной почты выполняют свою функцию, а в каких случаях они становятся дополнительным источником спама? Трудно ли объединить отдельные базы данных пользователей в одну?

В этой статье перечислены 10 моих лучших советов, которые помогут вам пройти иногда довольно сложный путь к успешным реализациям ClearQuest.

Быть или не быть? MultiSite или не MultiSite?

С выходом версии ClearQuest MultiSite 2002 у организаций с территориально рассредоточенным расположением появился еще один вариант развертывания ClearQuest. Но как определить, тратить ли время и финансовые ресурсы на потенциально сложную реализацию MultiSite или просто использовать Web-интерфейс ClearQuest?

Ответ на этот вопрос зависит от нескольких факторов, в том числе от того, есть ли необходимость у территориально рассредоточенного коллектива использовать локально развернутые клиенты (ClearQuest for Windows и ClearQuest Eclipse Rich Client Platform (RCP)), и от доступной для данной организации скорости передачи данных между различными местоположениями. Как правило, если пользователям из территориально рассредоточенного коллектива необходимо использовать локально развернутый клиент, вопрос решается в пользу MultiSite. Если же требуется просто предоставить территориально рассредоточенным пользователям доступ к ClearQuest для операций, которые не требуют использования локального клиента, то ClearQuest Web - это то, что вам нужно. Однако интеграция между ClearQuest и IBM Rational ClearCase®может затруднить использование новой функции управления тестированием (Test Management) в СlearQuest при помощи ClearQuest Web (см. рисунок 1).

C выходом ClearQuest и ClearCase 7.0.1, казалось бы, не вызывающий сомнений случай использования ClearQuest MultiSite для поддержки интегрированной среды унифицированного управления изменениями (Unified Change Management, UCM), потребовал пересмотра. Тесная интеграция между ClearCase Remote Client (CCRC) и ClearQuest Web дает пользователям возможность работать в среде, основанной на использовании сети Интернет, пользуясь преимуществами платформы Rational Web Platform (ClearCase Web и ClearQuest Web). Однако отсутствие динамических представлений в CCRC может быть серьезным препятствием для большинства организаций, и единственное средство для преодоления этого препятствия - обеспечить наличие в ClearCase и ClearQuest MultiSite набора функций, необходимых рабочей группе.

ClearQuest Test Manager может усложнить развертывание ClearQuest Multisite для тестировщиков, находящихся за пределами организации

Программный пакет ClearQuest Test Management (CQTM), появившийся в версии 7.0, также может стать фактором, свидетельствующим в пользу решения о развертывании MultiSite. Если какая-либо организация имеет удаленные филиалы, использующие CQTM для работы с планами тестирования, контрольными примерами и журналами результатов тестирований, проводимых в IBM Rational ManualTester, IBM Rational FunctionalTester или IBM Rational PerformanceTester, то, по всей вероятности, MultiSite будет единственно разумным решением. Возможность интегрировать инструменты тестирования с Eclipse ClearQuest Perspective для выполнения и протоколирования результатов тестирования будет критически важным требованием для тестировщиков. Возможностей ClearQuest Web вполне достаточно для выполнения функции планирования тестирования и генерирования отчетов; однако для серьезной тестовой среды ClearQuest вряд ли сможет обеспечить всю необходимую функциональность.

У каждого клиента ClearQuest есть своя область применения (и каждый клиент ClearQuest Client занимает свою нишу)

Пользователям ClearQuest 7.0.1 доступны четыре различных способа взаимодействия с приложением: ClearQuest for Windows, ClearQuest Web, подключаемый модуль ClearQuest Eclipse и ClearQuest Eclipse RCP. Необходимо тщательно обдумать, какой клиент следует использовать для каждой конкретной функции. В таблице 1 перечислены "разновидности" ClearQuest и предлагаемые ими функции.

Таблица 1. Определение подходящего клиента ClearQuest для пользователя, работающего в интегрированной среде, требует тщательного обдумывания и планирования

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

Более интегрированную среду придется разделить на "классы", чтобы определить, какие клиенты следует развернуть в данной пользовательской системе. "Классу разработчиков" для интеграции с интегрированной средой разработки Eclipse Integrated Development Environment (IDE) потребуется подключаемый модуль Eclipse. "Классу аналитиков" для поддержки интеграции с клиентом RequisitePro для Windows может потребоваться клиент ClearQuest для Windows, а также возможность обеспечения трассируемости между требованиями и (в большинстве случаев) запросами на изменения, хранящимися в ClearQuest.

Используйте форумы для разработчиков

Не изобретайте велосипед. Один из лучших Web-сайтов для начинающих администраторов ClearQuest - это форум по Rational ClearQuest на портале IBM developerWorks. Форум по ClearQuest представляет собой место, на котором можно найти предоставленные пользователями примеры кодов процедур перехвата и ответы на вопросы, возникающие при настройке параметров вашей схемы.

Кроме обсуждений в темах вы найдете множество примеров реализаций процедур перехвата в списке ClearQuest hooks index. Если вы пытаетесь добавить элемент "Список выбора", функции аудита или использовать ClearQuest для применения ограничений или проверки корректности данных в конкретных полях, примеры из этого списка могут стать отправной точкой для создания собственных реализаций.

В списке ClearQuest hooks index представлены результаты нескольких сотен часов работы разработчиков. Воспользуйтесь опытом других людей для улучшения своей реализации.

Разрешите пользователям создавать форматы отчетов

Взаимосвязь между ClearQuest и Crystal Reports может иногда добавить сложности первоначальному варианту развертывания инструмента, особенно для начинающих. Наиболее простое объяснение заключается в том, что, в текущем виде реализации, все пользователи каждого клиента могут запускать генерацию отчетов. Отчеты представляют собой сочетание формата отчета и определенного запроса. Однако при ближайшем рассмотрении оказывается, что не все так просто. Не каждый клиент допускает авторинг формата отчета.

Только клиент ClearQuest для Windows в связке с поддерживаемой версией Crystal Reports, запущенной в той же системе, может создавать форматы отчетов, необходимые для их генерации. Поскольку Crystal Reports представляет собой отдельное приложение (требующее дополнительных затрат на приобретение лицензии и установки дополнительного продукта), у руководства может возникнуть искушение приобрести несколько лицензий Crystal Reports для администраторов, а затем сделать их специалистами по созданию форматов отчетов Report Formats.

Не поддавайтесь этому искушению. Меньше, чем за 600 долларов можно купить лицензию на Crystal Reports. Более выгодным для организации сценарием может быть модель "подготовь инструктора". В этом случае администратор ClearQuest обучает ключевых специалистов в различных проектных группах, купивших лицензии на Crystal Reports и имеющих в системе Windows-клиент ClearQuest. Таким образом администратор ClearQuest предоставляет отдельным рабочим группам возможность использовать данные, хранящиеся в ClearQuest, для генерации отчетов любым способом, соответствующим их потребностям.

Никогда не ассоциируйте деятельности с группами нижнего уровня.

Возможно, этот совет покажется вам слишком техническим, относящимся к деталям процесса. Однако именно такую ошибку совершают многие начинающие проектировщики ClearQuest.

При выборе деятельности в ClearQuest Designer у начинающих появляется искушение добавить к какой-либо деятельности конкретные группы. Возьмем для примера деятельность Approve. Вы можете создать группу с именем Java_Project_Approvers и добавить в нее трех менеджеров. Затем вы ассоциируете эту группу, Java_Project_Approvers, с разрешением для группы на эту деятельность, регистрируете это в схеме и обновляете базу данных.

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

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

В нашем примере нам следовало бы создать "высокоуровневую" группу с именем Approvers и двумя подгруппами - Java_Project_Approvers и C#_Project_Approvers. Впоследствии, например на следующей неделе, при поступлении запроса от группы C++ Group вам не пришлось бы отключать схему, добавлять новую группу и обновлять схему. Управление разрешениями для группы на эту деятельность теперь становится просто функцией администрирования пользователей и групп.

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

Рисунок 2. Ассоциируя деятельности с высокоуровневыми группами, вы можете добавить к деятельности "специфические для конкретной группы" подгруппы, не изменяя схему

Правила обработки электронной почты предназначены для обеспечения коммуникаций, а не для генерации спама

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

Из-за того, что все правила обработки электронной почты на базе запросов были основаны на первичной записи Defect, при выполнении каждой операции запускались все 90 правил для проверки выполнения условий запроса. Нужно ли говорить, что заказчика интересовало, почему ClearQuest затрачивает на выполнение изменений после нажатия кнопки Apply столько времени.

Организациям, которые выполняют развертывание ClearQuest с нуля, я могу порекомендовать спланировать, какие роли необходимо отслеживать в ClearQuest и рабочих потоках State и Action, и определить, для каких наиболее важных фаз процесса действительно необходима отправка уведомлений. Неопытные пользователи ClearQuest часто поддаются искушению отправлять уведомление подателю дефекта (submitter) по поводу каждого изменения состояния. Поле Submitter заполняется в процессе передачи сообщения, поэтому несложно добавить ссылку на поле Submitter в строку правила электронного сообщения СС (копия).

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

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

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

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

Опасности, связанные с использованием правил обработки электронной почты на основе кода процедуры перехвата

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

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

Перемещение данных между базами данных пользователей (нет, это бывает не только с вами)

В течение нескольких лет я наблюдал инциденты, которые в часто задаваемых вопросах (FAQ) по IBM Rational называются ошибкой новичков. Неопытные администраторы ClearQuest обычно начинают развертывание ClearQuest в соответствии с одним из двух сценариев:

1. "Для начала мы создадим базы данных пользователей для каждого проекта. Если руководство примет решение о том, что имеет смысл объединить их в одну базу данных пользователей организации (по соображениям генерации отчетов или управления данными), мы просто объединим эти базы данных";

Или

2. "Для начала мы создадим общую базу данных пользователей для всех наших проектов. Если проекты потребуют специфической настройки или база данных станет слишком "обширной", мы создадим базы данных пользователей для отдельных проектов и импортируем соответствующие данные из общей базы данных".

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

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

Однако в большинстве случаев чем дальше в лес, тем больше дров. Если у вас есть многострочное поле, например поле Description (см. рисунок 4), то каждая строка возврата каретки в многострочном поле является разделителем записи; это означает, что, в конечном итоге, формат поля в целевой базе данных будет отличаться от исходной базы данных.

Рисунок 4: Отображение полей легко выполнить при помощи мастера импорта. Необходимо планирование и тестирование форматов данных, подлежащих импортированию.

Запомните: поскольку идентификатор записи представляет собой поле, генерируемое системой, невозможно передать идентификатор из одной базы данных в другую. Чтобы обойти этот факт, можно создать новое поле (с таким, например, именем - old_id) и импортировать исходный идентификатор из исходной базы данных пользователей, после чего можно будет создать хроникальную ссылку после импорта в целевую базу данных. Ссылочные поля также должны быть идентичными между базами данных. Если мой входной идентификатор в исходной базе данных был giliod, а в целевой базе данных будет dg1111, то ссылочные поля типа owner и submitter потеряют смысл.

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

В одной из ситуаций заказчик, с которым я работал, хотел, чтобы содержание сообщения электронной почты можно было настраивать в более широких пределах, чем это позволяло готовое программное решение. Он хотел, чтобы по факту получения запроса на изменение пользователю пересылалось сообщение электронной почты, составленное по всем правилам деловой переписки. Например, такое: "Уважаемый <полное имя подателя дефекта>, Ваш запрос № <идентификационный номер> получен. Он был изучен и ему был присвоен приоритет. Если понадобится дополнительная информация, с Вами свяжется представитель группы разработчиков. Благодарим за использование системы управления изменениями Acme ClearQuest Change Management system."

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

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

Рисунок 3: Электронные сообщения на основе процедуры перехвата можно настраивать через мощное API ClearQuest.

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

Не попадите в ловушку: инструменты являются отражением процесса, а не его двигателем

Унифицированный процесс IBM (Rational Unified Process, RUP®), утверждает, что роль"Tool Specialist (Специалист по инструментарию)" отвечает за поддержку инструментов, используемых в проекте, в том числе, за их выбор и приобретение, настройку параметров конфигурации и проверку работы каждого инструмента. В более узком смысле администратор ClearQuest выполняет функции специалиста по инструментарию для системы управления изменениями.

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

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

В некоторых случаях я использовал интересный подход, заключающийся в использовании пакета программ IBM Rational Suite для развертывания инструментов IBM. Выполните сбор дефектов и требования к запросам на улучшение в RequisitePro. Воспользуйтесь базой данных пользователей, построенной на корпоративной схеме, для создания запросов на улучшение и ведения журнала дефектов для данной системы. Таким образом вы станете участником организации процесса, а любые требования, отслеживающиеся в ClearQuest, будут документированы в RequisitePro.

Даже в более неформальной среде будет достаточно электронной таблицы Excel с требованиями заинтересованных лиц со стороны бизнеса. Это предоставляет двойное преимущество: с одной стороны, вы примерно представляете себе, какие действия ожидаются от вас как от администратора ClearQuest, с другой стороны, обеспечивается отслеживаемость выраженных требований при неизбежном возникновении вопросов типа: "Зачем нужно поле Owner при переходе в состояние Approved?" Если ваши требования хорошо документированы, вы сможете дать обоснованный ответ: "Таково было требование, определенное группой согласования SOX, которой данный фрагмент данных необходим для внутренней отчетности."

Ведите разработку схемы ClearQuest изолированно

Через всю статью красной нитью проходит тема, которую я хотел бы озвучить в последнем, десятом, совете: проблемы, возникающие в результате частых изменений схемы. Начинающий администратор ClearQuest может не обратить особого внимания на всплывающее окно с напоминанием, которое появляется при обновлении базы данных пользователей до новой версии схемы (см. рисунок 5). Текст в окне гласит: "This action can not be reversed. Be sure you have backed-up the schema repository and user database. Continue?" (Это действие не подлежит отмене. Обязательно сохраните резервную копию репозитория схемы и базы данных пользователей. Продолжить?)

Рисунок 5. Ответ "yes" в этом окне связан с риском потенциальной аварийной ситуации для вашей реализации ClearQuest, если вы вовремя не подготовите пути к отступлению.

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

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

Это аналогично замене шин на гоночном автомобиле при движении его по треку. При обновлении тестовой базы данных вы получите то же предупреждающее сообщение, показанное на рисунке 5. Вы можете спросить: что, если при обновлении произойдет сбой, в результате которого схема останется в "несогласованном состоянии"? Моя рабочая база данных пользователей будет в порядке, сбой повлияет только на тестовую базу данных, не так ли? Лучше всего ответить так: необязательно. Вследствие сложных взаимосвязей между схемой и базой данных пользователей повреждение схемы - независимо от того, какую из баз данных пользователей вы обновляли (тестовую или рабочую) - может потребовать восстановления схемы, а это, в свою очередь, потребует восстановления всех ассоциированных с ней баз данных (в том числе, производственных данных) для сохранения непротиворечивости.

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

В данной ситуации можно воспользоваться утилитой командной строки "installutil", которая поставляется с ClearQuest, чтобы сделать резервные копии редактируемых схемы и базы (баз) данных пользователей. Точно так же, как разработчики программного обеспечения обычно изолируют свою деятельность по разработке различных физических систем или экземпляров (Разработка, тестирование системы, тестирование на приемлемость для пользователя), этот подход позволяет вам разрабатывать изменения схемы ClearQuest изолированно.

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

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