DevOps tools от Microsoft

    Вступление

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

    Что такое DevOps?

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



    Методология DevOps довольно молодая — появилась в 2007 г. и развилась в сообществе IT-профессионалов, что обусловило ее практическую направленность.

    Когда и как используют DevOps?

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


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



    Для ускорения взаимодействия команд Development и Operations используют средства автоматизации. Мы можем автоматизировать:
    • Управление релизами.
    • Мониторинг установленных приложений и доставку команде разработчиков отзывов о работе установленного приложения.


    Далее будут описаны средства автоматизации, предлагаемые Microsoft.

    Управление релизами с помощью Microsoft Release Management (Development to Operations)

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

    В такой ситуации решение — использование единой автоматизированной системы для всех вовлеченных в процесс развертывания. И Microsoft Release Management — как раз такая система.



    Возможности Microsoft Release Management

    Главная функция Microsoft Release Management — автоматизация развертывания приложения через цепь тестовых окружений на продакшн.
    Основной объект системы — Release Template, описание шагов, которые нужно пройти для развертывания релиза. Release Template создается через графический интерфейс WPF-клиента. Чтобы создать Release Template, нужно определить набор виртуальных машин и добавить для каждой набор действий по развертыванию. Эти наборы действий можно копировать между виртуальными машинами.



    Установка на каждое окружение может быть одобрена или отклонена. Можно назначить ответственного за каждый этап установки.



    Но это еще не всё, что может Microsoft Release Management. Система предоставляет:
    • Большой набор действий по установке. Microsoft Release Management умеет работать с файлами, с реестром, с IIS, выполнять SQL-скрипты, устанавливать Reporting Services, Windows Services, манипулировать виртуальными машинами Windows Azure, запускать тесты с помощью Microsoft Test Manager.
    • Управление файлами конфигурации. Config-файлы можно параметризовать и подставлять нужные значения параметров для каждого окружения.
    • Возможность отката установки. Можно определить последовательность действий, откатывающих установку. Откат запускается автоматически при сбое в процессе установки.
    • Интеграцию с TFS. Релиз можно запустить автоматически по завершению билда в TFS.


    Мониторинг и предоставление информации о работающих приложениях(Operations to Development)

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

    Microsoft System Center 2012 Operations Manager

    Microsoft Operations Manager — часть линейки продуктов Microsoft System Center. Microsoft Operations Manager позволяет следить за несколькими приложениями через одну консоль и легко посылать информацию о произошедших событиях разработчикам.

    Мы можем таким образом отслеживать работу веб-приложений, разработанных на .NET, веб-страниц и веб-сервисов. Также последние версии Operations Manager позволяют мониторинг работы Windows-сервисов. Можно отслеживать сбои и проблемы с производительностью приложений и на стороне клиента, и на сервере.

    Однако это еще не самое интересное умение Operations Manager. Кроме возможностей мониторинга, приложение замечательно интеграцией с TFS. Собранную информацию о сбоях и проблемах с производительностью можно легко послать разработчикам — всего в один клик.



    После того как мы отослали информацию о событии разработчикам, в TFS автоматически создается Work Item, содержащий необходимые для отладки данные в виде IntelliTrace-файла.



    Используя информацию, предоставленную в Work Item, разработчики могут немедленно начать работу над правкой.

    Microsoft Monitoring Agent

    Microsoft Operations Manager — удобное, но тяжеловесное решение. Простую альтернативу предоставляет Microsoft Monitoring Agent. Используя это средство, можно локально отслеживать работу веб-приложений, разработанных на .NET.



    Microsoft Monitoring Agent собирает данные только о локально установленных приложениях, собранные данные сохраняются в IntelliTrace-файл, который можно послать разработчикам вручную. Управляется Microsoft Monitoring Agent с помощью скриптов PowerShell.

    Application Insights

    Application Insights — новое и перспективное средство мониторинга. Сейчас Application Insights предоставляется в превью-версии. Приложение доступно как часть Visual Studio Online. Application Insights предоставляет:

    1. Мониторинг доступности и времени отклика веб-приложения. Для этого достаточно только указать URL приложения или предоставить веб-тест Visual Studio.
    2. Мониторинг ошибок и производительности. Этот случай похож на описанные ранее варианты. На компьютер, где работают отслеживаемые приложения, устанавливается Microsoft Monitoring Agent, затем он связывается с Application Insights. После этого собираемая информация становится доступна в Application Insights. Интеграции с TFS нет, так что IntelliTrace-файл придется посылать разработчикам вручную.
    3. Анализ действий пользователя. Application Insights умеет отслеживать, с какой частотой происходят события в приложении (например, загрузка того или иного экрана). Эта опция доступна для следующих типов приложений:

    • Windows Phone 8.
    • Windows Store.
    • Веб-сервисов.
    • Веб-страниц.




    Автоматизация получения отзывов о приложении с помощью Microsoft Feedback Client

    С помощью Microsoft Feedback Client разработчики могут запрашивать и получать отзыв о работающем приложении от пользователей. Запрос на отзыв разработчики создают через Team Web Access и посылается по Email.



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




    Полученный отзыв сохраняется в TFS и может быть присоединён к Work Item.



    Автор: Александр Попов, .NET-разработчик.
    DataArt
    175,00
    Технологический консалтинг и разработка ПО
    Поделиться публикацией

    Похожие публикации

    Комментарии 11

      +1
      Как-то все сумбурно и без конкретики.
      Можно небольшой пример?
      Например скрипт, который ставит на виртуалку Windows 8.1 RUS, устанавовает на нее VisualStudio 2013 и собирает проект из git, ставя все зависимости?
        +2
        (но зачем?)

        Вообще же, предлагаемые инструменты на это не рассчитаны. Они предполагают, что вы уже собрали проект, и у вас есть готовый релиз.
          0
          Тогда это только Ops-часть от DevOps.
            0

            Это зависит от вашего понимание DevOps.

              0
              Нет. На таком основании можно сказать про любой термин, придумав под него новые значения.
              DevOps имеет вполне очерченный смысл термина. Как минимум, могу поспорить на миллион долларов, в названии DevOps первые три буквы — Dev. Вам же это о чем-то говорит? :-)
                0
                DevOps имеет вполне очерченный смысл термина

                Какой?


                Как минимум, могу поспорить на миллион долларов, в названии DevOps первые три буквы — Dev. Вам же это о чем-то говорит?

                Говорит. О том, что разработчики принимают участие в развертывании и поддержке. Если инструментарий позволяет разработчику выкатить продукт, и возвращает фидбек напрямую разработчику же — это и есть DevOps.

                  0
                  Вы знаете, я каждый день прихожу на работу и вижу десятки «девопсов», которые сидят и автоматизируют бардак разработчиков. Они называют все свои джобы с префиксом CI — таким образом это становится continuous integration.
                  Они ничего общего с девопсом не имеют.

                  Тем временем мне на почту сыпятся десятки статей в неделю с названиями «10 лучших инструментов DevOps» или «таблица DevOps инструментов».
                  Люди, которые это пишут, равно как наши «девопсы» в компании свято убеждены — если ты что-то заавтоматизировал, то ты сделал DevOps.

                  Мои поздравления, автоматизация не имеет вообще ничего общего с DevOps, равно как все эти приколюхи типа Jenkins или Docker, от которых в глазах рябит.

                  Давайте мы оставим buzz-word DevOps и вернемся к истокам этого значения?
                  DevOps, тот самый настоящий, который был изобретен бельгийцами 9 лет назад, — это решение проблемы взаимной ответственности в команде. Ключевое слово — взаимной. Если для этого нужна автоматизация — пожалуйста. Если для автоматизации нужен Jenkins — пожалуйста. Но это не во главе угла. Это даже не 10% работы по этой части.
                  Основная работа состоит в том, чтобы управлять взаимодействием.
                  1. Чтобы зависимости, которые ставились у разработчика, попадали в прод в обязательном порядке (будь то сделано через uDeploy или руками на листочке записали — неважно).
                  2. Чтобы код тестировался на всех стадиях в условиях приближенных к продовским и на чистых серверах, а не после многочисленных настроек разработчиком.
                  3. Чтобы разработчики могли планировать green/blue-деплоймент в проде на базах (это экстремально тяжелая задача, потому что две версии не работают с одной схемой)
                  4. Чтобы менеджеры могли планировать время траблшутинга проблемы (да да, это существует — Visible Ops)

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

                  Ага, собрали со своими депенденси, не пополнив список в pom.xml/requirements.txt/package.json [нужно подчеркнуть]. Со своими скриптами, которые никто не запустит в проде. И так далее.
                  Но да, разрабы получат «фидбек».
                  Конечно получат. А если Ops знают, где они живут, они и не только фидбек получат. Но когда им надоест получать, они придут к DevOps культуре, где фидбэков нет, потому что самим себе фидбэки не пишут.

                  Выдыхаю…
                    0
                    Я дам вам один пример, что такое реальный DevOps.

                    Когда я жил в России, то работал в Люксофте. У нас была база данных для приложения управления пожарными машинами в Москве. А наши разработчики писали это приложение. Я подумал, что было бы неплохо тестировать на базе продакшена. Поэтому при каждой сборке кода и деплое, скачивался бэкап прода за прошлый день и ставился на тестовое окружение.

                    Таким образом убил двух зайцев:
                    1. Каждый день тестировался вчерашний бэкап
                    2. Новый код работал с реальной базой в ее современном состоянии.

                    Вот это называется DevOps. Потому что были созданы условия, что накосячить невозможно. Накосячил в начале цепочки и то, что случится в конце случается сразу же в начале.
                      0
                      DevOps, тот самый настоящий, который был изобретен бельгийцами 9 лет назад, — это
                      реальный DevOps.
                      Вот это называется DevOps.

                      Я же говорю, все зависит от понимания термина. У нас с вами оно разное; бывает.

                        0
                        У ходожников бывает. Они так видят :-D
          0
          Релиз манагер выглядит неплохо но это он только так выглядит. Пока у него под капотом лежит Xaml, как и в tfs, а это такой один сплошной огромный геморрой. Может RM 2015 тоже будет без Xaml кто знает.

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

          Самое читаемое