Если ваша компания только внедряет 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 требует доступа к нужным инструментам, будь то управление тестированием или интеграция и постоянный мониторинг.
Создание сильной, ориентированной на качество культуры направлено на внедрение тестов, мониторинг взаимодействия с клиентами после развертывания и отслеживание улучшений.
Вот несколько практических советов, которые вы можете легко реализовать:
- Убедитесь, что тесты просты в написании и достаточно гибки, чтобы не ломаться при рефакторинге кода.
- Команды разработчиков должны быть включены в процесс тестирования — видеть список пользовательских проблем и запросов, которые важны для проверки во время конвейеров CI.
- У вас может и не быть полного покрытия тестами, но всегда следите, чтобы потоки, важные для UX и взаимодействия с клиентами, были протестированы.
Последний, но не менее важный пункт
Переход к CI/CD обычно инициируется снизу вверх, но, в конце концов, это трансформация, которая требует участия руководства, затрат времени и ресурсов со стороны компании. Ведь CI/CD — это набор навыков, процессы, инструменты и культурная перестройка, внедрить такие изменения можно только системно.
Что еще почитать по теме:
|
