Close

Как практиковать DevOps

Пошаговое руководство для команд, желающих внедрить DevOps

Фотография: Кришна Сай
Уоррен Марусяк

Старший технический эксперт


Ваш цикл разработки программного обеспечения — хаос из инструментов и рабочих процессов? Ваши команды и проекты разобщены? Если вы ответили утвердительно на любой из этих вопросов, пришло время подумать о DevOps. Эта методология помогает упростить и оптимизировать процессы разработки и развертывания путем создания новой экосистемы разработки программного обеспечения.

Но как внедрить DevOps? Одна из основных сложностей на этом пути — отсутствие стандартного процесса, поскольку каждая команда имеет свои потребности и цели. Изобилие инструментов и ресурсов может вызвать «аналитический паралич», что препятствует внедрению DevOps. Ниже описана последовательность действий, с помощью которой вы можете внедрить DevOps в своей команде.

Почему DevOps?


Если коротко, DevOps повышает производительность, позволяя разработчикам делать то, что получается у них лучше всего: создавать превосходное программное обеспечение, вместо того чтобы вручную выполнять малоценную работу, например проверять файлы журналов. Практики DevOps позволяют автоматизировать повторяющуюся работу, например запуск тестов и развертываний, мониторинг программного обеспечения в рабочей среде на предмет проблем и формирование устойчивой к проблемам методологии развертывания. Разработчики получают возможность творить и экспериментировать, что повышает производительность.

Существует множество определений DevOps. В данной статье DevOps означает, что команда отвечает за весь жизненный цикл программного обеспечения. Команда DevOps разрабатывает, внедряет, развертывает, отслеживает, обновляет программное обеспечение и устраняет проблемы. Она владеет кодом и инфраструктурой, на которой выполняется код. Она отвечает не только за удобство работы конечного пользователя, но и за проблемы в рабочей среде.

Принцип DevOps — создать процесс, в котором прогнозируется возникновение проблем, а разработчики получают возможность эффективно их решать. Процесс DevOps должен предоставлять разработчикам немедленную обратную связь о состоянии системы после каждого развертывания. Чем раньше обнаруживается проблема, тем меньше ее влияние и тем скорее команда может перейти к следующему объему работ. Когда внедрять изменения и исправлять проблемы легко, разработчики могут экспериментировать, создавать, выпускать и проверять новые идеи.

DevOps — не технологии. Если вы просто приобретаете специальные инструменты и думаете, что у вас DevOps, вы начинаете не с того конца. Суть DevOps в том, чтобы сформировать культуру совместной ответственности, прозрачности и быстрой обратной связи. Технологии — просто инструмент, который позволяет этого добиться.

логотип организации
Связанные материалы

Начните работу бесплатно

Значок: награда
Связанные материалы

Подробнее о рекомендациях по DevOps

Оговорка


Учитывая, что у каждой команды своя отправная точка, некоторые из следующих шагов могут быть неприменимы в вашем случае. К тому же это не исчерпывающий список. Представленные шаги задуманы как ориентир, чтобы помочь команде внедрить DevOps.

В этой статье DevOps используется в качестве универсального термина для обозначения культуры, процессов и технологий, которые обеспечивают работу DevOps.

8 шагов к DevOps


Цикл DevOps

Шаг 1. Выберите компонент

Первый шаг — начать с малого. Выберите компонент, который в настоящее время находится в рабочей среде. Идеальный вариант — компонент с простой базой кода, небольшим количеством зависимостей и минимальной инфраструктурой. Он станет опытным полигоном, на котором команда приобретет первый опыт внедрения DevOps.

Шаг 2. Рассмотрите возможность внедрения гибкой методологии, например Scrum

DevOps часто сочетается с методологией гибкой работы, например со Scrum. Нет необходимости внедрять все обычаи и практики, связанные со Scrum. Три элемента scrum, которые, как правило, легко внедряются и быстро приносят пользу, — это бэклог, спринт и планирование спринта.

Команда DevOps может добавлять работу и определять ее приоритет в бэклоге Scrum, а затем переносить часть этой работы в спринт — фиксированный промежуток времени для выполнения определенного объема работы. Планирование спринта — это процесс принятия решения о том, какие задачи должны быть переданы из бэклога в следующий спринт.

Шаг 3. Используйте систему управления версиями на основе Git

Контроль версий — передовая практика DevOps, которая повышает эффективность совместной работы и ускоряет циклы релизов. Такие инструменты, как Bitbucket, позволяют разработчикам вести совместную работу, обмениваться ее результатами, объединять программный код и создавать его резервные копии.

Выберите модель ветвления. Краткий обзор этого понятия приводится в этой статье. Рабочий процесс GitHub — отличная отправная точка для команд, не имеющих опыта работы с Git, поскольку он прост для понимания и реализации. Зачастую выбор делается в пользу магистральной разработки, однако она требует большей дисциплины и затрудняет первые шаги в Git.

Шаг 4. Объедините управление версиями с отслеживанием работы

Объедините инструмент управления версиями с инструментом отслеживания работы. Когда все, что относится к конкретному проекту, собрано в одном месте, это экономит много времени разработчикам и руководству. Ниже приводится пример задачи Jira с обновлениями из репозитория системы управления версиями на основе Git. В задачах Jira есть раздел Development (Разработка), где собраны данные о работе, проделанной для решения задачи Jira в системе управления версиями. В показанной ниже задаче была одна ветка, шесть коммитов, один запрос pull и одна сборка.

Снимок экрана, на котором показана интеграция системы управления версиями с инструментом отслеживания работы

Дополнительные сведения можно найти в разделе Development (Разработка) в задаче Jira. На вкладке Commits (Коммиты) перечислены все коммиты, связанные с задачей Jira.

Снимок экрана, на котором показана интеграция системы управления версиями с инструментом отслеживания работы

В этом разделе перечислены все запросы pull, связанные с задачей Jira.

Снимок экрана, на котором показана интеграция системы управления версиями с инструментом отслеживания работы

Код, относящийся к этой задаче Jira, развертывается во всех средах, которые перечислены в разделе Deployments (Развертывания). Такие интеграции обычно работают путем добавления идентификатора задачи Jira — в данном случае IM-202 — в комментарии к коммитам и имена веток, связанных с задачей Jira.

Снимок экрана, на котором показана интеграция системы управления версиями с инструментом отслеживания работы

Есть вкладка кода, на которой представлены ссылки на все репозитории системы управления версиями, связанные с проектом. Это помогает разработчикам находить код, над которым им необходимо работать, когда они назначают себе задачу Jira.

Снимок экрана, на котором показана интеграция системы управления версиями с инструментом отслеживания работы

Шаг 5. Напишите тесты

Для конвейеров CI/CD необходимы тесты, чтобы проверить правильность работы кода, развернутого в различных средах. Начните с написания модульных тестов для кода. В идеале предполагается покрытие кода на 90 процентов, однако на начальном этапе это нереально. Установите низкий базовый уровень покрытия и постепенно наращивайте его для модульных тестов. Для этого можно добавлять рабочие задачи в бэклог.

Применяйте разработку на основе тестирования при исправлении багов, обнаруженных в готовом коде. Когда находите баг, пишите модульные тесты, интеграционные тесты и (или) системные тесты, которые выдают результат «не пройдено» в средах, где существует этот баг. Затем исправляйте баг и проверяйте, успешно ли проходят тесты. Со временем этот процесс приведет к органическому увеличению охвата кода. Если баг обнаруживается в тестовой или промежуточной среде, тесты гарантируют, что при переходе в рабочую среду код будет функционировать правильно.

Поначалу это трудозатратно, однако важно. Тестирование позволяет командам увидеть влияние изменений кода на поведение системы, прежде чем конечные пользователи почувствуют эти изменения на себе.

Модульные тесты

Модульные тесты используются для проверки правильности исходного кода и должны выполняться в качестве одного из первых шагов в конвейере CI/CD. Разработчики должны писать тесты для развертываний в «зеленой» среде, проблемных входных данных и известных тупиковых ситуаций. При написании тестов разработчики могут имитировать входные данные и ожидаемые результаты.

Интеграционное тестирование

С помощью интеграционных тестов проверяется правильность взаимодействия двух компонентов друг с другом. Сымитируйте входные данные и ожидаемые результаты. Эти тесты — один из первых шагов в конвейере CI/CD перед развертыванием в любой среде. Чтобы эти тесты заработали, обычно необходим больший объем имитации, чем для модульных тестов.

Системные тесты

Системные тесты нужны, чтобы проверить комплексную эффективность системы и удостовериться, что она функционирует ожидаемым образом в каждой среде. Сымитируйте входные данные, которые может получить компонент, и запустите систему. Убедитесь, что система возвращает необходимые значения и правильно обновляет остальные свои части. Эти тесты следует запускать после развертывания в каждой среде.

Шаг 6. Создайте процесс CI/CD для развертывания компонента

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

Структура конвейера

Этот конвейер начинается с запуска модульных и интеграционных тестов перед развертыванием в тестовой среде. Системные тесты выполняются после развертывания в среде.

Снимок экрана, на котором показана интеграция системы управления версиями с инструментом отслеживания работы

Черновой шаблон, предложенный выше, можно расширить несколькими способами. Проверка кода, статический анализ и сканирование безопасности — хорошие дополнительные шаги перед модульными и интеграционными тестами. Проверка кода может обеспечить соблюдение стандартов программирования, с помощью статического анализа можно проверить наличие антишаблонов, а сканирование безопасности позволяет обнаруживать известные уязвимости.

Снимок экрана, на котором показана интеграция системы управления версиями с инструментом отслеживания работы

Конвейеры CI/CD для развертывания инфраструктуры и кода с большой вероятностью различаются. Конвейер CI/CD для инфраструктуры зачастую не содержит модульных или интеграционных тестов. Системные тесты будут запускаться в нем после каждого развертывания, чтобы обеспечить непрерывность работы системы.

Инфраструктура

Различия в инфраструктуре между средами затрудняют правильное выполнение программного обеспечения, работающего в этой среде. Для надлежащего выполнения ПО правила брандмауэра, пользовательские права, доступ к базе данных и другие компоненты уровня инфраструктуры должны находиться в известной конфигурации. Правильно повторить развертывание инфраструктуры вручную может быть сложно. Поскольку этот процесс включает множество этапов, попытка по памяти выполнить каждый шаг в правильном порядке с правильными параметрами может привести к ошибкам. Для устранения этих и других проблем инфраструктура должна быть определена в коде везде, где это возможно.

Определить инфраструктуру в коде можно с помощью различных инструментов, в том числе AWS CloudFormation, Terraform, Ansible, Puppet или Chef.

Напишите несколько конвейеров для развертывания инфраструктуры. Как и при написании кода, развертывание инфраструктуры полезно выполнять в виде модулей. По возможности разбивайте необходимую инфраструктуру на непересекающиеся подмножества. Предположим, что A, B, C и D — это абстрактное представление компонентов инфраструктуры, которые могут зависеть друг от друга. Например, A — экземпляр EC2, а B — корзина S3. Зависимости, в которых компонент инфраструктуры A — и только A — зависит от компонента B, скорее всего, должны находиться вместе в одном конвейере CI/CD. Зависимости, в которых A, B и C зависят от D, но независимы между собой, должны разбиваться на несколько конвейеров CI/CD. В этом случае создаются четыре независимых конвейера. В данном примере необходимо создать один конвейер для D, от которого зависят все три других компонента, и по одному конвейеру для A, B и C.

Программирование

Конвейеры CI/CD создаются для развертывания кода. Как правило, их просто реализовать, поскольку инфраструктура уже существует благодаря предшествующей работе. Здесь важны тестирование, повторяемость и возможность восстановления после неудачных развертываний.

Повторяемость — это возможность развертывать одно и то же изменение без ущерба для системы. Развертывание должно быть повторяемым и идемпотентным. Оно должно приводить систему в известную конфигурацию, а не применять модификатор к существующему состоянию. Применение модификатора нельзя повторить, так как после первого развертывания начальное состояние модификатора, необходимое для его правильной работы, изменится.

Простой пример неповторяющегося обновления — обновление файла конфигурации путем добавления в него данных. Не добавляйте строки в файлы конфигурации и не используйте подобный метод модификации. Если обновления выполняются путем добавления, в файле конфигурации могут оказаться десятки повторяющихся строк. Вместо этого замените файл конфигурации правильно записанным файлом из системы управления версиями.

Этот принцип также необходимо применять к обновлению баз данных. Обновление базы данных может быть сложным и требовать внимания к деталям. Крайне важно сделать процесс повторяемым и отказоустойчивым. Создавайте резервные копии непосредственно перед внесением изменений, чтобы обеспечить возможность восстановления.

Еще один вопрос заключается в том, как провести восстановление после неудачного развертывания. Развертывание завершилось неудачей, и система перешла в неизвестное состояние, либо развертывание прошло удачно, но сработали сигналы тревоги, и начали поступать заявки на устранение неполадок. Есть два основных способа решения этой проблемы. Первый способ —выполнить откат. Второй способ —использовать флажки возможностей и отключить некоторые из них, чтобы вернуться к заведомо рабочему состоянию. Дополнительные сведения о флажках возможностей приводятся в шаге 8 в этой статье.

Откат позволяет вернуться к известному рабочему состоянию в среде после обнаружения неудачного развертывания. Это необходимо планировать в самом начале. Прежде чем делать что-то с базой данных, создайте резервную копию. Убедитесь, что можно быстро развернуть предыдущую версию кода. Регулярно тестируйте процесс отката в тестовой или промежуточной средах.

Шаг 7. Добавьте мониторинг, сигналы тревоги и инструментарий

Команде DevOps необходимо отслеживать поведение запущенного приложения в каждой среде. Есть ли ошибки в журналах? Истекает ли время ожидания запросов к API? Происходят ли сбои в базах данных? Отслеживайте проблемы в каждом компоненте системы. Если в процессе наблюдения выявляется проблема, создайте заявку на устранение неполадки, чтобы кто-нибудь мог ее решить. В рамках решения напишите дополнительные тесты, которые могут выявить проблему.

Исправление ошибок

Отслеживание проблем и их решение — это часть работы по эксплуатации программного обеспечения в рабочей среде. Команда с культурой DevOps отвечает за работу программного обеспечения и берет на себя обязанности инженеров по техническому обеспечению надежности сайта (SRE). Проведите анализ первопричин проблемы, напишите тесты, чтобы ее выявить, устраните ее и убедитесь, что теперь тесты выполняются успешно. Этот процесс поначалу часто требует больших трудозатрат, но в долгосрочной перспективе оправдывает себя, поскольку сокращает технический долг и обеспечивает операционную гибкость.

Оптимизация производительности

После наладки базового мониторинга состояния следующим часто выполняемым шагом становится настройка производительности. Проанализируйте работу каждой части системы и оптимизируйте запаздывающие части. Как отмечал Кнут, «преждевременная оптимизация — корень зла». Не оптимизируйте производительность всего подряд. Позаботьтесь только о самых медленных и дорогостоящих частях. Выявить такие компоненты можно с помощью мониторинга.

Шаг 8. Используйте флажки возможностей, чтобы выполнять канареечное тестирование

Чтобы обеспечить возможность канареечного тестирования, оберните каждую новую функцию во флажок возможности со списком разрешенных, в который входят тестовые пользователи. Код новой функции будет выполняться только для пользователей из списка разрешенных после развертывания в среде. Дайте новой функции как следует поработать в одной среде, прежде чем переносить ее в другую. Пока новая функция используется в какой-либо области, следите за показателями, сигналами тревоги и другими признаками, чтобы выявить проблемы. В частности, обратите внимание на рост количества новых заявок на устранение неполадок.

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

Заключение


Проведите ретроспективу проекта по переносу первого компонента в DevOps. Определите болевые точки — этапы, оказавшиеся проблемными или сложными. Внесите в план решения по устранению этих болевых точек, а затем переходите ко второму компоненту.

Использование подхода DevOps для вывода компонента в рабочую среду поначалу может быть связано со значительным объемом работы, но впоследствии это приносит плоды. После того завершения подготовительной работы реализация второго компонента должна быть проще. Когда имеются инструменты, технологии понятны, а команда обучена работать в стиле DevOps, можно использовать для второго компонента тот же процесс, что и для первого, немного его изменив.

Чтобы начать свой путь в DevOps, рекомендуем попробовать Atlassian Open DevOps —комплексный открытый пакет инструментов, содержащий все необходимое для разработки и эксплуатации программного обеспечения с возможностью интегрировать дополнительные инструменты по мере роста ваших потребностей.

Warren Marusiak
Warren Marusiak

Warren is a Canadian developer from Vancouver, BC with over 10 years of experience. He came to Atlassian from AWS in January of 2021.


Поделитесь этой статьей
Следующая тема

Рекомендуемые статьи

Добавьте эти ресурсы в закладки, чтобы изучить типы команд DevOps или получать регулярные обновления по DevOps в Atlassian.

Рисунок: DevOps

Сообщество DevOps

Рисунок: DevOps

Образовательные программы DevOps

Рисунок: карта

Начните работу бесплатно

Подпишитесь на информационную рассылку по DevOps

Thank you for signing up