Ускорьте доставку программного обеспечения с помощью практики CI/CD

Непрерывная интеграция — это процесс создания и тестирования программного обеспечения каждый раз, когда член команды вносит изменения в центральный репозиторий, чтобы уменьшить проблемы интеграции и улучшить качество программного обеспечения. Непрерывная интеграция (CI) — это практика разработки, которая требует, чтобы разработчики интегрировали код в общий репозиторий несколько раз в день. Каждая регистрация затем проверяется автоматизированной сборкой, что позволяет командам обнаруживать проблемы на раннем этапе.

Первый набор инструментов CI/CD был разработан в конце 90-х для удовлетворения потребностей малых и средних команд DevOps. С тех пор непрерывная интеграция и доставка стали стандартом и поддерживаются несколькими платформами облачных сервисов. Команда Amazon AWS одной из первых осознала преимущества конвейеров CI/CD. Команда использовала Jenkins, чтобы помочь им создать свои основные компоненты платформы, а также разработать инструменты для внутреннего использования.

Вы хотите преобразовать свой процесс разработки программного обеспечения из сложного и медленного водопада в быстро развивающийся Agile или DevOps? Если да, то эта запись в блоге представляет собой простое введение в методы непрерывной интеграции (CI) и непрерывной доставки (CD) с Amazon Web Services (AWS).

Какие основные проблемы связаны с доставкой ПО?

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

Давайте посмотрим, как Amazon решил задачу создания и доставки программного обеспечения. Можно использовать AWS CodeStar, AWS CodeCommit, AWS CodeBuild, AWS CodeDeploy и AWS CodePipeline для реализации автоматизированного конвейера CI/CD для предоставления более надежного и безопасного программного обеспечения.

Специалисты DevOps могут использовать сервисы, предоставляемые AWS, для масштабирования и защиты своих программных сервисов. Можно безопасно хранить и применять контроль версий к исходному коду приложений. Можно использовать AWS CodeStar для быстрой организации сквозного рабочего процесса выпуска программного обеспечения с использованием этих сервисов. В существующей среде CodePipeline позволяет независимо интегрировать каждую службу с помощью существующих инструментов. Это высокодоступные и легко интегрируемые сервисы, доступ к которым можно получить через Консоль управления AWS, интерфейсы прикладного программирования (API) AWS и наборы инструментов разработки программного обеспечения (SDK) AWS, как и любой другой сервис AWS.

Понимание непрерывной интеграции и непрерывной доставки или развертывания

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

Непрерывная интеграция (CI) — это практика разработки программного обеспечения, при которой разработчики объединяют свои изменения кода в центральный репозиторий, после чего развертываются автоматические заявки и тесты. CI, как правило, относится к этапу сборки или интеграции процесса выпуска программного обеспечения и требует как компонента автоматизации (например, обучения частой интеграции). Ключевые цели CI — быстрее находить и устранять ошибки, улучшать качество программного обеспечения и сокращать время, затрачиваемое на проверку и выпуск новых обновлений программного обеспечения.

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

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

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

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

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

Непрерывная поставка делает решение о запуске бизнес-решением, а не техническим. Техническая проверка происходит при каждом коммите.

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

Насколько выгодна непрерывная доставка?

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

Автоматизация процесса выпуска программного обеспечения

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

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

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

CD улучшает качество кода

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

Обновления могут быть доставлены быстрее

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

Реализация непрерывной интеграции и непрерывной доставки

Чтобы помочь вам в реализации модели CI/CD, AWS сотрудничает с рядом сертифицированных партнеров DevOps, которые могут предоставить ресурсы и инструменты. Всегда можно перейти к облаку AWS и обратиться к AWS Building a Cloud Operating Model.

Непрерывная интеграция и непрерывная доставка — Путь

В конвейере CI/CD новый код отправляется на одном конце, тестируется на нескольких этапах (исходный код, сборка, подготовка и производство), а затем публикуется как готовый к эксплуатации код. Организации, которые плохо знакомы с CI/CD, могут подойти к этому конвейеру итеративно. Это означает, что нужно начинать с малого и повторять каждый этап, чтобы можно было понять и разработать свой код таким образом, чтобы способствовать их организационному росту.

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

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

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

Организация с поддержкой CI/CD — это путешествие, и на этом пути есть много пунктов назначения. Давайте посмотрим, как ваша организация может принять возможный путь, начиная с непрерывной интеграции и заканчивая уровнями непрерывной поставки.

Непрерывная интеграция — источник и сборка

Первый этап пути CI/CD включает в себя развитие непрерывной интеграции. Следует убедиться, что все разработчики регулярно передают свой код в центральный репозиторий (например, в CodeCommit или GitHub). Все изменения, наконец, объединяются в ветку выпуска для приложения. Ни один разработчик не должен держать код в изоляции. Если функциональная ветвь нужна в течение определенного периода времени, ее следует поддерживать в актуальном состоянии путем слияния с исходной ветвью как можно чаще. Частые коммиты и слияния с полными единицами работы рекомендуются команде для развития дисциплины и поощряются процессом. Любой разработчик, который рано и часто объединяет код, вероятно, будет иметь меньше проблем с интеграцией в конце.

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

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

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

Непрерывная поставка: создание рабочей среды

В последовательности конвейера развертывания/доставки после промежуточной среды следует производственная среда, которая также создается с использованием инфраструктуры как кода (laC).

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

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

Зрелость и не только

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

·       Дополнительные промежуточные среды для обеспечения конкретных тестов производительности, соответствия требованиям, безопасности и пользовательского интерфейса (UI).

·       Модульные тесты инфраструктуры и кода конфигурации вместе с кодом приложения

·       Интеграция с другими системами и процессами, такими как проверка кода, отслеживание проблем и уведомление о событиях.

·       Интеграция с миграцией схемы базы данных (если применимо)

·       Дополнительные шаги для аудита и утверждения бизнеса

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

Как должны быть организованы команды разработчиков для реализации среды CI/CD

AWS рекомендует организовать три группы разработчиков для реализации среды CI/CD: группу приложений, группу инфраструктуры и группу инструментов. Организация представляет собой набор базовых практик, которые были разработаны и применены в быстро развивающихся стартапах, крупных корпоративных организациях, а также в Amazon. В команде рекомендуется не более 10-12 человек, чтобы состоялись содержательные разговоры.

Команда приложения

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

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

Команда инфраструктуры

Эта команда отвечает за написание кода, который создает и настраивает инфраструктуру, необходимую для запуска приложения. Команда может использовать собственные инструменты AWS, включая AWS CloudFormation, или общие инструменты, такие как Chef, Puppet или Ansible. Группа инфраструктуры определяет, какие инструменты необходимы, и тесно сотрудничает с командой приложения. Та же команда может состоять всего из пары человек для небольшого приложения.

Эти команды обладают навыками использования таких методов предоставления инфраструктуры, как AWS CloudFormation или HashiCorp Terraform. Команда использует навыки настройки и автоматизации с помощью таких инструментов, как Chef, Ansible или Salt.

Команда инструментов

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

Эта команда имеет опыт построения и интеграции всех частей конвейера CI/CD. Это часто включает в себя создание репозиториев системы управления версиями, механизмов рабочих процессов, сред сборки, сред тестирования и репозиториев артефактов. Команды могут внедрить такое программное обеспечение, как AWS CodeDeploy, AWS CodeBuild и AWS CodeArtifact, а также Jenkins, GitHub, Artifactory, Teamcity и другие подобные инструменты. Это приводит к развитию команд DevOps, которые используют совокупность людей, процессов и инструментов для доставки программного обеспечения.

Как протестировать различные этапы непрерывной интеграции и непрерывной доставки

Три команды CI/CD (как предлагает AWS) должны включать тестирование в жизненный цикл разработки программного обеспечения на разных этапах конвейера CI/CD. В целом, тестирование следует начинать как можно раньше. Следующая пирамида тестирования представляет собой концепцию, представленную Майком Коном в книге [Успех с Agile] (https://www.amazon.com/Succeeding-Agile-Software-Development-Using/dp/0321579364/ref=sr_1_1?crid= 32NIW72NJZ3FK&dchild=1&keywords=успешный+с+agile&qid=1633036198&s=книги&sprefix=успешный+с+%2Caps%2C202&sr=1-1).

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

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

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

Этапы CI/CD

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

Настройка и запуск сборок

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

а)      Ant, Maven и Gradle для Java

б)      Сделать для C/C++

в)       Grunt для JavaScript

г)      Рейк для Ruby

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

Строительство

На этапе сборки инструменты будут принимать в качестве входных данных любые изменения в репозитории исходного кода, создавать программное обеспечение и запускать следующие типы тестов, которые публикуются:

а)      Модульное тестирование — тестирует определенный раздел кода, чтобы убедиться, что код выполняет то, что от него ожидается. Модульное тестирование выполняется разработчиками программного обеспечения на этапе разработки. На этом этапе могут применяться статический анализ кода, анализ потока данных, покрытие кода и другие процессы проверки программного обеспечения.

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

Постановка

На этом этапе создаются полные среды, которые отражают возможную производственную среду. Проводятся следующие тесты:

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

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

c)       Тестирование системы – это комплексное тестирование системы и проверка соответствия программного обеспечения бизнес-требованиям. Это может включать тестирование пользовательского интерфейса (UI), API и серверной логики, а также конечного состояния.

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

e)      Тестирование на соответствие — проверяет, соответствует ли изменение кода требованиям нефункциональной спецификации и/или правилам. Он определяет, внедряете ли вы определенные стандарты и соответствуете ли они им.

f)        Тестирование, приемлемое для пользователя. Это тестирование проверяет сквозной бизнес-процесс. Тестирование выполняется конечным пользователем в промежуточной среде и подтверждает, соответствует ли система требованиям спецификации требований. Как правило, на этом этапе клиенты используют методологии альфа- и бета-тестирования.

Производство

Наконец, после прохождения предыдущих тестов постановка повторяется в производственной среде. На этом этапе окончательный тест Canary можно дополнить разработкой нового кода только на небольшом подмножестве серверов или даже на одном сервере или в одном регионе AWS перед развертыванием кода во всей производственной среде. Особенности безопасного развертывания в рабочей среде описаны в разделе «Методы развертывания».

Давайте теперь посмотрим, как построить пайплайн для включения этих этапов и тестов.

Формирование трубопровода

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

Начните с минимально жизнеспособного конвейера для непрерывной интеграции

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

Ключевым компонентом является инструмент оркестрации непрерывной доставки. Чтобы построить этот конвейер, Amazon разработала AWS CodeStar.

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

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

Шаги AWS CodeStar и AWS CodePipeline напрямую сопоставляются с этапами, а именно. этапы исходного кода, сборки, подготовки и производства CI/CD. Хотя непрерывная доставка желательна, можно начать с простого двухэтапного конвейера, который взламывает исходный репозиторий и выполняет действие сборки:

Для AWS CodePipeline этап исходного кода может принимать входные данные от GitHub, AWS CodeCommit и Amazon Simple Storage Service (AWS S3). Автоматизация процесса сборки — важный первый шаг для внедрения непрерывной доставки и перехода к непрерывному развертыванию. Устранение участия человека в создании артефактов сборки снимает нагрузку с вашей команды, сводит к минимуму ошибки, связанные с ручной упаковкой, и позволяет вам чаще начинать упаковывать потребляемые артефакты.

AWS CodePipeline без проблем работает с AWS CodeBuild, полностью управляемым сервисом сборки, упрощая настройку этапа сборки в конвейере, который упаковывает ваш код и запускает модульные тесты. С помощью AWS CodeBuild можно упростить предоставление, управление или масштабирование собственных серверов сборки. AWS CodeBuild непрерывно масштабируется и обрабатывает несколько одновременно, поэтому ваши бренды не остаются в очереди. AWS CodePipeline также интегрируется с такими серверами сборки, как Jenkins, Solano CI и TeamCity.

Например, на этапе сборки параллельно выполняются три действия (объединенное тестирование, проверка стиля кода и сбор метрик кода). С помощью AWS CodeBuild эти этапы можно добавить в качестве новых проектов без дополнительных усилий по созданию или установке серверов сборки для обработки нагрузки.

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

AWS CodePipeline легко интегрируется с AWS CodeBuild, полностью управляемым сервисом сборки, позволяющим настроить этап сборки в конвейере, который упаковывает ваш код и запускает модульные тесты. С AWS CodeBuild не нужно предоставлять, управлять или масштабировать собственные серверы. AWS CodeBuild не позволяет предоставлять, управлять или масштабировать собственные встроенные серверы. AWS CodeBuild непрерывно масштабируется и одновременно обрабатывает несколько сборок за один раз, чтобы ваши сборки не оставались в очереди. AWS CodePipeline также интегрируется со встроенными серверами, такими как Jenkins, Solano CI и TeamCity.

Например, на следующем этапе сборки три действия (модульное тестирование, проверка стиля кода и сбор метрик кода) выполняются в тандеме с использованием AWS CodeBuild. Эти шаги могут быть добавлены как новые проекты без каких-либо дополнительных усилий по созданию или установке серверов сборки для управления и обработки нагрузки.

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

Конвейер непрерывной доставки

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

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

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

В соответствии с потребностями приложения некоторые этапы развертывания могут быть абстрагированы существующими сервисами AWS. Например, AWS CodePipleline напрямую интегрируется с AWS CodeDeploy, сервисом, который автоматизирует развертывание кода в экземплярах Amazon EC2 и экземплярах, работающих в локальной среде, AWS OpsWorks — сервисе управления конфигурацией, помогающем конечным пользователям управлять приложениями с помощью Chef, и в AWS Elastic Beanstalk. , сервис для развертывания и масштабирования веб-приложений и сервисов.

У AWS есть подробная документация по процессу внедрения и интеграции AWS CodeDeploy с вашей инфраструктурой и конвейером.

Как только ваша команда успешно автоматизирует развертывание приложения, этапы развертывания можно расширить с помощью различных тестов. Например, можно добавить другие готовые интеграции с такими службами, как Ghost Inspector, Runscope и другими, как показано ниже:

Добавление функциональных возможностей AWS Lambda

AWS CodeStar и AWS CodePipleline поддерживают интеграцию с AWS Lambda. Эта интеграция позволяет реализовать широкий набор задач, таких как создание пользовательских ресурсов в вашей среде, интеграция со сторонними системами (такими как Slack) и тщательное изучение следующих задач:

·       Внесение изменений в вашу среду путем применения или обновления шаблона AWS CloudFormation

·       Создание ресурсов по требованию на одном этапе конвейера с помощью AWS CloudFormation и их удаление на другом этапе

·       Развертывайте версии приложений с нулевым временем простоя в AWS Elastic Beanstalk с функцией Lambda, которая меняет местами значения записи канонического имени (CNAME).

·       Развертывание экземпляров Amazon EC2 Container Service (ECS) Docker

·       Резервное копирование ресурсов перед сборкой или развертыванием с помощью моментального снимка AMI.

·       Добавьте в конвейер интеграцию со сторонними продуктами, например отправку сообщений в клиент Internet Rely Chate (IRC).

Утверждение вручную: разрешения AWS Identity and Access Management (IAM)

Действие утверждения необходимо добавить на этап конвейера в точке, где требуется остановить обработку конвейера, чтобы кто-то с необходимыми разрешениями AWS Identity and Access Management (IAM) мог одобрить или отклонить действие.

После утверждения действий конвейерная обработка возобновляется. Если действие отклонено или если никто не одобрит или не отклонит действие в течение 7 дней после того, как конвейер достигнет действия и остановится, результат будет таким же, как сбой действия, и обработка конвейера не будет продолжена.

Изменения кода инфраструктуры развертывания в конвейере CI/CD

AWS CodePipeline позволяет пользователям выбирать AWS CloudFormation в качестве действия по развертыванию на любом этапе конвейера. Затем можно выбрать конкретные действия, которые AWS CloudFormation должен выполнять, например создание или удаление стеков, а также создание или выполнение наборов изменений. Стек — это концепция AWS CloudFormation, представляющая группу связанных ресурсов AWS. Может быть несколько способов предоставления инфраструктуры как кода. AWS CloudFormation — это комплексный инструмент, рекомендованный AWS как масштабируемое комплексное решение, которое может описать наиболее полный набор ресурсов AWS в виде кода. AWS рекомендует использовать AWS CloudFormation в проекте AWS CodePipeline для [отслеживания изменений и тестов инфраструктуры] (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/continuous-delivery-codepipeline.html).

CI/CD для бессерверных приложений

Можно использовать AWS CodeStar, AWS CodePipeline, AWS CodeBuild и AWS CloudFormation для создания конвейеров CI/CD для бессерверных приложений. Бессерверные приложения интегрируют управляемые сервисы, такие как Amazon Cognito, Amazon S3 и Amazon DynamoDB, с управляемым событиями сервисом, а также AWS Lambda для развертывания приложений таким образом, что не требуется управление серверами. Разработчики бессерверных приложений могут использовать комбинацию AWS CodePipeline, AWS CodeBuild и AWS CloudFormation для автоматизации создания, тестирования и развертывания разработчиков бессерверных приложений, а также могут развернуть комбинацию AWS CodePipeline, AWS CodeBuild и AWS CloudFormation. для автоматизации создания, тестирования и развертывания бессерверных приложений, выраженных в шаблонах, созданных с помощью AWS Serverless Application Model (SAM).

Можно также создать безопасные конвейеры CI/CD, соответствующие передовым практикам вашей организации, с помощью конвейеров моделей бессерверных приложений AWS (конвейеры AWS SAM). AWS SAM Pipelines — это новая функция интерфейса командной строки AWS SAM, которая позволяет за считанные минуты получить доступ к преимуществам CI/CD, таким как ускорение частоты развертывания, сокращение времени подготовки изменений и уменьшение ошибок развертывания. Конвейеры AWS SAM поставляются с набором шаблонов конвейеров по умолчанию для AWS CodeBuild/CodePipeline, которые соответствуют рекомендациям по развертыванию AWS.

Конвейеры для нескольких команд, филиалов и регионов AWS

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

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

Конвейерная интеграция с AWS CodeBuild

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

Благодаря преимуществам тесной интеграции с AWS CodeCommit, AWS CodePipeline, AWS CodePipeline и AWS CodeDeploy, а также действиями Git и CodePipeline Lambda инструмент CodeBuild отличается высокой гибкостью.

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

Можно просмотреть подробную историю каждой сборки с помощью панели инструментов CodeBuild. События сохраняются в виде файлов журналов Amazon CloudWatch.

Конвейерная интеграция с Jenkins

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

С AWS можно реализовать непрерывную доставку с помощью Jenkins с помощью плагина AWS Code Pipeline. Этот подключаемый модуль упрощает описание сложных рабочих процессов за счет использования предметно-ориентированного языка, похожего на Groovy, и может использоваться для организации сложных конвейеров. Функциональность плагина AWS Code Pipeline можно расширить за счет использования вспомогательных плагинов, таких как плагин Pipeline Stage View, который визуализирует текущий ход этапов, определенных в конвейере, или плагин Pipeline Multibranch, который строится из массива ветвей.

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

На следующем рисунке показан пример конвейера Jenkins с четырьмя определенными этапами, визуализированными с помощью подключаемого модуля Pipeline Stage View.

!)

Методы развертывания

Можно рассмотреть несколько стратегий и вариантов развертывания для развертывания новых версий программного обеспечения в процессе непрерывной доставки. Вот наиболее распространенные методы развертывания — все сразу — непрерывное, неизменяемое и синее/зеленое. AWS указал, какие методы поддерживаются AWS CodeDeploy и AWS Elastic Beanstalk.

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

Развертывание на месте (все сразу)

Все сразу (развертывание на месте) — это метод, который можно использовать для развертывания нового кода приложения на существующем парке серверов. Этот метод заменяет весь код одним действием развертывания. Это требует простоя, все серверы в парке обновляются одновременно. Нет необходимости обновлять существующие записи DNS. В случае неудачного развертывания единственный способ восстановить работу — повторно развернуть код на всех серверах.

В AWS Elastic Beanstalk это развертывание вызывается сразу и доступно для отдельных приложений и приложений с балансировкой нагрузки. В AWS CodeDeploy этот метод развертывания называется развертыванием на месте с конфигурацией развертывания AllAtOnce.

Последовательное развертывание

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

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

AWS Elastic Beanstalk придерживается схемы непрерывного развертывания с двумя вариантами развертывания: последовательное развертывание и последовательное развертывание с дополнительным пакетом. Эти параметры позволяют масштабировать приложение перед выводом серверов из эксплуатации, сохраняя полную мощность во время развертывания. AWS CodeDeploy реализует этот шаблон как вариант развертывания на месте с такими шаблонами, как OneAtTime и HalfAtATime.

Неизменяемые и синие/зеленые развертывания

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

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

AWS Elastic Beanstalk поддерживает неизменяемые или сине-зеленые шаблоны развертывания. AWS CodeDeploy также поддерживает сине-зеленый шаблон. Таким образом, сервисы AWS реализуют эти неизменные шаблоны.

Изменения в схеме базы данных

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

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

Схема базы данных до и после применения изменения должна рассматриваться как разные версии базы данных. Для управления версиями можно использовать такие инструменты, как Liquibase и Flyway.

Как правило, эти инструменты используют некоторые варианты следующих методов:

·       Добавьте в базу данных таблицу, в которой хранится версия базы данных.

·       Отслеживайте команды изменения базы данных и объединяйте их вместе в версионном наборе изменений. В случае с Liquibase эти изменения сохраняются в файлах XML. Flyway использует немного другой метод, когда наборы изменений обрабатываются как отдельные файлы SQL или иногда как отдельные классы Java для более сложных переходов.

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

Заворачивать

Практикуя непрерывную интеграцию и непрерывную доставку на AWS, конечные пользователи должны соблюдать некоторые из лучших практик:

а)      Относитесь к своей инфраструктуре как к коду.

б)      Используйте контроль версий для своего кода инфраструктуры.

в)       Использовать системы отслеживания ошибок или систем тикетов.

г)      Внесите изменения в соответствии с экспертными оценками, прежде чем применять их

e)      Создание шаблонов кода инфраструктуры и / дизайнов

f)        Тестируйте изменения инфраструктуры, такие как изменения кода.

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

Маркетологи могут постоянно внедрять системы сборки, такие как Maven или Gradle, в разных организациях и должны стандартизировать сборки.

Разработчики могут создавать модульные тесты для 100% охвата базы кода и должны гарантировать, что модульные тесты составляют 70% от общего тестирования по продолжительности, количеству и объему. Маркетологи должны убедиться, что модульные тесты актуальны и не игнорируются. Ошибки юнит-тестов должны быть исправлены и не должны быть обойдены.

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

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

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

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