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

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

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

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

Оценка базовых методик 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. Другие средства, такие как Crossplane , поддерживают ресурсы в нескольких облаках. Они позволяют использовать централизованные или общие диаграммы Helm в таких системах, как ACR, для более широкого спектра сценариев.

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

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

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

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

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

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

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

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

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

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

Используйте паттерн "всё как код"

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

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

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

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

Таким образом, у вас есть отдельный, защищенный централизованный репозиторий, в котором размещается ряд файлов, которые представляют собой подготовку и настройку (в этом случае все, от Bicep или Terraform, до диаграмм Helm и других собственных форматов Kubernetes). Операционная команда или другая группа администраторов управляет репозиторием, а разработчики (или системы) могут отправлять пулл-реквесты (PR). После объединения этих 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 и PR может включить самообслуживание из проверяемого источника данных.

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

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

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

• Каждая система была настроена для использования вашего поставщика удостоверений (например, Microsoft Entra ID) для единого входа (SSO).
• Группы поставщиков идентификации (например, группы 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. Учитывая, что разработчики и аналогичные роли в сфере операций, вероятно, уже знакомы с этим пользовательским опытом, ручные триггеры могут дополнить шаблон "всё как код", чтобы включить автоматизацию для действий (или заданий), которые либо не имеют естественного представления в виде файлов, либо должны быть полностью автоматизированы без необходимости в процессе создания pull request.

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

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

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

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

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

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

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

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

Часть облицованных путей

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

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

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

Подход	Примеры
Использование облачных виртуальных машин	Microsoft Dev Box — это полный вариант виртуализации рабочей станции Windows с встроенной интеграцией с программным обеспечением управления настольными компьютерами.
Использование локальных виртуальных машин	Hashicorp Vagrant является хорошим вариантом, и вы можете использовать HashiCorp Packer для создания образов виртуальных машин для него и Dev Box.

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

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

Подход	Примеры
Использование размещенных в облаке контейнеров	GitHub Codespaces — это облачная среда для контейнеров разработки, которая поддерживает интеграцию с VS Code, IntelliJ JetBrains и средствами на основе терминалов. Если эта или аналогичная служба не соответствует вашим потребностям, вы можете использовать поддержку SSH или удаленных туннелей в VS Code с контейнерами для разработки на удаленных виртуальных машинах Linux. Опция на основе туннеля, которая работает не только с клиентом, но и с веб-версией vscode.dev.
Использование локальных контейнеров	Если вы предпочитаете использовать локальные контейнеры разработки вместо этого или в дополнение к размещенной в облаке, контейнеры разработки имеют надежную поддержку в VS Code, поддержку в IntelliJ и других средствах и службах.
Использование облачных размещенных виртуальных машин	Если контейнеры слишком ограничены, поддержка SSH в таких средствах, как VS Code или JetBrains, например IntelliJ, позволяет напрямую подключаться к виртуальным машинам Linux, которыми вы управляете самостоятельно. В VS Code также есть вариант на основе туннеля .
Использование подсистемы Windows для Linux	Если ваши разработчики работают исключительно на Windows, подсистема Windows для Linux (WSL) — отличный способ для разработчиков локально разрабатывать под Linux. Вы можете экспортировать дистрибутив WSL для своей команды и поделиться им со всеми настроенными параметрами. Для облачного варианта облачные рабочие станции, такие как Microsoft Dev Box, также могут воспользоваться преимуществами WSL для целевой разработки Linux.

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

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

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

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

Оставаться в правильном положении и исправлять ошибки

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

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

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

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

Area	Сведения
Достаточное количество исходного кода для управления шаблонами приложений, пакетами SDK и средствами.	Включите код и конфигурацию для управления разработчиками в отношении рекомендуемых языков, моделей приложений и служб, API, пакетов SDK и архитектурных шаблонов. Обязательно включите код для распределенной трассировки, логирования и наблюдаемости с помощью предпочитаемых вами инструментов.
Скрипты сборки и развертывания	Предоставьте разработчикам общий способ активировать сборку и локальное или изолированное развертывание. Включите конфигурацию отладки в интегрированной среде разработки или редакторе для ваших инструментов на выбор, чтобы использовать их. Это важный способ избежать проблем с обслуживанием и предотвратить рассинхронизацию CI/CD. Если ваш движок шаблонов имеет жёсткие настройки, как Azure Developer CLI, возможно, уже существуют команды, которые можно легко использовать.
Конфигурация для CI/CD	Предоставьте рабочие процессы и конвейеры для создания и развертывания приложений на основе рекомендаций. Используйте централизованные, повторно используемые или шаблонные рабочие процессы или конвейеры, чтобы обеспечить их up-to-date. На самом деле, эти многократно используемые рабочие процессы / конвейеры могут служить стартовыми шаблонами сами по себе. Обязательно рассмотрите возможность вручную активировать эти рабочие процессы.
Инфраструктура в качестве ресурсов кода	Предоставьте рекомендуемые конфигурации IaC, включая ссылки на централизованно управляемые модули или элементы каталога, чтобы гарантировать, что любая настройка инфраструктуры следует лучшим практикам с самого начала. Эти ссылки также могут помочь командам оставаться на верном пути со временем. В сочетании с рабочими процессами и потоками можно также включить IaC или EaC для подготовки почти чего угодно.
Безопасность и политика в качестве ресурсов кода	Движение DevSecOps перенесло конфигурацию безопасности в код, что отлично подходит для шаблонов. Некоторые политики в виде кода также могут применяться на уровне приложения. Включите все, начиная с файлов, таких как CODEOWNERS и до параметров сканирования, например dependabot.yaml в GitHub Advanced Security. Предоставление запланированных рабочих процессов и запусков конвейера для сканирования, например, с помощью Defender for Cloud и тестовых запусков среды. Это важно для безопасности цепочки поставок и обязательно учитывать образы контейнеров в дополнение к пакетам приложений и коду. Эти шаги помогают командам разработчиков оставаться в порядке.
Наблюдаемость, мониторинг и ведение журнала	Часть упрощения самообслуживания заключается в предоставлении легкой видимости приложений после их развертывания. Помимо инфраструктуры среды выполнения, обязательно включите настройку для наблюдения и мониторинга. В большинстве случаев существует аспект IaC для настройки (например, развертывание агента, инструментирование), а в других случаях это может быть другой тип артефакта "конфигурации как кода" (например, панели мониторинга для Azure Application Insights). Наконец, обязательно включите пример кода для распределенной трассировки, ведения журнала и мониторинга с помощью инструментов по вашему выбору.
Настройка среды программирования	Включите файлы конфигурации для линтеров, форматировщиков, редакторов и интегрированных сред разработки. Включите сценарии установки вместе с файлами виртуализации рабочей области или рабочей станции, такими как devcontainer.json, devbox.yaml, ориентированные на разработчиков Dockerfiles, Docker Compose или Vagrantfiles.
Конфигурация теста	Предоставьте файлы конфигурации для модульного и более подробного тестирования с помощью предпочитаемых служб, таких как Microsoft Playwright Testing для пользовательского интерфейса или тестирования приложений Azure.
Настройка средства совместной работы	Если ваша система управления ошибками и системы управления версиями поддерживает шаблоны задач/ вопросов / PR в качестве кода, включите их также. В случаях, когда требуется дополнительная настройка, можно предоставить рабочий процесс или конвейер, который обновляет системы с помощью доступного интерфейса командной строки или API. Это также позволяет настроить другие средства совместной работы, такие как Microsoft Teams или Slack.

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

• Центр ресурсов Microsoft DevOps
• Платформа безопасной цепочки поставок контейнеров
• Базовая архитектура CI/CD с помощью Azure Pipelines
• Уточнение платформы приложений