Книга: Философия DevOps. Искусство управления IT

Концепции разработки, релиза и развертывания ПО

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

Контроль версий

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

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

Разработка через тестирование

При выполнении разработки через тестирование (Test Driven Development; TDD) разработчик начинает с написания проверяемого функционал-теста, применяемого для проверки функциональности нового кода. После этого создается сам код, затем начинается тестирование этого кода. Благодаря тестированию гарантируется безупречная работа новых функций, а также становится более очевидным назначение кода.

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

Развертывание приложений

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

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

Непрерывная интеграция

Непрерывная интеграция (Continuous Integration; CI) – это процесс интегрирования нового кода, написанного разработчиками, в основной код или ветку «мастер», осуществляемый в течение рабочего дня. Этот подход отличается от методики, в соответствии с которой разработчики работают с независимыми ветками неделями или месяцами, выполняя слияние кода в основную ветку только после полного завершения работы над проектом. Длительные периоды времени между слияниями приводят к тому, что в код вносится очень много изменений, что повышает вероятность появления ошибок. При работе с большими пакетами изменений гораздо труднее изолировать и идентифицировать фрагмент кода, который вызвал сбой. Если же используются небольшие наборы изменений, для которых часто выполняется слияние, поиск ошибок значительно упрощается. Постарайтесь избежать проблем, связанных с интеграцией, которые неизбежно появятся при слиянии больших наборов изменений.

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

Непрерывная доставка

Методология непрерывной доставки (Continuous Delivery; CD) представляет собой набор общих принципов по разработке программного обеспечения, которые позволяют часто создавать новые релизы программного обеспечения с привлечением автоматизированного тестирования и непрерывной интеграции. Эта методология тесно связана с непрерывной интеграцией и часто воспринимается как расширение непрерывной интеграции. Это позволяет убедиться в том, что новые изменения могут быть интегрированы без обращения к автоматическим тестам. В случае непрерывной доставки обеспечивается развертывание изменений.

Непрерывное развертывание

Непрерывное развертывание (Continuous deployment; CD) – это процесс развертывания изменений при разработке путем создания тестов и проверок, позволяющих свести риск ошибок к минимуму. В то время как непрерывная доставка позволяет гарантировать развертывание новых изменений, непрерывное развертывание означает, что выполняется развертывание изменений в производственном цикле.

Чем быстрее изменения программного обеспечения внедряются в производство, тем быстрее сотрудники увидят результаты своей работы. Благодаря «прозрачности» возрастает степень удовлетворенности работой, появляются позитивные эмоции, что, в свою очередь, способствует росту производительности. Также появляются возможности для быстрого обучения. Если в коде функции или в дизайне программы допущена серьезная ошибка, ее легче обнаружить и исправить путем просмотра недавно измененного рабочего контента.

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

Минимально жизнеспособный продукт

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

Минимально жизнеспособный продукт (Minimum Viable Product; MVP) – это прототип готового продукта, который можно проверить на соответствие требованиям с приложением минимальных усилий. Создание минимально жизнеспособного продукта целесообразно в тех случаях, когда высока вероятность внесения серьезных изменений в готовый продукт. При этом вы сэкономите значительный объем времени и усилий. В минимально жизнеспособном продукте отключены некоторые второстепенные функции или расширенные настройки, которые не нужны для оценки базовых концепций, либо делается упор на функциях, а не на дизайне или производительности. Подобно методологиям бережливой разработки и непрерывной доставки, минимально жизнеспособный продукт позволяет быстрее осуществлять рабочие итерации и улучшать продукт, уменьшая затраты и количество отходов.

Оглавление книги