Матриця Рамсфелда як ефективний інструмент в процесі приняття рішень
Під час брифінгу, присвяченого війні в Іраку, Дональд Рамсфелд поділив інформацію на 4 категорії: відоме знане, відоме незнане, невідоме знане, невідо...
CI/CD пайплайни допомагають мінімізувати потенційні ризики в процесі інтеграції змін коду в репозиторій, ізолювати вплив можливих помилок та спрощувати їх виправлення. Головне завдання CI/CD – прискорити процес розробки та надання цінності кінцевому користувачеві. Проте, завжди існують шляхи та інструменти, як зробити процес ще ефективнішим. Матричний підхід є одним із таких варіантів.
Базова структура пайплайна передбачає одночасне виконання завдань на певному етапі. При цьому завдання наступного етапу можуть бути виконаними за умов завершення попередніх. Цей процес продовжується на всіх етапах. Різні завдання у конвеєрі потребують різний час для їхнього виконання. Учасникам команди доводиться чекати, аби внести свої зміни до проєкту. Це значно уповільнює робочий процес та знижує продуктивність. Також, наявність однакових конвеєрів та сценаріїв створення можуть призвести до блокування пайплайнів. Для оптимізації ресурсів та підвищення продуктивності існує сенс створення клонів завдань та паралельного їх запуску.
Раніше необхідно було вручну визначати завдання для їхнього паралельного виконання. З появою паралельних матричних завдань з’явилась можливість створювати завдання під час виконання на основі зазначених змінних.
Матрична стратегія використовує змінні під час визначення завдання, що дозволяє забезпечити автоматичне створення кількох виконань завдань. Ця стратегія може використовуватися в процесі тестування коду у різних варіантах мови та/або різних операційних системах. Матриця може бути створена з різними конфігураціями завдань із зазначенням однієї чи більше змінних. Визначаючи змінні (одну чи кілька), завдання застосовуватиметься для кожної комбінації змінних.
Варто звернути увагу на певну особливість. Вона полягає в тому, що організації часто використовують монорепозиторії для кращого управління проєктами. Проте, продуктивність конвеєра знижується в ситуації, коли в репозиторії знаходиться велика кількість проєктів і одне визначення конвеєра використовується для запуску різних автоматизованих процесів для різних компонентів. Використання батьківських та дочірніх конвеєрів сприяють створенню ефективних конвеєрів. Такий підхід мінімізує можливість виникнення конфліктів злиття, дозволяє редагування частини конвеєра за необхідністю.
При оптимізації роботи конвеєрів знижуються витрати часу, необхідного розробникам для обслуговування, з одного боку. З іншого боку, це дозволяє звільнити час та простір для нових ідей, творчого підходу та підвищення продуктивності. Наприклад, використовуючи матрицю, можна розбити великі конвеєри на керовані частини для більш ефективного обслуговування та максимізувати кількість завдань, які виконуються паралельно. Порядок створення завдань диктує порядок змінних матриці. Перша змінна є першим завданням під час виконання.
Архітектура комплексного Qlik-додатка складається з кількох шарів (трансформери, модель, дашборд та екстрактори). І при використанні QOps, матрична стратегія якнайкраще підходить для управління однотипними додатками в межах одного шару. До таких можна віднести додатки у шарі трансформерів та екстракторів.
GitHub, GitLab та Jenkins дозволяють будувати пайплайни на основі матричної стратегії, яка перебирає наявні завдання згідно з декартовим множенням. Це зроблено для розширення можливостей CI/CD, а саме у проведенні тестування на різних платформах або, наприклад, із різними версіями фреймворків.
На скріншоті нижче відображено приклад вихідного файлу пайплайну для GitHub, перевантаження трансформерів в якому реалізовано з використанням матричної стратегії. Ключовим словом для цього є matrix у блоці strategy. Необхідний перелік програм вказується у вигляді списку у рядку 403. При цьому підстановка програми, що ітерується, буде виконана при кожному згадуванні matrix.app.
Так виглядає список додатків, що використовуються в графічному інтерфейсі GitHub при виконанні пайплайна. При цьому легко виконується масштабування кількості додатків, що обробляються. Для цього достатньо лише змінити їх список і не вносити зміни до виконуваної частини коду.
Більше інформації ви знайдете за посиланням