Конфігурація процедур
Типи процедур / види закупівель VS конфігурації закупівель
“Процедура” або тип закупівлі це логічно і законодавчо виокремлена сутність, яка реалізує процес закупівлі відповідно чітко визначених правил. Втім, іноді правила можуть змінюватися або бути різними в межах однієї “процедури”. Такі відмінності можуть бути реалізовані допомогою кофігурацій.
Конфігурації, як інструмент, почали використовувати відносно недавно. Тому їх поки не дуже багато. Раніше будь-яка відмінність поведінки процедури реалізовувалась через створення під це окремої “процедури”. Часто це робили копіюванням коду.
Зараз ми рухаємо систему в напрямку, що буде інсувати єдина кодова база, а відмінності “процедур” повністю визначені “конфігами”.
Створення конфігурацій в репозиторії стандартів
Ознайомитись з усіма можливими конфігураціями процедур можна тут.
Можливі значення конфігів для кожнох процедури мають бути вказані в стандартах
При додаванні нового конфігу - його “назву” треба додати в файл кожної процедури. А при додаванні нової процедури - додати новий файл, з вказанням усіх можливих варіантів конфігурацій.
Після додавання конфігурацій треба зробити можливим їх використання в коді як описано тут
Ось коміт приклад створення нової конфігурації: внесення назви конфігу у відповідний словник і внесенння можливих значень в файл кожнох процедури.
Для розробки можна використовувати власну версію стандартів: вказувати в requirements.txt посилання на свій форк репозиторія стандартів або підкидати стандарти к контенер апі черeз volumes
Реалізація конфігурацій в код АПІ
Реалізація складається з багатьох кроків, всі вони як правило обов’яхкові.
Розглянемо цей коміт як приклад.
Вказано на використання версії стандартів, що мають необхідний конфіг. (Це окремий коміт, якого ще не має у main гілці) Додавання конфігу до репозиторія стандартів було попереднім кроком.
Режим сумісності / перехідний період
Щоб не зламати сервіси клієнти АПІ, необхідно реалізувати можливість автоматичного заповненя конфігу. Після релізу змін, АПІ має приймати конфіг в межах дозволених значень завжди. Але додатково заповнювати значенням по замовчанню, допоки усі клієнти не зроблять відповідні змінні і “перехідний період” буде вимкнено.
Розглянемо приклад в коді. (Іноді така конфігураціє буває датою)
В цьому конкретному випадку, така конфігурація (коли включена) дозволяє НЕ передавати в апі нову конфіг minBidsNumber. І той буде заповнюватись автоматично значенням 1, 2 або 3 відповідно до поередньої поведінки процедур.
Конфіг перехідного періоду велючає заповнення інофрмації про конфіг кожного тендера, якщо його ще немає. Цей серіалізатор буде заповнювати значення minBidsNumber, якщо його немає в БД і воно не було передано в запиті.
Міграція
Для уніфікації конфіг має бути присутнім в усіх об’єктах, тому необхідно додати приальне значенно в “дорелізні” об’єкти. Переглянути код можна тут
Зверніть увагу, функція що повертая значення по замовчанню на перехідний період та сама, що і в міграції.
Використання конфігу
Далі передане (або за замовчанням) значення використовується в коді логіки процедури.
Конфіг в прикладі був раніше атрибутом стейт класа і перевизначався наслідуанням
Тести
Вся поведніка має бути покрита тестами.