DevOps

Подсказка

Это фрагмент из электронной книги «Архитектура облачных нативных приложений .NET для Azure», доступен на .NET Docs или как бесплатный загружаемый PDF-файл, который можно прочитать в автономном режиме.

Скачать в формате PDF

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

Например, две основные школы разработки веб-приложений: одностраничные приложения (SPAs) и серверные приложения. С одной стороны, пользовательский опыт, как правило, лучше с SPA, и объем трафика на веб-сервер можно свести к минимуму, что дает возможность разместить их, например, на статичном хостинге. С другой стороны, SPA, как правило, медленнее разрабатываются и сложнее тестировать. Какой из них правильный выбор? Ну, это зависит от вашей ситуации.

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

Много лет назад было обычным делом, когда процесс переноса приложения из разработки в рабочую среду занимал месяц или даже больше. Компании выпускали программное обеспечение каждые 6 месяцев или даже ежегодно. Чтобы получить представление о темпе выпусков, приемлемых до времени выпуска Windows 10, нужно обратить внимание на такие примеры, как Microsoft Windows. Пять лет прошло между Windows XP и Vista, еще три между Vista и Windows 7.

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

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

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

Рис. 10-1 — DevOps и микрослужбы.

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

Нет золотого молотка, когда дело доходит до DevOps. Никто не может продавать полное и комплексное решение для выпуска и эксплуатации высококачественных приложений. Это связано с тем, что каждое приложение дико отличается от всех остальных. Однако есть инструменты, которые могут сделать DevOps гораздо менее трудной задачей. Один из этих средств называется Azure DevOps.

Azure DevOps

Azure DevOps имеет длинную родословную. Он ведет свою историю с момента, когда Team Foundation Server впервые вышел в онлайн, переживая различные изменения названия: Visual Studio Online и Visual Studio Team Services. Однако на протяжении многих лет он стал гораздо значительнее, чем его предшественники.

Azure DevOps делится на пять основных компонентов:

Рис. 10-2 — Azure DevOps.

Azure Repos — управление исходным кодом, поддерживающее проверенную временем систему контроля версий Team Foundation Version Control (TFVC) и популярную в отрасли систему Git. Пулл-реквесты предоставляют возможность для социального кодирования, поддерживая обсуждение изменений по мере их внесения.

Azure Boards — предоставляет средство отслеживания проблем и рабочих элементов, которое стремится разрешить пользователям выбирать рабочие процессы, которые лучше всего работают для них. Он поставляется с рядом предварительно настроенных шаблонов, включая те, которые поддерживают стили разработки SCRUM и Kanban.

Azure Pipelines — система управления сборками и выпусками , которая поддерживает тесную интеграцию с Azure. Сборки можно запускать на различных платформах: от Windows до Linux и macOS. Агенты сборки могут быть подготовлены в облаке или локальной среде.

Планы тестирования Azure — Ни один специалист по обеспечению качества не останется без внимания благодаря управлению тестами и исследованиям путем тестирования, предлагаемым возможностями планов тестирования.

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

Подразделение верхнего уровня в Azure DevOps называется проектом. В каждом проекте можно включить и отключить различные компоненты, такие как Артефакты Azure. Каждый из этих компонентов предоставляет различные преимущества для облачных приложений. Наиболее полезными являются репозитории, доски и конвейеры. Если пользователи хотят управлять исходным кодом в другом стеке репозитория, например GitHub, но по-прежнему используют преимущества Azure Pipelines и других компонентов, это совершенно возможно.

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

Действия GitHub

Основанная в 2009 году GitHub — это широко популярный веб-репозиторий для размещения проектов, документации и кода. Многие крупные технологические компании, такие как Apple, Amazon, Google и основные корпорации, используют GitHub. GitHub использует распределенную систему управления версиями с открытым кодом с именем Git в качестве основы. Кроме основных функций, система добавляет свой собственный набор возможностей, включая отслеживание ошибок, запросы на добавление функций и на вытягивание изменений, управление задачами и вики-страницы для каждой базы кода.

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

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

Управление исходным кодом

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

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

Разделение кода для микрослужб в проекте Azure DevOps может быть немного сложнее.

Рис. 10-3 — один против многих репозиториев.

Репозиторий для каждой микрослужбы

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

1. Инструкции по созданию и обслуживанию приложения можно добавить в файл README в корне каждого репозитория. При просмотре репозиториев легко найти эти инструкции, уменьшая время запуска для разработчиков.
2. Каждая служба находится в логическом месте, легко найти, зная имя службы.
3. Сборки можно легко настроить так, чтобы они активировались только при изменении в репозитории владельца.
4. Количество изменений, поступающих в репозиторий, ограничено небольшим количеством разработчиков, работающих над проектом.
5. Безопасность легко настроить путем ограничения репозиториев, которыми разработчики имеют разрешения на чтение и запись.
6. Параметры уровня репозитория можно изменить командой владельцев с минимальным обсуждением с другими пользователями.

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

Однако этот подход не без проблем. Одна из самых проблем с развитием нашего времени — управление зависимостями. Рассмотрим количество файлов, составляющих средний node_modules каталог. Новая установка чего-то подобного create-react-app , скорее всего, принесет с собой тысячи пакетов. Вопрос о том, как управлять этими зависимостями, является трудным.

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

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

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

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

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

Альтернативой использованию многих репозиториев является объединение всего исходного кода в гигантский, все зная, один репозиторий.

Один репозиторий

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

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

При перемещении кода между проектами теперь проще сохранить историю изменений, так как файлы будут обнаружены как перемещенные, а не перезаписанные.

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

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

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

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

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

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

Стандартная структура каталогов

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

Рис. 10-4 — стандартная структура каталогов.

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

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

Управление задачами

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

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

Azure DevOps поставляется с рядом популярных шаблонов, предварительно настроенных. В самой базовой конфигурации все, что необходимо знать, это то, что находится в невыполненной работе, над чем работают люди, и что делается. Важно иметь такую прозрачность процесса создания программного обеспечения, чтобы можно было расставлять приоритеты в работе и сообщать клиенту о выполненных задачах. Конечно, немногие проекты программного обеспечения придерживаются процесса, так же простого, как to do, doing, и done. Это не займет много времени, прежде чем люди начнут добавлять шаги, такие как QA или Detailed Specification в процесс.

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

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

Рис. 10-5 . Задача в Azure DevOps.

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

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

Рис. 10-6 . Рабочий элемент в Azure DevOps.

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

Рис. 10-7 . Доска в Azure DevOps.

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

Конвейеры CI/CD

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

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

Рис. 10-8 — контрольный список.

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

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

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

Сборки Azure

Azure DevOps предоставляет набор средств для упрощения непрерывной интеграции и развертывания. Эти средства находятся в Azure Pipelines. Первым из них является Azure Builds, которое служит инструментом для запуска определений сборки на основе YAML в крупных масштабах. Пользователи могут использовать собственные компьютеры сборки (отлично, если сборка требует тщательно настроенной среды) или использовать компьютер из постоянно обновляемого пула размещенных виртуальных машин Azure. Эти размещенные агенты сборки поставляются с предустановленным широким спектром средств разработки, охватывающим не только .NET, но и Java, Python, а также разработку для iPhone.

DevOps включает широкий спектр готовых определений сборки, которые можно настроить для любой сборки. Определения сборки задаются в файле, который называется azure-pipelines.yml, и проверяются в репозитории, чтобы они могли подвергаться версионированию вместе с исходным кодом. Это упрощает внесение изменений в конвейер сборки в ветви, так как изменения можно проверить только в этой ветви. Пример azure-pipelines.yml создания веб-приложения ASP.NET на полной платформе показан на рис. 10-9.

name: $(rev:r)

variables:
  version: 9.2.0.$(Build.BuildNumber)
  solution: Portals.sln
  artifactName: drop
  buildPlatform: any cpu
  buildConfiguration: release

pool:
  name: Hosted VisualStudio
  demands:
  - msbuild
  - visualstudio
  - vstest

steps:
- task: NuGetToolInstaller@0
  displayName: 'Use NuGet 4.4.1'
  inputs:
    versionSpec: 4.4.1

- task: NuGetCommand@2
  displayName: 'NuGet restore'
  inputs:
    restoreSolution: '$(solution)'

- task: VSBuild@1
  displayName: 'Build solution'
  inputs:
    solution: '$(solution)'
    msbuildArgs: '-p:DeployOnBuild=true -p:WebPublishMethod=Package -p:PackageAsSingleFile=true -p:SkipInvalidConfigurations=true -p:PackageLocation="$(build.artifactstagingdirectory)\\"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: VSTest@2
  displayName: 'Test Assemblies'
  inputs:
    testAssemblyVer2: |
     **\$(buildConfiguration)\**\*test*.dll
     !**\obj\**
     !**\*testadapter.dll
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: CopyFiles@2
  displayName: 'Copy UI Test Files to: $(build.artifactstagingdirectory)'
  inputs:
    SourceFolder: UITests
    TargetFolder: '$(build.artifactstagingdirectory)/uitests'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact'
  inputs:
    PathtoPublish: '$(build.artifactstagingdirectory)'
    ArtifactName: '$(artifactName)'
  condition: succeededOrFailed()

Рис. 10-9 - пример "azure-pipelines.yml"

Это определение сборки использует ряд встроенных задач, которые позволяют создавать сборки так же просто, как создание набора Lego (проще, чем гигантский Сокол тысячелетия). Например, задача NuGet восстанавливает пакеты NuGet, а задача VSBuild вызывает средства сборки Visual Studio для выполнения фактической компиляции. Существуют сотни различных задач, доступных в Azure DevOps, и тысячи других, которые поддерживаются сообществом. Скорее всего, независимо от того, какие задачи сборки вы хотите запустить, кто-то уже разработал подобное решение.

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

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

Выпуски Azure DevOps

Сборки заботятся о компиляции программного обеспечения в отправляемый пакет, но артефакты по-прежнему должны быть отправлены в среду тестирования для завершения непрерывной доставки. Для этого Azure DevOps использует отдельное средство с именем "Выпуски". Средство "Выпуски" использует ту же библиотеку задач, которая была доступна для сборки, но представляет концепцию "этапов". Этап — это изолированная среда, в которую устанавливается пакет. Например, продукт может использовать разработку, QA и рабочую среду. Код постоянно поставляется в среду разработки, где автоматические тесты можно выполнять с ним. После успешного прохождения этих тестов выпуск переходит в тестовую среду QA для ручного тестирования. Наконец, код отправляется в рабочую среду, где она видна всем.

Рис. 10-10 . Конвейер выпуска

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

Каждый получает конвейер сборки

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

Выпуски версий

Одним из недостатков использования функциональности выпусков является то, что она не может быть определена в зафиксированном файле azure-pipelines.yml. Существует множество причин, по которым вам может понадобиться это сделать: от задания определений релиза для каждой отдельной ветви до включения шаблона релиза в ваш проект. К счастью, работа продолжается, чтобы перенести некоторые этапы поддержки в компонент сборки. Это будет известно как многоэтапная сборка, а первая версия доступна сейчас!

НазадДалее