Міграція на новий Siebel

Організація робот із сумісної розробки

перенесення доопрацьовань між середовищами

Пропозиція Ареон для СК УНІКА

Версія 3 від 29.03.2023

Основні обмеження

Деталізація пропозиції Ареон:

• стосуються нового середовища ІР23.1
• три середовища — ДЕВ, ТСТ, ПРД
• переноси — за єдиними регламентом
• переноси через SMA
• RR на всіх середовищах
• розробка тільки на ДЕВ
• DR тільки на ДЕВ

Ланшафт сервисів з переносу

• два відокремлених сервіса SMA
  • для розробників – переноси ДЕВ ➔ ТСТ
  • релізи на прод ‐ ТСТ ➔ ПРД
• сервіси розташовані на серверах ДЕВ, ТСТ
• передача змін через файли TCT ➔ ПРД

Особливість організації

• одночасний, паралельний та незалежний процес розробки
• версійність RR на ПРД
• ТСТ — дві ролі
  • як ТСТ — користувацьке тестування
  • як преПРОД — тестування виправлень
• спрощення переносів
  • основний обсяг перенесення через SMA
  • для невеликих змін — відсутність пакету
  • інструкція з додаткових налаштування
• перейменування RR на ТСТ
• застосування концепції Релізів

Концепція Релізів

Реліз — це конфігурація всієї системи, образ майбутнього ПРД

• формування репозиторію для ПРД
• завантаження в MAIN готових розробок — об'єдання задач, які змінюють MAIN
• перенос всього репозиторію, схеми даних та seed-даних

Звідси:

• оновлення ПРД за розкладом
• планування включення змін в наступний образ ПРД (реліз)
• єдиний поток задач на deliver в MAIN
• на ТСТ перевіряється майбутній ПРД
  • виправлення, bugfix, дрібні доопрацювання
  • регрес перевірка іншого функціоналу
• застосовується функціонал Jira — Release

Загальний процес

• Розробка — на ДЕВ, це також bugfix
• Тестування — на ТСТ
• Формування релізу — на ДЕВ, delivery WS в МАIN
• Перевірка — на ТСТ, регрес тестування
• Впровадження — інкрементальний перенос MAIN на ПРД

Ієрархія WS

• створюється тільки на ДЕВ
• IWS для окремих розробок (заявок)

  int_[dd]_[dd_name]

• WS двох типів
  • окремого етапу розробки

    dev_[dd]_[dd_name]_[num_etap]

  • для індивідуальної розробки, bugfix

    dev_[user]_[yymmdd]

• Ієрархія WS формується Архітектором від складності розробки

MAIN
+-- dev_[user]_[yymmdd]          <--- bugfix
+-- int_[dd]_[dd_name]           <--- Окрема розробка, тому IWS
    +-- dev_dev_[user]_[yymmdd]  <--- Індивідуальні доопрацювання
    +-- dev_dd129_voc_etap1      <--- Етап розробки
        +-- dev_vadim_b_230323
        +-- dev_vadim_b_230325
            . . .
        +-- dev_[user]_[yymmdd]
    +-- dev_dd129_voc_etap2
             . . .
        +-- dev_[user]_[yymmdd]
+-- dev_sveta_s_230327

Багфікс

• WS створюється Розробником від MAIN

  dev_[user]_[yymmdd]

• перевірка на ДЕВ в робочому WS
• по завершенню — delivery в MAIN
• задача Jira привязується до поточного release
• на ТСТ встановлено MAIN
• переноси інкрементальні — ДЕВ → ТСТ, ТСТ → ПРД
• можливі переноси — ДЕВ → ПРД
• переноси виконує Системний інженер ІТ (Роман)

Розробка

В одну поставку

• окремий IWS на всю розробку, створює Архітектор

  int_[dd]_[dd_name]

• робочі WS від IWS, створює Розробник

  dev_[user]_[yymmdd]

• внутрішнє тестування — на ДЕВ в IWS
• delivery IWS в MAIN по завершенню тестування бізнесом

Розробка

В одну поставку

• на початку встановлення на ТСТ
  • створення snapshot БД
  • MAIN перейменувати
  • повний перенос IWS
• подальші переноси IWS на ТСТ — інкрементальні
• переключення між RR на ТСТ через перейменування
• по завершеню тестування — відновлення БД на ТСТ із snapshot
• окремий issue в Jira на delivery IWS в MAIN (фактично, задача на перенос), прив'язується до Release
• подальші дії так само як з bugfix

Розробка

Декілька поставок

• один IWS на всю розробку, створює Архітектор
• ієрархія WS від IWS
  • на поставку (пакет), створює Архітектор, безпопесередньо на початку етапу

    dev_[dd]_[dd_name]_[etap_num]

  • робочі — від WS поставки
• робочі WS від IWS, створює Розробник

Розробка

Декілька поставок

Особливість створення WS на поставку

• безпосередньо перед початком робот
• виконується ручний "deliver" всіх WS dev_[dd]_[dd_name]_[etap_num] (поставки) в MAIN — ручний перенос *.sif
• можливо застосування команди Export Workspace to Arhive
• потім створення від MAIN

Розробка

Декілька поставок. Варіант 2

Відміність від попереднього варіанту

• deliver всіх WS dev_[dd]_[dd_name]_[etap_num] (поставки) в MAIN
• сторити наново зміненну ієрархію WS із поставками

Формування

• Планування релізу
  • ІТ визначення дати готовності релізу
  • Адміністратор створення в Jira об'єкту release
• Формування релізу
  • КП включення задач в release
  • КП, Проектний офіс контроль задач, включених в реліз
  • Розробник delivery включених задач в MAIN

Впровадження

• починається в запланований день
• всі задачі в статусі "Done"
• Адміністратор виконує
  • SAM завдання на перенос RR
  • інструкції із задач "New version" (не репозитарка)
  • перевод всіх задач релізу в Going to Testing
• перевірка релізу
  • Тестувальники — перевірка по задачам Going to Testing
  • Виправлення — на ДЕВ, в WS, delivery, запуск SAM завдання
    • Розробник — на ДЕВ в робочих WS від MAIN
    • Тестувальник — функціональна перевірка на ДЕВ
    • Адміністратор — виконати перенос на ТСТ (інкрементальний)
    • Тестувальник, Бізнес — функціональна перевірка на ТСТ
• перенос на ПРД
  • планування часу
  • запуск SAM завдання
  • інкрементальний перенос RR
  • виконання інструкцій до релізу
  • швидка перевірка
  • закриття задач Jira

Наступні кроки

• перехід на одну Jira - робота із задачами Релізів
  • робота із об'єктами Реліз
  • ведення задач із deliver в MAIN
• планування Релізів
  • визначання часу (хто? коли?)
  • адміністрування та керування релізами
• задачі в Jira на задачі із deliver в MAIN
  • типи задач
  • статуси задач та правила їх зміни

Дякую за увагу

Питання?