DevOps

Совет

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

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

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

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

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

Много лет назад это не было редкостью для процесса перемещения приложения из разработки в рабочую среду, чтобы занять месяц или еще больше. Компании выпустили программное обеспечение на 6-месячный или даже каждый год. Для получения идеи о том, что выпуски, которые были приемлемыми до вечно зеленых дней Windows 10, необходимо выглядеть не дальше, чем в Microsoft Windows 10. Пять лет прошло между 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 (TFVC) и любимую в отрасли Git. Запросы на вытягивание предоставляют способ включения социального кодирования путем содействия обсуждению изменений по мере их внесения.

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

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

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

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

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

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

GitHub Actions

Основанная в 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.ymlREADME. В любой архитектуре микрослужб высокая степень дисперсии между проектами делает массовые операции в отношении служб более сложными.

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 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 до i Телефон разработки.

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 Существует множество причин, по которым может потребоваться сделать это от определения выпуска для каждой ветви до включения скелета выпуска в шаблон проекта. К счастью, работа продолжается, чтобы перенести некоторые этапы поддержки в компонент сборки. Это будет известно как многоэтапная сборка, а первая версия доступна сейчас!

НазадДалее