Применение систем разработки программного обеспечения

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

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

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

Оценка базовых методик DevOps и DevSecOps

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

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

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

Создание нужных проложенных путей

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

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

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

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

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

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

Использование средств автоматизации разработчиков для улучшения самообслуживания для проложенных путей

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

Включение автоматической подготовки инфраструктуры приложений во время непрерывной доставки

Если вы еще не реализовали, проблемы, выявленные во время планирования, скорее всего, указывают на проблемы, которые могут помочь в непрерывной интеграции (CI) и непрерывной доставке (CD). В этом пространстве существуют такие продукты, как GitHub Actions, Azure DevOps, Jenkins, а также решения GitOps на основе по запросу, такие как Flux или Argo CD. Вы можете приступить к работе с этими разделами в центре ресурсов Microsoft DevOps.

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

Например, рассмотрим эти иллюстрации, показывающие два подхода, которые используют GitHub Actions для обновления инфраструктуры и развертывания в Служба Azure Kubernetes: один с использованием развертываний на основе push-уведомлений и одно развертывание на основе по запросу (GitOps).

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

Централизация IaC в каталоге или реестре для масштабирования и повышения безопасности

Чтобы управлять и масштабировать IaC в приложениях, необходимо централизованно публиковать артефакты IaC для повторного использования. Например, можно использовать модули Terraform в реестре, модулях Bicep, рецептах radius или Диаграммах Helm, хранящихся в собственном реестре артефактов OCI, например Реестр контейнеров Azure (ACR), DockerHub или каталог в средах развертывания Azure (ADE). Для GitOps и Kubernetes API кластера (и реализации, такие как CAPZ), позволяет управлять кластерами рабочих нагрузок Kubernetes, а пользовательские определения ресурсов, такие как оператор службы Azure, могут предоставлять добавленную поддержку для других видов ресурсов Azure, других инструментов, таких как межплановые ресурсы поддержки в нескольких облаках. Они позволяют использовать централизованные или распространенные диаграммы Helm в таких случаях, как ACR, для более широкого спектра сценариев.

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

Какой формат IaC вы выбираете, зависит от существующего набора навыков, уровня необходимого элемента управления и используемой модели приложения. Например , приложения контейнеров Azure (ACA) и недавний экспериментальный проект инкубации Radius OSS более уверены, чем напрямую с помощью Kubernetes, но также упрощают работу разработчика. Модуль обучения типов облачных служб поможет понять преимущества и минусы различных моделей. Независимо от того, что ссылки на централизованные и управляемые IaC, а не полные определения в исходном дереве имеют значительные преимущества.

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

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

Разработчики или конвейер CI/CD могут использовать Azure CLI или Azure Developer CLI для подготовки предварительно настроенной и управляемой инфраструктуры, даже не имея доступа к базовой подписке или удостоверениям, необходимым для этого. Независимо от того, используете ли вы что-то ADE или нет, ваша система непрерывной доставки может помочь вам безопасно и безопасно обновить инфраструктуру, разделив секреты и источник содержимого IaC от расположений разработчики не могут получить доступ или изменить их самостоятельно.

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

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

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

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

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

Использование всего в качестве шаблона кода

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

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

Применение шаблонов IaC к любой инфраструктуре

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

Таким образом, у вас есть отдельный, защищенный централизованный репозиторий, в котором размещается ряд файлов, которые представляют собой подготовку и настройку (в этом случае все, что происходит от Bicep, Terraform, до диаграмм Helm и других собственных форматов Kubernetes). Группа операций или другой набор администраторов владеет репозиторием, а разработчики (или системы) могут отправлять запросы на вытягивание. После объединения этих PR в основную ветвь этих администраторов те же средства CI/CD, которые используются во время разработки приложений, могут обработать изменения. Рассмотрим этот рисунок, который использует GitHub Actions и IaC и удостоверения развертывания, размещенные в средах развертывания Azure:

Если вы уже используете подход GitOps для развертывания приложений, вы также можете повторно использовать эти средства. Объединение таких средств, как Flux и оператор службы Azure, позволяет расширяться за пределами Kubernetes:

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

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

Отслеживание подготовленной инфраструктуры

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

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

Применение безопасности как кода и политики в качестве шаблонов кода

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

Многие различные продукты и проекты открытый код приняли этот подход, включая Политика Azure, агент open Policy, GitHub Advanced Security и GitHub CODEOWNERS, среди прочего. При выборе инфраструктуры приложений, служб или инструментов обязательно оцените, насколько хорошо они поддерживают эти шаблоны. Дополнительные сведения о уточнении приложения и управления см. в разделе "Уточнение платформы приложений".

Использование всего в качестве кода для собственных сценариев

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

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

Teams в качестве кода

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

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

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

В этом примере:

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

На высоком уровне вот как работает этот шаблон:

• В центральном, заблокированном репозитории Git есть набор файлов (обычно YAML), представляющих каждую абстрактную команду, связанное с членством пользователей и ролями пользователей. Владельцы или утверждающие изменения команды также могут храниться в этом месте (например, через CODEOWNERS). Ссылка на пользователя в этих файлах является поставщиком удостоверений, но этот репозиторий выступает в качестве источника истины для этих команд (но не пользователей).
• Все обновления этих файлов выполняются с помощью запросов на вытягивание. Это связывает беседы и связанных участников с запросом на фиксацию git для аудита.
• Потенциальные пользователи и отдельные пользователи могут создавать PR для добавления и удаления пользователей, а также потенциальных пользователей и других ролей, а другие роли могут создавать команды с помощью PR, которые с новым файлом команды из шаблона.
• Всякий раз, когда поставщик услуг объединяется в основной, система CI/CD, привязанная к репозиторию, обновляет систему поставщика удостоверений и все подчиненные системы соответствующим образом.

В частности, система CI/CD:

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

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

Ваши потребности и политики могут изменить особенности, но общий шаблон можно адаптировать к любому количеству вариантов. Все секреты, необходимые для интеграции с любыми подчиненными системами, сохраняются либо в системе CI/CD (например, в GitHub Actions,Azure Pipelines), либо в azure Key Vault.

Использование вручную или внешних триггерных рабочих процессов с параметризованными рабочими процессами

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

К счастью, большинство систем CI, включая GitHub Actions и Azure Pipelines, могут настроить рабочий процесс с входными данными, которые затем можно активировать вручную с помощью интерфейсов UIs или CLIs. Учитывая, что разработчики и связанные роли операций, скорее всего, уже знакомы с этими пользовательскими интерфейсами, триггеры вручную могут расширить все функции кода, чтобы включить автоматизацию для действий (или заданий), которые либо не имеют естественного представления файлов, либо должны быть полностью автоматизированы без необходимости в процессе pr.

Система CI может позволить вам активировать эти рабочие процессы или конвейеры из собственных пользовательских интерфейсов через API. Для GitHub Actions ключом для выполнения этой работы является REST API Actions для запуска рабочего процесса события отправки рабочего процесса. Триггеры Azure DevOps аналогичны, и вы также можете использовать API Конвейера Azure DevOps для выполнения. Скорее всего, вы увидите те же возможности в других продуктах. Независимо от того, активируется ли этот рабочий процесс вручную или через API, может поддерживать набор входных данных, добавив конфигурацию workflow_dispatch в файл YAML рабочего процесса. Например, это то, как наборы средств портала, такие как Backstage.io взаимодействуют с GitHub Actions.

Рабочий процесс или система заданий системы CI/CD, несомненно, отслеживает действия, сообщает о состоянии обратной работы и содержит подробные журналы, которые могут использовать как разработчики, так и операционные группы, чтобы увидеть, что произошло неправильно. Таким образом, он имеет одни и те же преимущества безопасности, аудита и видимости, что и все, что является шаблоном кода. Однако следует помнить, что любые действия, выполняемые этими рабочими процессами или конвейерами, выглядят как системное удостоверение (например, субъект-служба или управляемое удостоверение в идентификаторе Microsoft Entra) в подчиненных системах.

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

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

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

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

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

• В некоторых случаях для разработчика может потребоваться несколько недель, чтобы получить свой первый запрос на вытягивание. Это проблематичная область при передаче разработчиков между командами функций и проектами довольно часто (например, в матричных организациях), необходимо увеличить подрядчиков или на этапе найма.
• Несоответствие между разработчиками и системами CI может привести к частым проблемам "он работает на моем компьютере" даже для опытных участников команды.
• Экспериментирование и обновление платформ, время выполнения и другое программное обеспечение также могут нарушить существующие среды разработчика и привести к потере времени, пытаясь выяснить именно то, что пошло не так.
• Для потенциальных разработчиков проверки кода могут замедлить разработку, учитывая, что они могут потребовать изменения конфигурации для тестирования и отмены их после завершения проверки.
• Члены команды и операторы также должны тратить время на повышение связанных ролей за пределами разработки (операторы, QA, бизнес, спонсоры), чтобы помочь тестировать, увидеть ход выполнения, обучение бизнес-ролей и евангелизировать работу, выполняемую командой.

Часть проложенных путей

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

Замена рабочей станции и назначение Windows

Если вы используете Windows или хотите выполнить полную виртуализацию рабочих станций (клиентские инструменты и параметры ос узла в дополнение к определенным параметрам проекта), виртуальные машины обычно предоставляют лучшие функциональные возможности. Эти среды могут быть полезны для любой среды от разработки клиентов Windows до службы Windows или управления веб-приложениями .NET full framework.

Виртуализация рабочей области и назначение Linux

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

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

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

Для начала можно использовать что-то так простое, как репозиторий шаблонов GitHub, но если ваша организация следует шаблону monorepo , это может оказаться менее эффективным. Вы также можете создать шаблоны, которые помогают настроить то, что не связано напрямую с деревом источника приложения. Вместо этого можно использовать механизм шаблонов, например cookiecutter, Yeoman или что-то подобное интерфейс командной строки разработчика Azure (azd), который, помимо шаблонов и упрощенной установки CI/CD, также предоставляет удобный набор команд разработчика. Так как интерфейс командной строки разработчика Azure можно использовать для настройки среды во всех сценариях, он интегрируется с средами развертывания Azure, чтобы обеспечить улучшенную безопасность, интегрированную среду IaC, отслеживание среды, разделение проблем и упрощенную настройку cd.

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

Оставаться правым и получать право

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

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

Содержимое шаблона

Рекомендуется учитывать следующие области при создании шаблонов.

Связанный контент

• Центр ресурсов Microsoft DevOps
• Безопасность цепочки поставок контейнеров
• CI/CD для приложений AKS с помощью GitHub Actions и Gitflow