Вести з передової: 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 набору функцій, необхідних робочій групі.


Screen shot shows Rational ClearQuest setup environment

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 (Eclipse RCP)


Плагін ClearQuest Eclipse


Клієнт ClearQuest для Windows


ClearQuest Web


Планування тестування


X


X


X


X


Авторінг тестування (зв’язування тесту з налаштованим контрольним прикладом)


X


X

   

Виконання тестування

 

X

   

Створення звіту про тестування


X


X


X


X


Інтеграція з Eclipse IDE (Rational Application Developer)

 

X

   

Інтеграція з клієнтом ClearCase для Windows


X


X


X

 

Інтеграція з віддаленим клієнтом ClearCase Remote Client

     

X


Інтеграція з IBM Rational RequisitePro ® Windows Client

   

X

 

Інтеграція з RequisiteWeb

     

X


Авторські звіти

     

X


При створенні плану розподілу програмного забезпечення не забудьте розглянути можливості різних клієнтів 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). Цей процес дозволить уникнути істотних наслідків внаслідок частих оновлень схеми і бази даних користувачів (див. наступний рисунок).


Figure shows a screen where a high level approvers group allows sub-groups to be nested within it.


Рисунок 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. “Для початку ми створимо бази даних користувачів для кожного проекту. Якщо керівництво прийме рішення про те, що має сенс об’єднати їх в одну базу даних користувачів організації (з міркувань генерації звітів або управління даними), ми просто об’єднаємо ці бази даних “;

Або



  1. “Для початку ми створимо спільну базу даних користувачів для всіх наших проектів. Якщо проекти зажадають специфічної настройки або база даних стане занадто” великої “, ми створимо бази даних користувачів для окремих проектів і імпортуємо відповідні дані із загальної бази даних “.

Будь-який з цих двох добре обгрунтованих варіантів побудований на одному допущення: простоті переміщення даних між різними базами даних користувачів в ClearQuest. Інформація про те, що в цьому процесі іноді можуть виникати проблеми, дозволить вам краще уявити, що слід очікувати вашої організації.


За допомогою наданих ClearQuest функцій імпорту та експорту ви напевне можете експортувати дані з однієї бази даних користувачів (навіть на вимогу) та імпортувати їх в іншу (навіть у тому випадку, якщо бази даних користувачів побудовані за різними схемами). Якщо вихідне поле і цільове поле, які вам потрібні, доступні і у вихідній, і в цільовій базі даних, інструмент імпорту підтримує їх.


Однак у більшості випадків чим далі в ліс, тим більше дров. Якщо у вас є багаторядкове поле, наприклад поле Description (див. малюнок 4), то кожен рядок повернення каретки в багаторядковому поле є роздільником записи; це означає, що, в кінцевому підсумку, формат поля в цільовій базі даних буде відрізнятися від вихідної бази даних.


Screen shot shows field mapping via the import wizard


Малюнок 4: Відображення полів легко виконати за допомогою майстра імпорту. Необхідно планування і тестування форматів даних, що підлягають імпортування.


Запам’ятайте: оскільки ідентифікатор запису являє собою поле, що генерується системою, неможливо передати ідентифікатор з однієї бази даних в іншу. Щоб обійти цей факт, можна створити нове поле (З таким, наприклад, ім’ям – old_id) і імпортувати вихідний код з вихідної бази даних користувачів, після чого можна буде створити хронікальну посилання після імпорту в цільову базу даних. Посилальні поля також повинні бути ідентичними між базами даних. Якщо мій вхідний ідентифікатор у вихідній базі даних був giliod, а в цільовій базі даних буде dg1111, то посилальні поля типу owner і submitter втратять сенс.


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


В одній із ситуацій замовник, з яким я працював, хотів, щоб зміст повідомлення електронної пошти можна було налаштовувати в більш широких межах, ніж це дозволяло готове програмне рішення. Він хотів, щоб за фактом отримання запиту на зміну користувачеві пересилалися повідомлення електронної пошти, складене за всіма правилами ділового листування. Наприклад, таке: “Шановний <повне ім'я подавця дефекту>, Ваш запит № <ідентифікаційний номер> отриманий. Він був вивчений і йому було присвоєно пріоритет. Якщо знадобиться додаткова інформація, з Вами зв’яжеться представник групи розробників. Дякуємо за використання системи управління змінами Acme ClearQuest Change Management system. “


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


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


Figure shows customization for code-based e-mail.

Малюнок 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? “(Ця дія не підлягає скасуванню. Обов’язково збережіть резервну копію репозиторію схеми і бази даних користувачів. Продовжити?)


Screen shot showing the warning message prior to updating a database to a new schema version.


Рисунок 5. Відповідь “yes” в цьому вікні пов’язаний з ризиком потенційної аварійної ситуації для вашої реалізації ClearQuest, якщо ви вчасно не підготуєте шляху до відступу.


Досвідчені адміністратори ClearQuest пам’ятають часи, коли при оновленні бази даних користувачів відбувався збій в роботі мережі, результатом якого була втрата зв’язку між клієнтом проектувальника і сервером бази даних, або в процесі оновлення відбувалася фатальна помилка Windows з демонстрацією “синього екрану смерті”. Вони також пам’ятають, в яке замішання приходив адміністратор бази даних, коли його просили відновити схему і базу даних користувачів до стану, що передував оновленню.


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


Це аналогічно заміні шин на гоночному автомобілі при русі його по треку. При оновленні тестової бази даних ви отримаєте те ж попередження, показане на малюнку 5. Ви можете запитати: що, якщо при оновленні відбудеться збій, в результаті якого схема залишиться в “неузгодженому стані”? Моя робоча база даних користувачів буде в порядку, збій вплине тільки на тестову базу даних, чи не так? Найкраще відповісти так: необов’язково. Внаслідок складних взаємозв’язків між схемою і базою даних користувачів пошкодження схеми – незалежно від того, яку з баз даних користувачів ви оновлювали (тестову або робочу) – може зажадати відновлення схеми, а це, в свою чергу, вимагатиме відновлення всіх асоційованих з нею баз даних (в тому числі, виробничих даних) для збереження несуперечності.


Крім проблем через зміни робочої схеми, в тому випадку, якщо схема використовує динамічні списки або списки без збереження стану, вам може знадобитися чимало часу на перезавантаження даних на виробничому сервері до новоствореної порожню базу даних тільки для того, щоб зробити її придатною до використання. Якщо схема занадто складна, ви досягнете верхнього порогу, після чого Microsoft Access більше не можна буде використовувати для швидкої генерації тестової бази даних.


У даній ситуації можна скористатися утилітою командного рядка “installutil”, яка поставляється з ClearQuest, щоб зробити резервні копії редагованих схеми і бази (баз) даних користувачів. Точно так само, як розробники програмного забезпечення зазвичай ізолюють свою діяльність з розробки різних фізичних систем або примірників (Розробка, тестування системи, тестування на прийнятність для користувача), цей підхід дозволяє вам розробляти зміни схеми ClearQuest ізольовано.


Після перевірки коректності змін схеми ви можете скористатися командою “cqload” для експорту набору змін схеми та виконання контрольованого імпорту в виробниче середовище. Таким чином ви зможете спланувати оновлення зі звичайною для будь-якої іншої виробничої системи у вашій робочої середовищі ступенем контролю. Ви можете зв’язатися з адміністратором бази даних, запросити створення резервної копії “на вимогу”, повідомити всіх користувачів про просте бази даних і випустити бюлетень з описом змін, які можуть вплинути на співтовариство кінцевих користувачів.


Якщо для оновлення схеми ClearQuest (і пов’язаних баз даних користувачів) ви скористаєтеся цим методом, то при виконанні цієї операції, отримавши дезориентирующее попередження, ви будете знати, що мережа в безпеці, тому що у вас є резервна копія, яку ви створили 15 хвилин тому, і навіть в тому випадку, якщо непередбачені обставини порушать оновлення, ви зможете просто попросити адміністратора баз даних відновити схему і базу даних користувачів з резервної копії.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*