Введение в DevOps с помощью Azure DevOps

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

В этой статье представлены концепции и терминология DevOps, затем представлены все функции и службы, доступные в наборе служб Azure DevOps от Microsoft, и каждая служба связана с концепциями культуры DevOps.

Начнем с определения понятия “DevOps”. DevOps – это культура, цель которой – изменить способ сотрудничества разработчиков и ИТ-персонала для создания программного обеспечения. Культура DevOps позволяет команде разработчиков программного обеспечения лучше реагировать на требования бизнеса, повышать уверенность в поставляемом программном обеспечении и быстро развертывать высококачественное программное обеспечение.

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

Планирование

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

Разработка

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

Доставка

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

Непрерывная доставка – это процесс, в ходе которого код собирается, тестируется и развертывается в одном или нескольких окружениях. Развертывание и тестирование в нескольких средах повышает качество. Весь процесс доставки масштабируется, повторяется и контролируется с помощью автоматизации. CD производит результаты, которые можно развернуть. Такие активы, как исполняемые файлы, файлы конфигурации и даже инфраструктура, могут быть включены в результаты CD. Команды используют такие инструменты, как Terraform, Bicep или шаблоны ARM для развертывания инфраструктуры повторяемым и надежным способом. Эти инструменты позволяют командам DevOps создавать и разрушать инфраструктуру с помощью кода, так называемую инфраструктуру как код (IaC). Системы мониторинга и оповещения работают постоянно, обеспечивая видимость всего процесса CD.

Операционная

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

Что такое Azure DevOps?

Как только компания принимает культуру DevOps, ей необходим набор инструментов для реализации принципов Agile по созданию высококачественного программного обеспечения. Именно здесь и пригодится набор услуг Azure DevOps от Microsoft. Azure DevOps предоставляет инструменты для каждого этапа ALM, включая планирование, разработку, доставку и эксплуатацию. Вы можете выбрать, сколько сервисов Azure DevOps внедрить – от одного до всех. Службы, доступные в Azure DevOps, показаны на рисунке ниже.

Azure DevOps доступен в двух вариантах: Azure DevOps Server и Azure DevOps Services. Azure DevOps Server – это самостоятельная, локальная установка Azure DevOps. Эта версия имеет те же функции, что и облачное предложение Azure DevOps Services, но при этом вы несете ответственность за безопасность, конфигурацию и все остальные обязанности по поддержке программного обеспечения в вашем центре обработки данных. Организации могут выбрать Azure DevOps Server, поскольку требования соответствия или безопасности требуют хранения данных в своем центре обработки данных. Интеграция с другими локальными службами, такими как SQL Server Analysis Server, является еще одним примером выбора локальной версии. Эти случаи использования являются исключительными. Большинство разработчиков выберут Azure DevOps Services.

Azure DevOps Services

Azure DevOps Services – это облачное предложение программного обеспечения как услуги (SaaS). Версия SaaS является частью облачной платформы Microsoft Azure. Она обладает всеми преимуществами предложения SaaS, включая доступность 24×7, автоматические обновления и безопасность Azure AD. Azure DevOps Services не требует дополнительной настройки. Приступить к работе можно быстро и легко, используя учетную запись Microsoft для регистрации, создания организации (домена), проекта и добавления нового пользователя.

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

Организация

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

Каждая организация имеет свой собственный URL в виде https://dev.azure.com/<Organization Name> и получает свой собственный набор ресурсов бесплатного уровня (подробнее об этих ресурсах мы расскажем чуть позже), включая:

  • Задания для выполнения CI/CD конвейера
  • Инструменты для отслеживания рабочих элементов, дефектов с использованием Kanban или Scrum
  • Неограниченное количество личных Git-репозиториев
  • 5 бесплатных пользователей (базовый)
  • 2 ГБ хранилища артефактов

Организации могут быть созданы с помощью Azure Active Directory (Azure AD) или учетной записи Microsoft. Используемая учетная запись влияет на модель безопасности организации. Используйте учетную запись MS, если вам не нужно проходить аутентификацию в Azure AD. Для более строгого контроля создайте организацию, используя учетную запись Azure AD. Это ограничивает доступ к организации только теми пользователями AD, которые являются членами этого каталога. Удаление пользователя из AD удаляет его/ее доступ к организации. Это обеспечивает более высокий уровень безопасности, поскольку Azure AD управляется администратором и может контролироваться в масштабах всей компании. Пользователей можно администрировать с помощью групп Azure AD, что еще больше упрощает контроль доступа.

Проекты

Следующим уровнем в иерархии является проект. Проект Azure DevOps – это группа служб и функций, доступных через веб-портал или клиент IDE, например Visual Studio. Когда вы создаете свою организацию, для вас создается проект по умолчанию.

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

Проект может быть доступен для публики или для частной группы. Выбор контроля версий в раскрывающемся списке Advanced определяет тип хранилища контроля исходных текстов. Есть два варианта, Git и Team Foundation Version Control. Большинство команд выберут Git. В раскрывающемся списке Процесс рабочего элемента можно выбрать модель процесса проекта. По этой ссылке вы найдете подробную информацию о моделях процессов. В таблице ниже приведена краткая информация о каждом доступном варианте.

Модель процесса Описание
Базовая Обеспечивает простейшую модель, которая отслеживает работу через проблемы, задачи и эпосы.
Agile Поддерживает методы планирования Agile, включая Scrum, и отслеживает деятельность по разработке и тестированию отдельно. Этот процесс отлично подходит, если вы хотите отслеживать пользовательские истории и (опционально) ошибки на доске Kanban, или отслеживать ошибки и задачи на доске задач.
Scrum Отслеживает работу с помощью элементов бэклога продукта (PBI) и ошибок на доске Kanban или на доске задач спринта. Этот процесс поддерживает методологию Scrum, определенную организацией Scrum.
Интеграция модели зрелости возможностей (CMMI) Поддерживает основу для совершенствования процесса и аудируемую запись решений. С помощью этого процесса можно отслеживать требования, запросы на изменения, риски и обзоры. Этот процесс поддерживает формальные мероприятия по управлению изменениями

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

Под иерархией проекта находится пять дочерних сервисов: Boards, Repos, Pipelines, Test Plans и Artifacts. Отдельный проект имеет свой собственный набор сервисов, которые изолированы от других проектов. В приведенном ниже списке описаны все отдельные службы, доступные в рамках проекта. Они могут отличаться в зависимости от опций, выбранных при создании проекта:

  • Доски: Инструменты для планирования и отслеживания рабочих элементов, дефектов кода и проблем с использованием методов Kanban и Scrum доступны в службе Azure Boards.
  • Repos: контроль исходных текстов обеспечивается службой Azure Repos.
  • Конвейеры: Конвейер сборки для функций непрерывной интеграции и непрерывного развертывания (CI/CD).
  • Планы тестирования: Инструменты для тестирования приложений, как ручного, так и автоматизированного.
  • Артефакты: Совместное использование интегрированных пакетов, таких как npm и NuGet, доступно с помощью службы Azure Artifacts.

Доски

Набор инструментов, доступных в категории Azure DevOps Boards, полезен для управления проектом на этапе планирования ALM. Инструменты предоставляют богатый набор возможностей, включая поддержку процессов Agile, Scrum и Kanban. Такие инструменты, как элементы рабочего процесса, бэклоги, спринты и настраиваемые приборные панели, используются для отслеживания и отчетности о ходе проекта. Эти инструменты разработаны для масштабирования по мере роста бизнеса и помогают команде планировать и управлять проектом на протяжении всего его жизненного цикла.

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

Команда DevOps устанавливает все рабочие элементы для проекта. Представления показывают рабочие элементы на различных стадиях разработки. Названия стадий настраиваются командой. По умолчанию используются стадии “Новый”, “Активный”, “Решенный” и “Закрытый”. На следующем снимке экрана показана ссылка на доски в моем примере проекта.

Ссылка Backlogs предоставляет визуальный метод назначения рабочих элементов на спринт. Используя бэклог, рабочие элементы можно перетащить на карты планирования и поместить в итерацию. Итерация – это имя по умолчанию для спринтов в Azure DevOps. Имя итерации можно настраивать. На приведенном ниже снимке экрана я переместил задачу “Создание конспекта поста” в первый спринт проекта.

Дополнительные функции планирования предоставляются ссылками Sprints, Queries и Delivery Plans. Каждый инструмент предоставляет функциональность для управления проектом. Например, элементы, перемещенные в итерацию планирования, видны по ссылке Спринты. Это представление позволяет командам отслеживать статус рабочих элементов в конкретном спринте.

Repos

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

Azure DevOps предлагает набор инструментов контроля версий Repos. Эти инструменты позволяют командам DevOps сотрудничать при разработке с использованием бесплатных публичных и частных репозиториев. Как упоминалось выше, Azure Repos предоставляет две системы контроля версий на выбор: Git и TFVC. В основном команды решают использовать Git, поскольку это децентрализованная система контроля исходных текстов, и в будущем она будет привлекать больше всего внимания со стороны Microsoft. Она также обеспечивает наибольшую гибкость и интегрируется практически со всеми инструментами в экосистеме разработчика. Проект может содержать неограниченное количество Git-репо.

Azure DevOps Repos предлагает огромное количество функциональных возможностей. Ниже приведены некоторые из наиболее важных функций.

  • Кодом можно делиться с помощью командной строки, VS Code или Visual Studio, а также других IDE.
  • Проверки кода выполняются вместе с запросами на перенос, чтобы убедиться, что изменения собираются без ошибок и проходят тесты перед объединением в основную ветку.
  • Рабочие элементы могут быть связаны с запросами на вытягивание для отслеживания проекта.
  • Политики и разрешения можно применять к отдельным веткам.
  • Функции Azure Functions можно использовать для создания пользовательских политик ветвей.

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

Эти параметры инициализируют репозиторий проекта. Можно создать пустой репозиторий или инициализировать репозиторий с существующим кодом путем загрузки. Также доступны опции для создания файла readme и файла .gitignore, который представляет собой файл, гарантирующий, что определенные файлы не будут отслеживаться Git’ом. Каждый язык разработки имеет свои собственные файлы, которые необходимо игнорировать. Параметры настройки позволяют создать файл .gitignore для конкретного языка.

Команды DevOps с опытом использования Git будут знакомы с концепциями контроля версий, которые реализует Azure Repos. Чтобы получить максимальную пользу от Repos, важно иметь базовое понимание концепций контроля версий git. В следующей таблице описаны некоторые из них. Более подробно о концепциях контроля версий можно прочитать здесь.

Концепция Описание
Клонирование Клонирование с локального компьютера создает полную рабочую копию репозитория на локальной рабочей станции. Изменения, внесенные в локальный репозиторий, могут быть перенесены в удаленный репозиторий в Azure DevOps.
Коммит Коммит – это набор связанных изменений кода, внесенных в ваш локальный репозиторий. Эти изменения могут быть вытеснены или откачены как набор.
Ветвь Ветви хранят историю фиксаций и изолируют изменения кода от основной ветви. Ветви изолированы, поэтому фиксация изменений в одной ветви не влияет на другие ветви.
Pull Request Pull requests позволяют команде просматривать код и предоставлять отзывы об изменениях до того, как они будут объединены в ветку.
Вилка Вилка – это копия хранилища. Копия включает все файлы, коммиты и (опционально) ветки из удаленного хранилища. Файлы и ветки в форкнутом репозитории не разделяются между репозиториями. Чтобы объединить файлы с вилкой обратно в основную ветку, требуется запрос на исправление.

Репозиторий Azure DevOps имеет ветку по умолчанию с именем “main” или “master”. Ветвь по умолчанию должна быть защищена от кода, который не собирается должным образом. В качестве лучшей практики установите политику ветки, которая требует, чтобы все слияния в ветку по умолчанию выполнялись с помощью запроса на притяжение (PR). Такая политика дает два преимущества. Во-первых, она предотвращает изменения непосредственно в основной ветви. Это помогает обеспечить качество кода, требуя проведения проверки кода перед слиянием изменений в основную ветвь. Во-вторых, PR заставляет чистую сборку объединенного кода перед его слиянием. Стратегии разветвления и выпуска – важные понятия, которые необходимо понимать. Чтобы узнать больше, смотрите статью “Принять стратегию ветвления в Git”. Ветвями и PR можно управлять с помощью ссылок Branches и Pull requests, соответственно.

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

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

Конвейер

Как уже говорилось на этапе доставки, CI/CD играет важную роль в организации DevOps. Сервис Pipelines помогает командам настраивать и управлять CI/CD для своих проектов. Возможность интегрировать код, над которым работает множество разработчиков, и развертывать релизы с помощью автоматизации является краеугольным камнем в обеспечении качественного продукта. Pipelines отличается гибкостью, поскольку работает со многими языками и типами проектов. Сам конвейер – это код, состоящий из серии этапов, заданий и шагов, обычно написанных с использованием YAML. YAML – это человекочитаемый, простой для понимания язык для создания файлов конфигурации. Azure pipelines интегрируется с развертываниями Azure, может создавать различные платформы (Windows, Linux или Mac) и развертываться в нескольких средах. Azure pipelines бесплатна для публичных проектов. Для частных проектов Azure предоставляет 30 часов работы конвейеров бесплатно в месяц.

Создание нового трубопровода осуществляется по ссылке “Трубопроводы”. При этом запускается мастер. Первым шагом мастера является указание местоположения репозитория исходного кода. На выбор предлагаются следующие варианты: Azure Git Repos, GitHub, Bitbucket, Subversion и другие. Затем выбирается репозиторий из этого местоположения. Третий шаг – инициализация конвейера, используя либо “стартовый конвейер”, либо существующий конвейер. Просмотр и сохранение конвейера – это последние шаги мастера. В результате создается файл с именем “azure-pipelines.yml”, который автоматически добавляется в репозиторий проекта. На следующем снимке экрана показан файл azure-pipelines.yml, созданный мастером стартового трубопровода.

Стартовый конвейер имитирует типичное приложение “hello world”. Запуск конвейера выводит строку “hello world”, как показано ниже.

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

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

Термин / компонент Описание
Агенты Агенты – это виртуальные машины с установленным программным обеспечением агентов, которые выполняют по одному заданию за раз.
Утверждения Утверждения – это набор проверок, которые необходимо пройти перед запуском развертывания.
Среда Набор ресурсов, т.е. виртуальных машин, контейнеров или других служб, которые используются для размещения приложения. После завершения сборки конвейер может развернуть изменения в одной или нескольких средах.
Этап Этап – это группа связанных заданий и шагов. Этапы выполняются последовательно и могут использовать условную логику для определения того, должен ли этап выполняться или быть пропущенным.
Задание Задание – это набор шагов, которые выполняются вместе на одном агенте.
Релиз Ветви хранят историю фиксаций и изолируют изменения кода от основной ветви. Ветви изолированы, поэтому фиксация изменений в одной ветви не влияет на другие ветви.
Шаг Шаг – это наиболее детальная задача в рамках конвейера. Это может быть как задача, так и сценарий.
Развертывание Набор шагов, которые выполняются последовательно.

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

Более подробную информацию о конвейерах можно найти здесь.

Планы тестирования

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

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

Существующие тесты доступны по ссылке Планы тестов. На приборной панели Test Plans перечислены все тесты и предоставлен портал для запуска и управления тестами.

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

Контекстное меню также предоставляет опции для запуска тестов и просмотра результатов тестирования.

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

Артефакты

Azure Artifacts предоставляет разработчикам механизм для обмена и потребления пакетов из различных каналов и публичных реестров. Команды DevOps могут использовать пакеты из известных менеджеров пакетов, таких как NuGet и npm, или создавать и делиться собственными пакетами. Совместное использование может быть ограничено одной командой, организацией или публично.

В зависимости от использования, команды могут нести расходы при использовании Артефактов. Счет за использование Артефактов выставляется на основе потребления, и до 2 Гигабайт памяти хранится бесплатно. После достижения лимита хранения в 2 Гигабайта новые артефакты не могут быть загружены. Для хранения более 2 Гигабайт необходимо создать биллинговый счет.

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

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

Преимущества/преимущества Azure DevOps

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

Альтернативы Azure DevOps

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

Название услуги Описание
GitHub Предоставляет инструменты для репозиториев Git, CI/CD, совместной работы и автоматизации.
AWS AWS предлагает услуги ala carte для команд DevOps. В их число входит AWS CodePipeline. CodePipeline – это сервис CI/CD для приложений и инфраструктуры. AWS CodeDeploy CodeDeploy – это сервис, автоматизирующий развертывание на AWS или в локальной инфраструктуре. AWS CodeCommit CodeCommit – это решение для контроля исходных текстов.
BitBucket Предоставляет командам единое место для репозиториев контроля исходных текстов, управления проектами и развертывания.
Jenkins Сервер автоматизации с открытым исходным кодом, который использует плагины для поддержки создания, развертывания и автоматизации любого проекта.

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

Оцените статью
Procodings.ru
Добавить комментарий