Поделиться через

Жизненный цикл разработки

  • Статья

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

Стратегия репозитория

Рекомендации по проектированию

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

    • Git — это стандартная в отрасли система управления версиями. Это распределенная система управления версиями, где локальная копия кода является полной версией репозитория.

  • Общие сведения о структуре репозитория mono-repo и многорепо.

    • В структурах монореплиочного репозитория все исходные коды находятся в одном репозитории.
    • В многорепрепных структурах все проекты организованы в отдельные репозитории.

  • Выберите параметр видимости, соответствующий содержимому репозитория.

    • Доступ к общедоступным репозиториям можно получить анонимно.
    • Для частных репозиториев требуется предоставить пользователям доступ к репозиторию и войти в систему для доступа к службам.
    • Вы можете задать общедоступную и частную видимость для проектов Azure DevOps и репозиториев GitHub.

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

    • Вы можете задать разрешения репозитория для Azure DevOps и GitHub.

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

  • Azure обеспечивает поддержку IaC для целевых зон с помощью:

Рекомендации по проектированию

  • Используйте Git в качестве системы управления версиями.

  • Использование частных репозиториев при создании целевых зон Azure

  • Используйте общедоступные репозитории при совместном использовании неконфиденциальных сведений, таких как примеры автоматизации, общедоступная документация и материалы для совместной работы с открытым кодом.

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

Стратегия ветвления

Рекомендации по проектированию

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

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

  • Рекомендуется использовать разрешения ветви для управления возможностями пользователей.

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

  • Внедрение стратегии запроса на вытягивание позволяет контролировать изменения кода, объединенные в ветви.

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

Рекомендации по проектированию

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

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

  • Задайте разрешения для управления тем, кто может читать и обновлять код в ветви репозитория Git. Вы можете задать разрешения для отдельных пользователей и групп.

  • Задайте политики ветвей:

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

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

Автоматизированные сборки

Рекомендации по проектированию

  • Рассмотрите возможность реализации непрерывной интеграции (CI). CI включает объединение всего кода разработчика в центральную базу кода по обычному расписанию и автоматическое выполнение стандартных сборок и тестовых процессов.

  • Рекомендуется использовать триггеры CI:

    • Azure Repos Git. Можно настроить ветви, пути и теги в качестве триггеров для запуска сборки CI.
    • GitHub. Можно настроить триггеры ветвей, путей и тегов для запуска сборки CI.

  • Рассмотрите возможность включения модульных тестов IaC в процесс сборки для проверки синтаксиса.

    • Набор средств тестирования шаблонов ARM проверяет, соответствует ли шаблон рекомендациям.
    • Bicep linter проверяет файлы Bicep на наличие ошибок синтаксиса и нарушений рекомендаций.

  • Рассмотрите возможность включения модульных тестов в процесс сборки приложения. Просмотрите задачи, доступные для Azure DevOps Pipeline.

  • Используйте подключения службы Azure DevOps или секреты GitHub для управления подключениями к Azure. Каждое подключение должно иметь правильный привилегированный доступ к ресурсам Azure.

  • Рекомендуется использовать секреты Azure Key Vault для хранения конфиденциальных данных, таких как пароли, ключи API, сертификаты.

  • Агенты Azure DevOps могут размещаться самостоятельно или размещаться корпорацией Майкрософт.

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

Рекомендации по проектированию

  • Используйте CI для автоматизации сборки и тестирования кода каждый раз, когда член команды фиксирует изменения в элементе управления версиями.

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

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

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

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

Стратегия развертывания

Рекомендации по проектированию

  • Рекомендуется использовать непрерывную доставку (CD). Cd включает создание, тестирование, настройку и развертывание из сборки в среде.

  • Рассмотрите возможность использования сред. Среды позволяют нацеливать коллекцию ресурсов из задания доставки. Ниже приведены примеры распространенных имен сред:

    • Разработка
    • Тест
    • Контроль качества
    • Промежуточная
    • Производственный экземпляр

  • Рекомендуется использовать IaC в рамках стратегии для проверки и подтверждения предварительных изменений.

Рекомендации по проектированию

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

  • Используйте среды в рамках стратегии развертывания. Среды предоставляют такие преимущества:

    • Журнал развертывания
    • Трассировка фиксаций и рабочих элементов
    • Работоспособности диагностических ресурсов
    • Безопасность

  • Включите проверки предварительного развертывания IaC, чтобы просмотреть изменения и просмотреть сведения о том, создан ли ресурс, изменен или удален.

Стратегия отката

Рекомендации по проектированию

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

  • Если необходимо отменить изменения в Git, отменить изменения в фиксации, отменить изменения или сбросить ветвь в предыдущее состояние.

Рекомендации по проектированию

  • Используйте отмену изменений в Git, если необходимо вернуть изменения в зафиксированные файлы, отменить незафиксированные изменения или сбросить ветвь в предыдущее состояние.