Если ваша компания только внедряет DevOps или инструменты CI/CD, вам может быть полезно познакомиться с самыми распространенными ошибками, чтобы не повторить их и не наступать на чужие грабли. 

Команда Mail.ru Cloud Solutions перевела статью Avoid These Common Pitfalls When Transitioning to CI/CD by Jasmine Chokshi с дополнениями.

Неготовность к изменению культуры и процессов

Если посмотреть на циклическую диаграмму DevOps, то видно, что в 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 требует доступа к нужным инструментам, будь то управление тестированием или интеграция и постоянный мониторинг.

Создание сильной, ориентированной на качество культуры направлено на внедрение тестов, мониторинг взаимодействия с клиентами после развертывания и отслеживание улучшений. 

Вот несколько практических советов, которые вы можете легко реализовать:

1. Убедитесь, что тесты просты в написании и достаточно гибки, чтобы не ломаться при рефакторинге кода.
2. Команды разработчиков должны быть включены в процесс тестирования — видеть список пользовательских проблем и запросов, которые важны для проверки во время конвейеров CI.
3. У вас может и не быть полного покрытия тестами, но всегда следите, чтобы потоки, важные для UX и взаимодействия с клиентами, были протестированы.

Последний, но не менее важный пункт

Переход к CI/CD обычно инициируется снизу вверх, но, в конце концов, это трансформация, которая требует участия руководства, затрат времени и ресурсов со стороны компании. Ведь CI/CD — это набор навыков, процессы, инструменты и ​​культурная перестройка, внедрить такие изменения можно только системно.