Page History

Частина 1 "Початок роботи АТ "Прозорро.Продажі" - Видача ключей ключів до тестового середовища

1. Подання запиту на первинну взаємодію – Майданчик подає запит на первинну взаємодію через форму на порталі АТ "Прозорро.Продажі"
2. Укладення договору на первинну взаємодію – Менеджер по роботі з клієнтами підписує договір про первинну взаємодію з майданчиком.
3. Створення каналу Slack – Менеджер по роботі з клієнтами створює канал в Slack і , додає розробника та менеджмент майданчика, додає всі необхідні WF для якісної взіємодії взаємодії з майданчиком та запускає WF "Отримання тестового ключа"
4. Отримання технічної документації – Менеджер по роботі з клієнтами додає до Slack каналу посилання на технічну документацію (ТЗ процедур Swagger)
5. Подання запиту на тестовий ключ – Майданчик подає запит на отримання ключа до тестового середовища через наданє посилання надання посилання на SD в у розпочатому WF "Отримання тестового ключа".
6. Перевірка створеного запиту на наявність всіх документів – Менеджер по роботі з майданчиками підтверджує наявність договірних відносин з майданчиком змінивши виконавця задачі на DevOps команду (Павел Кузьменко)./Підтвердження відбувається в Slack через WF
7. Надання тест ключів – DevOps команда виконує видачу ключів до оточень (Sandbox та Stage) до всіх напрямків , коментуючи доступ в конфігураційному файлі вручну.
8. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика та в канал відділу по роботі з майданчиками приходить повідомлення про видачу ключів майданчику до тестових оточень.

...

1. Подання запиту на тестування – Майданчик подає запит тестування розвобленого розробленого функціоналу через WF "Взаємодія для тестування функціоналу", збирає пакет документів (Зазначений в WF) та передає на розгляд внутрішній комісії.
2. Перевірка пакету документів – Менеджер по роботі з майданчиками перевіряє, чи всі необхідні документи присутні.
3. Розгляд комісією – Комісія проводить перевірку та рекомендує (або ні) перехід до тестування.
4. Укладення договору на тестування – Менеджер по роботі з майданчиками підписує договір про тестування з майданчиком.
5. Подача заявки на тестування – Майданчик створює заявку посилання в SD отриманому в WF "Взаємодія для тестування функціоналу". 
6. Олата Оплата тестування – Майданчик оплачує тестування  в тестування (у разі якщо воно оплачуванє або безкоштовне тестуванняє оплачуваним), підтверджує проходження тестування та наявність договорів за протестованим функціоналом з майданчиком змінивши виконавця задачі на DevOps команду (Павел Кузьменко).
7. Підтвердження оплати тестування – Менеджер по роботі з майданчиками підтверджує проходження оплату змінивши виконавця задачі на QA команду (Тарас Бондарчук).
8. Тестування – Проводиться тестування доступу з виданими ключами.
9. Завершення тестування – Команда QA надає висновок тестування (тестувальники закривають задачу в JIRA, якщо тестування успішне, та інформують Менеджера по роботі з майданчиками).
10. Закриття акта виконаних робіт – Підтвердження завершення робіт.
11. Укладення договору про використання АТС – Менеджер по роботі з майданчиками укладає договір із майданчиком.

...

1. Подання запиту на ключ – Майданчик подає запит на отримання ключа до продуктивного оточення через WF "Отримання продуктивного ключа".
2. Перевірка створено створеного запиту на наявність всіх усіх документів – Менеджер по роботі з майданчиками підтверджує проходження тестування та наявність договорів за протестованим функціоналом з майданчиком змінивши виконавця задачі на DevOps команду (Павел Кузьменко).
3. Надання прод ключів до продуктивного оточення – DevOps команда виконує видачу ключа з доступами зазначеними в задачі, коментуючи доступ в конфігураційному файлі вручну.
4. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика та в канал відділу по роботі з майданчиками приходить повідомлення про видачу ключів майданчику до продуктивного оточення .

...

1. Подання запиту на ключ – Майданчик подає запит на розширення ключа до продуктивного оточення через WF "Розширення дозволів на Прод оточення".
2. Перевірка створено створеного запиту на наявність всіх документів – Менеджер по роботі з майданчиками підтверджує проходження тестування та наявність договорів за протестованим функціоналом з майданчиком змінивши виконавця задачі на DevOps команду (Павел Кузьменко).
3. Надання прод ключів до продуктивного оточення – DevOps команда виконує розширення дозволів ключа відповідно до зазначених задачі, коментуючи доступ в конфігураційному файлі вручну.
4. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика та в канал відділу по роботі з майданчиками приходить повідомлення про видачу ключів майданчику до продуктивного оточення .

Частина 8. Блокування майданчиків на всіх ототченнях / Обмеження дозволів 

1. Офіційний лист/виявлення порушення – Якщо майданчик ініціює вихід , подається офіційний лист про розірвання договору (на основі завершення співпраці чи фінансових причин). Якщо ж є порушення, то питання ініціюється з нашого боку.
2. Створення завдання – Менеджер по роботі з майданчиками створює задачу в системі та тегає Тараса Бондарчука (приклад: SBM-1046 - Аутентификация для просмотра подробных данных проблемы ) для подальшого виконання.
3. Юридична перевірка – Юридичний відділ проводить перевірку обґрунтованості вимоги та підтверджує її.
4. Офіційне підтвердження – Наказ про припинення/обмеження доступу (видається юридичним відділом або менеджером по роботі з майданчиками); у разі власного бажання – розірвання договору.
5. Інформування бухгалтерії – Бухгалтерія інформується про припинення доступу майданчику.
6. Оцінка на наявність активних об'єктів – Визначає подальший шлях чи це блокування чи обмеження ключейключів
7. Якщо всі взаємодії завершено - відбувається блокування ключейключів
   1. Створення заявки на DevOps – Менеджер по роботі з майданчиками створює задачу через SD на DevOps команду
   2. Виконання блокування – DevOps команда виконує блокування, коментуючи доступ в конфігураційному файлі вручну.
   3. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика та в канал відділу по роботі з майданчиками приходить повідомлення про блокування доступу майданчику.
   4. Створення заявки на відділ маркетингу – після надходження повідомлення про блокування доступу майданчику менеджер по роботі з майданчиками створює задачу на контент менеджера для видалення логотипу майданчика з порталу та з каталогу.
   5. Оновлення інформації на порталі – Контент менеджер видаляє логотип майданчика з порталу та з каталогу і переводить задачу в термінальний стан ("Готово"/"Done") та інформує відділ по роботі з майданчиками.
   6. Повідомлення BI – Менеджер по роботі з майданчиками інформує РО (Андрія Салія) про необхідність внесення змін до аналітичної звітності в BI-системі.
   7. Оновлення статусу задачі на юр відділу – після надходження повідомлення про видалення логотипу майданчика з порталу та з каталогу та інформування PO, менеджер по роботі з майданчиками переводить задачу в термінальний стан ("Готово"/"Done").
8. Якщо присутні обмеження, які не дозволяють повне блокування ключей ключів - відбувається обмеження дозволів 
   1. Створення заявки на DevOps – Менеджер по роботі з майданчиками створює задачу через SD на DevOps команду
   2. Виконання блокування – DevOps команда виконує обмеження доступів ключа згідно задачі, коментуючи доступ в конфігураційному файлі вручну.
   3. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика та в канал відділу по роботі з майданчиками приходить повідомлення про обмеження доступу майданчику.
   4. Створення заявки на відділ маркетингу – після надходження повідомлення про блокування доступу майданчику менеджер по роботі з майданчиками створює задачу на контент менеджера для видалення логотипу майданчика з порталу та з каталогу.
   5. Оновлення інформації на порталі – Контент менеджер видаляє логотип майданчика з порталу та з каталогу і переводить задачу в термінальний стан ("Готово"/"Done") та інформує відділ по роботі з майданчиками.
   6. Повідомлення BI – Менеджер по роботі з майданчиками інформує РО (Андрія Салія) про необхідність внесення змін до аналітичної звітності в BI-системі.
   7. Оновлення статусу задачі на юр відділу – після надходження повідомлення про видалення логотипу майданчика з порталу та з каталогу та інформування PO, менеджер по роботі з майданчиками переводить задачу в термінальний стан ("Готово"/"Done")

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