Поточна організація коду та конфігурації, які ви описуєте, структурується за допомогою відповідних технічних рішень. Це погана конструкція, яка додасть багато накладних витрат у нашій діяльності з обслуговування, а також додасть багато пасток і на нашому шляху. Натомість ця організація повинна бути структурована навколо артефактів, які ми розгортаємо.
Причиною цього є те, що ми хочемо розглядати артефакти ( наприклад, зображення докера або програмний пакет) як об’єкти наступних дієслів:
розглянути мінімальний набір автоматизованих завдань, які ми хочемо виконати. Якщо ми хочемо щось змінити про те, як реалізується тестове дієслово, легко відвідати папку, відповідну цьому артефакту, у відповідному сховищі, а потім виявити специфічні для автоматики елементи автоматизації, які потрібно оновити. Натомість, якщо рецепти автоматизації побудовані навколо технічних рішень, тоді нам потрібно зрозуміти, що дженкіни беруть участь у процедурах тестування, і знайти там предмети автоматизації, пов'язані з артефактом. У складних ситуаціях організація навколо технічних рішень робить оновлення дуже важкими, тому що ми повинні апріорі знати всі технічні рішення, що беруть участь у якійсь службі, щоб відповідно їх оновити.
Наприклад, сховище, що містить код веб-сайту та мікро-сервісу "a", може мати такі підкаталоги, присвячені операціям:
./ops/website
./ops/micro-service-a
кожен з яких має три сценарії, що викликаються build, testі deploy. Тепер, коли організація елементів автоматизації якимось чином з'ясована, звернемо увагу на конфігурацію.
Основні умови та вимоги щодо організації конфігурації встановлюються deployдієсловом при застосуванні до службового артефакту. deployДієслово повинен мати наступні параметри:
- версія артефакту для розгортання,
- ціль розгортання артефакту, яка описує конкретне середовище, де працюватиме розгорнутий артефакт ( наприклад, кластер та кінцеві точки, з якими він повинен поговорити)
- облікові дані, які він повинен використовувати для підключення до інших кінцевих точок ( наприклад, баз даних)
- конфігурація виконання (наприклад, тривалість записів кешу тощо)
З точки зору експлуатації, ця розбивка параметризації відповідає природному ступеню свободи проблеми розгортання - окрім облікових даних, які можуть бути в комплекті з конфігурацією виконання, але краще відокремити їх, щоб уникнути їх необережного розповсюдження.