Якщо ваша компанія тільки впроваджує DevOps або інструменти CI/CD, вам може бути корисно познайомитися з найпоширенішими помилками, щоб не повторити їх і не наступати на чужі граблі.
Команда переклала статтю .
Неготовність до зміни культури та процесів
Якщо подивитися на циклічну діаграму , то видно, що у DevOps-практиках тестування є безперервною роботою, фундаментальною частиною кожного окремого розгортання.
Нескінченна циклічна діаграма DevOps
Тестування та забезпечення якості у процесі розробки та доставки є обов'язковою частиною всього, що роблять розробники. Це вимагає зміни мислення, щоб увімкнути тестування в кожну задачу.
Тестування стає частиною повсякденної роботи кожного члена команди. Перехід на постійне тестування не проходить легко, потрібно бути готовим до цього.
Відсутність зворотного зв'язку
Ефективність DevOps залежить від постійного зворотного зв'язку. Безперервне поліпшення неможливе, якщо немає місця для співпраці та спілкування.
Компаніям, які не організують ретроспективні зустрічі, важко запровадити культуру безперервного зворотного зв'язку у CI/CD. Ретроспективні зустрічі проводять наприкінці кожної ітерації, учасники групи обговорюють, що минуло добре, що погано. Ретроспективні зустрічі - фундамент Scrum/Agile, але вони також необхідні для DevOps.
Це з тим, що ретроспективні зустрічі прищеплюють звичку проводити обмінюватися відгуками і думками. Один із найважливіших моментів на старті — організація ретро-зустріч, що повторюються, щоб вони стали зрозумілими і звичними для всього колективу.
Коли справа доходить до якості програмного забезпечення, всі члени команди відповідають за його підтримку. Наприклад, розробники можуть писати модульні тести, а також писати код з урахуванням тестованості, допомагаючи знизити ризики від початку.
Один із простих способів відобразити зміну уявлень про тестування — називати тестувальників не QA, а тестувальник програмного забезпечення чи інженер з якості. Ця зміна може здатися занадто простою або навіть дурною. Але якщо когось називають «фахівцем із забезпечення якості програмного забезпечення», це дає неправильне уявлення про те, хто відповідає за якість продукту. У практиках Agile, CI/CD та DevOps усі несуть відповідальність за якість ПЗ.
Іншим важливим моментом є розуміння, що означає якість для всієї команди та кожного її члена, організації, зацікавлених сторін.
Неправильне розуміння завершеності етапу
Якщо якість — безперервний та загальний процес, потрібне загальне розуміння завершеності етапу. Як зрозуміти, що етап закінчено? Що відбувається, коли етап позначений як виконаний на дошці Trello або на іншій канбан-дошці?
Визначення виконаного етапу (DoD) є потужним інструментом у контексті CD DevOps/CI. Воно допомагає краще зрозуміти стандарти якості того, що та як будує команда.
Команда розробників має вирішити, що означає Готово. Їм потрібно сісти та скласти список характеристик, які мають виконуватися на кожному етапі, щоб його можна було вважати завершеним.
DoD робить процес прозорішим та полегшує впровадження CI/CD, якщо він зрозумілий усім учасникам команди та взаємно узгоджений.
Відсутність реалістичних, чітко визначених цілей
Це одна з найчастіше цитованих порад, але її варто повторити. Для успіху будь-якого серйозного починання, у тому числі впровадження CI/CD або DevOps, потрібно встановити реальні цілі та вимірювати продуктивність щодо них. Чого ви намагаєтеся досягти за допомогою CI/CD? Це дозволяє швидше випускати релізи з найкращою якістю?
Будь-які поставлені цілі мають бути не тільки прозорими та реалістичними, а й відповідати поточній діяльності компанії. Наприклад, як часто ваші клієнти потребують нових виправлень чи версій? Немає потреби перевантажувати процеси та випускати релізи швидше, якщо в цьому немає додаткових переваг для користувачів.
Крім того, вам не завжди потрібно продавати як CD, так і CI. Наприклад, компанії з високим ступенем регулювання, такі як банки та медичні клініки, можуть працювати лише з CI.
CI служить гарною відправною точкою для будь-якої компанії, яка впроваджує DevOps. За його впровадження у компанії значно змінюються підходи до постачання програмного забезпечення. Після того як освоєно CI, можна подумати про поліпшення всього процесу, збільшення швидкості викочування та інші зміни.
Для багатьох організацій достатньо одного CI, і CD має бути реалізований лише, якщо він приносить додаткову користь.
Відсутність відповідних панелей моніторингу та метрик
Як тільки ви встановили цілі, команда розробників може створити панель моніторингу для вимірювання KPI. До її розробки варто провести оцінку параметрів, які відстежуватимуться.
Різні звіти та програми корисні для різних членів команди. Scrum-майстри більше цікавить статус та охоплення. У той час, як вищому керівництву може бути цікава швидкість вигоряння фахівців.
Деякі команди також використовують для оцінки статусу CI/CD дашборди з червоними, жовтими та зеленими індикаторами, щоб розуміти, чи правильно вони все роблять, чи виникла помилка. Червоний означає, що потрібно звернути увагу на те, що відбувається.
Однак, якщо інформаційні панелі не стандартизовані, вони можуть вводити в оману. Проаналізуйте, які дані потрібні всім, а потім створіть стандартизований опис того, що вони означають. Дізнайтеся, що має більше значення для зацікавлених сторін: графіки, текст або числа.
Відсутність ручних тестів
Автоматизація тестування закладає основу хорошого конвеєра CI/CD. Але автоматизоване тестування на всіх етапах не означає, що ви не маєте проводити ручне тестування.
Щоб побудувати ефективний конвеєр CI/CD, потрібні й ручні випробування. Завжди будуть деякі аспекти тестування, які потребують аналізу людиною.
Варто подумати про інтеграцію зусиль із ручного тестування в конвеєр. Після завершення ручного тестування деяких тестових прикладів ви можете перейти до етапу розгортання.
Не намагатись покращувати тести
Ефективний конвеєр CI/CD вимагає доступу до потрібних інструментів, чи це управління тестуванням чи інтеграція та постійний моніторинг.
Створення сильної, орієнтованої на якість культури спрямовано , моніторинг взаємодії з клієнтами після розгортання та відстеження покращень.
Ось кілька практичних порад, які ви можете легко реалізувати:
- Переконайтеся, що тести прості в написанні і досить гнучкі, щоб не ламатися під час рефакторингу коду.
- Команди розробників повинні бути включені в процес тестування - бачити список проблем користувача і запитів, які важливі для перевірки під час конвеєрів CI.
- У вас може і не бути повного покриття тестами, але завжди слідкуйте, щоб потоки, важливі для UX та взаємодії з клієнтами, були протестовані.
Останній, але не менш важливий пункт
Перехід до CI/CD зазвичай ініціюється знизу вгору, але, зрештою, це трансформація, яка потребує участі керівництва, витрат часу та ресурсів із боку компанії. Адже CI/CD — це набір навичок, процеси, інструменти та культурна перебудова, впровадити такі зміни можна лише системно.
Що ще почитати на тему:
- .
- .
- .
Джерело: habr.com