Переноси доопрацьювань в ІР23
Схема переносів із IWA. верс 3
Міграція на новий 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 двох типів
- Ієрархія 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
- робочі 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
- типи задач
- статуси задач та правила їх зміни