Справочная информация: Управление жизненным циклом приложений (ALM)

Прежде чем мы начнем, давайте кратко вспомним об управлении жизненным циклом приложений (ALM).

Управление жизненным циклом приложений — это управление жизненным циклом продуктов компьютерных программ. Он включает в себя управление требованиями, архитектуру программного обеспечения, компьютерное программирование, тестирование программного обеспечения, обслуживание программного обеспечения, управление изменениями, непрерывную интеграцию, управление проектами и управление выпусками. [Источник википедия.]

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

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

Введение: Azure DevOps

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

Azure DevOps, ранее известная как Visual Studio Team System (VSTS). Это помогает вам планировать свой проект, управлять исходным кодом в репозиториях, таких как Git, TFVC, Subversion, GitHub, и развертывать код через конвейерную систему CI/CD в облаке или в локальных ресурсах. Кроме того, он предоставляет совместную платформу для разработчиков, бизнес-пользователей и инженеров-испытателей, менеджеров проектов под одной крышей для отслеживания работы в режиме реального времени и быстрой доставки продукта.

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

Что делает Azure DevOps решением ALM?

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

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

Azure Reposподдерживает различные системы контроля версий, такие как Azure Git, общедоступный GitHub, GitHub Enterprise, собственный контроль версий Microsoft Team Foundation (TFVC), внешний Git. Вы можете выбрать любой из репозиториев на ваш выбор для разработки программного обеспечения и исходного кода. После завершения разработки разработчики могут создать запрос на вытягивание со своими изменениями, отправить его на проверку кода и принять участие в совместной среде разработки.

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

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

Azure Artifacts управляет вашими частными пакетами NuGet, npm, Maven в частном канале. Вы можете интегрировать этот фид в свою любимую IDE, например Visual Studio или Visual Studio Code, и восстанавливать пакеты из этого фида во время разработки. Кроме того, вы можете интегрировать этот фид в конвейер сборки и восстанавливать пакеты из этого частного репозитория. Azure Artifacts очень помогает, когда в приложении используется много общих общих пакетов, и вы хотите контролировать стандарты, версии этих сквозных атрибутов.

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

Кроме того, он поддерживает создание Wiki-страниц для проекта. Вики-страницы можно использовать для создания любых документов/руководств, имеющих отношение к текущему или завершенному проекту.

Azure DevOps в действии

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

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

  • Шаг 1. Клиент приходит с требованием.
  • Шаг 2. Бизнес-аналитики/владелец продукта анализируют требования и начинают документировать их на Досках Azure. Они начинают создавать Epic, Feature и пользовательские истории.
  • Шаг 3. Затем команда инженеров начинает оценивать работу и планировать эти пользовательские истории на спринт.
  • Шаг 3.1. Параллельно инженеры по тестированию начинают планирование тестирования в планах тестирования на основе критериев приемлемости пользовательских историй.
  • Шаг 4. После запуска спринта разработчики начинают выбирать пользовательские истории из бэклогов, созданных на этапе 2, и приступают к их реализации.
  • Шаг 5. После завершения разработки разработчики создают запрос на вытягивание и отправляют его на проверку кода. После удовлетворения рецензента кода разработчик фиксирует код в репозиториях Azure.
  • Шаг 6. Сборка запускается в конвейере сборки, как только код фиксируется в Azure Repos с помощью непрерывной интеграции (CI). Сборка CI получает последний код из репозиториев, создает их в агентах сборки, восстанавливает любые частные пакеты из настройки фида в Azure Artifacts. Он запускает модульные тесты, генерирует результат покрытия кода и, наконец, генерирует выходные данные сборки для развертывания. Если какой-либо из шагов, настроенных в конвейере сборки, завершается сбоем, вся фиксация отклоняется, и разработчики получают уведомление об ошибке сборки. Разработчик исправляет сборку и фиксирует ее еще раз, и сборка CI срабатывает автоматически.
  • Шаг 7. Выходные данные сборки необходимо перенести в среду развертывания. В Конвейере выпуска источником артефактов сборки являются выходные данные сборки CI предыдущего шага 6, назначением будут серверы, на которых необходимо развернуть эти артефакты. В этом примере артефакты развертываются в облачных службах приложений Azure и в базах данных SQL Azure для ТЕСТИРОВАНИЯ среды (шаг 7.1). Ворота или механизм утверждения могут быть установлены до того, как произойдет развертывание, это дает возможность утверждающим выбирать, какую сборку развертывать.
  • Шаг 8 Теперь, когда сборка развернута в среде TESTING, инженеры по тестированию начинают тестирование и проверку качества сборки. Они запускают набор ручных, автоматизированных и нагрузочных тестов, как и планировалось на этапе планирования (шаг 3.1) в Планах тестирования Azure. Если они обнаруживают какие-либо дефекты, они регистрируются в невыполненной работе Azure Boards и создают новую ошибку/проблему/наблюдение. Разработчик выбирает эти дефекты после того, как они запланированы и переданы в спринт, исправляет дефекты и фиксирует их в репозиториях Azure, что в конечном итоге запускает CI/CD в Azure Pipelines.
  • Шаг 9. Если инженеры-испытатели удовлетворены качеством сборки и предоставленными функциями, эта сборка переносится в среду верхнего уровня (шаг 9.1). В этом примере это среда UAT для тестирования бизнес-пользователями.
  • Шаг 10. Теперь бизнес-пользователи получают новую сборку в среде UAT со всеми функциями, запланированными на текущий спринт. Бизнес-пользователь начинает проверку сборки и функциональности в среде UAT.
  • Шаг 11. Если бизнес-пользователи обнаруживают какие-либо дефекты, они регистрируют их в журналах невыполненной работы Azure Boards как ошибку/наблюдение. Цикл разработки и сборки продолжается, как только эти дефекты планируются и возвращаются в спринт.
  • Шаг 12. Если бизнес-пользователи удовлетворены функциональностью и качеством сборки, сборка переводится в рабочую среду (шаг 12.1). Как только это будет запущено в производство, конечные пользователи начнут использовать систему. Если в рабочей среде возникает какая-либо проблема, она снова регистрируется в невыполненной работе Azure Boards как Инцидент/Ошибка/Проблема.

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

Заключительные слова, чтобы начать новое путешествие

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

  • Если вы хотите узнать больше о ценах, проверьте это.
  • Чтобы узнать больше об Azure DevOps, посмотрите это видео.

О... подождите, а пока вы можете начать работу со своей бесплатной учетной записью в Azure DevOps и приступить к изучению. Просто войдите на https://dev.azure.com под своей учетной записью Microsoft и начните работу с ALM в облаке с помощью Azure DevOps.

Первоначально опубликовано на subhankarsarkar.com 30 сентября 2018 г.