Привет, Хабр! На первый взгляд название этой статьи может показаться вам странным: Java и Visual Studio – что у них общего? Зачем вообще Visual Studio, когда есть много других крутых инструментов для разработки на Java: Eclipse, NetBeans, IntelliJ IDEA и другие (холивар устраивать не будем).
Фактически Visual Studio теперь — это не просто среда разработки, а целое семейство продуктов, где Visual Studio IDE — лишь один из инструментов.
Под катом мы поговорим о Microsoft Visual Studio Team Services (VSTS).
Командные службы Microsoft Visual Studio — это облачная платформа DevOps, позволяющая гибко выстраивать DevOps-процессы непрерывной интеграции, сборки и развертывания (CI/CD).
Конечно, это невозможно сделать без поддержки контроля версий, встроенной системы отслеживания сумок, инструментов Agile-планирования и множества других возможностей для разработчиков разных «религий» и «мастей».
И, конечно же, Java-разработчики также найдут для себя полезный функционал DevOps для автоматизации своих решений.
О том, как эффективно использовать возможности VSTS, пойдет речь в нашей сегодняшней статье.
За 20 лет своего существования платформа Java сформировала вокруг себя богатую экосистему различных инструментов для создания, развертывания и тестирования приложений, которые Java-разработчики используют в повседневной практике, и многие из которых, по сути, уже стали отраслевым стандартом.
(Maven, Gradle, Ant, JUnit, JMeter и многие другие).
И, конечно же, у каждого разработчика или команды есть свои предпочтения при выборе инструментов: кто-то привык собирать проект с помощью Maven, а кто-то использует Gradle. Основная идея VSTS — предоставить разработчикам возможности, которые позволят им максимально гибко строить процессы CI/CD, используя привычные и знакомые инструменты OSS для сборки, развертывания и тестирования.
VSTS — это облачная платформа (в отличие от Сервер Microsoft Team Foundation , который развертывается локально), однако благодаря таким механизмам, как агенты сборки ( создавать агенты ), о чем мы поговорим ниже, сборка может производиться, например, on-premise (в вашем дата-центре), и, конечно же, на ваших виртуальных машинах в облаках (Azure, AWS, Google и других платформах) .
Возможности VSTS наиболее наглядно можно проиллюстрировать на простом примере Java-приложения с полным циклом сборки и развертывания.
Сразу оговорюсь, что полное и подробное пошаговое руководство я описывать не буду, Цель этой статьи — донести идею использования платформы VSTS для процессов Java DevOps. .
Для наших экспериментов вам понадобится учетная запись Microsoft Visual Studio Team Services. Вы можете получить это бесплатно используя свою учетную запись Microsoft или создав новую.
Итак, начнем наше увлекательное путешествие.
После регистрации нам необходимо создать проект. 
Указываем имя проекта, Git в качестве системы контроля версий и создаем новый проект. 
После создания проекта VSTS автоматически создает новый репозиторий Git и предлагает клонировать его на вашу производственную машину с помощью Git CLI или клонировать и открыть его в Java IDE, например: IntelliJ ИДЕЯ , также поддерживается Затмение .
Эти две IDE имеют плагины для интеграции с VSTS. 
К интеграции с IDE мы вернемся чуть позже в нашей статье, а пока просто клонируем код с GitHub. Нажимаем «Импортировать», указываем URL нашего репозитория GitHub ( https://github.com/easkerov/SampleJava.git ) и завершите импорт. В нашем случае репозиторий публичный и авторизация не нужна, но, конечно, можно использовать и приватные репозитории, указав необходимые учетные данные для доступа.
После завершения импорта откроется Файлы проводник для нашего репозитория, где вы можете добавлять и изменять артефакты приложения, переключаться между ветками или создавать новые.
Конечно, внутри одного проекта может быть несколько репозиториев, и для них можно настроить отдельные процессы CI/CD. И мы переходим к следующему этапу — созданию нашего приложения.
Для этого нам нужно создать Определение сборки (определение сборки) в нашем проекте.
VSTS имеет две важные концепции, связанные с настройкой процессов CI/CD. Этот Определение сборки И Определение выпуска .
Оба определения позволяют очень гибко строить процессы DevOps с помощью концепции задач.
Задачи могут быть разных типов: например, сборка проекта в Maven, выполнение Bash-скрипта, сборка Docker-контейнера, копирование файлов, развертывание приложения в контейнере Tomcat — все это примеры задач, из которых можно построить свой CI. /CD процессы.
При создании определения процесса сборки вы можете использовать готовый шаблон с заданным набором задач для конкретной задачи (например, сборка проекта в Maven/Gradle) или создать пустое определение сборки и определить набор задач в этот процесс самостоятельно.
В нашем случае мы выберем пустой шаблон и сами определим в нем задачи.
Порядок сборки и публикации нашего приложения будет следующим: первым делом устанавливаем все фронтенд-зависимости с помощью менеджера пакетов Bower, затем собираем наше приложение в Maven, в результате получаем война артефакт, который мы помещаем в Docker-контейнер с Tomcat и публикуем его в Docker Registry (в нашем случае это будет частный реестр на основе Реестр контейнеров Azure ).
Создав пустой шаблон, мы должны определить в нем необходимые задачи.
Каждый шаг нашего процесса CI — это отдельная задача.
Например, сборка Bower — это отдельная задача, которую нам нужно добавить в наш CI-конвейер и настроить.
Однако не все задачи доступны в VSTS «из коробки».
Например, в VSTS нет задачи Bower по умолчанию.
Но, к счастью, есть Торговая площадка Visual Studio , где Microsoft и сторонние разработчики публикуют расширения VSTS для интеграции с различными инструментами.
Установить эти расширения в VSTS крайне просто, достаточно найти необходимый модуль и установить его в свою среду, нажав «Установить» и указав свою учетную запись VSTS. 
Прежде чем мы определим конкретные задачи по созданию нашего приложения, нам необходимо указать, где будет создаваться наше приложение.
Мы можем собрать его с помощью механизма агентов сборки и выпуска/развертывания (Build/Release Agents), который есть в VSTS. Агенты могут быть двух типов: хостинг и частный .
Хостинг агенты самые простые в использовании, так как эти среды (ВМ) для сборки нам предоставляет сама платформа VSTS со всеми вытекающими преимуществами облачных вычислений (обслуживание, апгрейд и т.д.).
Более того, есть возможность выбора ОС для среды — это может быть Windows/Linux (последний пока находится в предварительной версии).
Но что делать, если у нас сложный случай, и среда, в которой мы будем собирать Java-приложение, требует определенной сложной настройки компонентов сборки (например, нам нужно определить приватный репозиторий Maven в настройки.
xml ).
В этом случае вы можете самостоятельно развернуть среду (на Linux/Windows/MacOS), установить Частный строительный агент и инициировать сборку приложения в нем из консоли VSTS. Более того, ваша собственная среда (ВМ) может быть развернута в облаках (Azure, Google, AWS) или в собственном дата-центре.
В нашем примере достаточно размещенного агента на компьютере с Linux. Это должно быть установлено явно в настройках процесса.
Далее мы строим CI-процесс и определяем задачи, которые будут в нем выполняться.
В нашем процессе CI будет 6 задач.
Давайте подробнее рассмотрим, из чего он будет состоять.
Перед началом сборки клонирование файлов из репозитория проекта Git в текущую среду (виртуальную машину) происходит автоматически, затем VSTS выполняет ту последовательность задач, которую мы указали в определении сборки.
Бауэр.
Установить.
Первая задача, Bower.Install, позволяет нам установить все внешние зависимости с помощью менеджера пакетов Bower. Для этого вам всего лишь нужно правильно настроить параметры задачи.
Как видно из скриншота выше, настройка проста и не требует особых комментариев (если только не нужно явно указывать --allow-корень ).
Maven.Build. На втором этапе мы создаем приложение, используя задачу Maven, и pom.xml артефакт из репозитория Git нашего приложения.
Помимо названия задачи и целей Maven, вы можете настроить параметры публикации JUnit-тестов, указать настройки JDK (версия, архитектура, настройки памяти и т. д.), а также подключить инструменты для статического анализа кода (SonarQube, Checkstyle, PMD, FindBugs) и код покрытия (JaCoCo, Cobertura и т. д.).
Докер.
ImageBuild. На третьем этапе мы собираем образ Docker, используя готовый Dockerfile из Git-репозитория нашего проекта.
Для этого шага используется задача Docker (которая будет использоваться на следующем шаге).
В качестве параметра Action выбираем Создайте образ и Докерфайл.
Дополнительно вы также можете указать параметры построения изображения.
Докер.
ImagePush. На четвертом этапе образ Docker, который мы собрали на предыдущем этапе, публикуется в частном реестре Docker; в нашем случае используется реестр Реестр контейнеров Azure (ACR) , но вы можете использовать другие частные/публичные реестры Docker (Docker Hub).
Обратите внимание, что здесь мы используем ту же задачу Docker, что и на предыдущем шаге, но для параметра Action в этом случае установлено значение Нажмите изображение .
В качестве имени изображения, которое мы собираем и публикуем, мы указываем выражение devopsdemoregistry.azurecr.io/javademo:v$(Build.BuildId) , где $(Build.BuildId) — переменная с идентификатором текущей сборки.
Мы собираемся развернуть приложение в облачном контейнерном сервисе.
Служба контейнеров Azure а в качестве системы управления контейнерами будем использовать известную Кубернетес .
YAML-манифест, описывающий развертывание и обслуживание объектов Kubernetes, был заранее подготовлен к публикации.
Шелл-скрипт. В артефакте YAML нам необходимо правильно определить образ Docker, который мы собираемся использовать при развертывании.
В случае каждой новой сборки мы помечаем каждый собранный образ Docker нашим приложением, используя Build ID в теге образа, соответственно при развертывании в процессе CD мы должны запустить процесс развертывания, используя образ с идентификатором сборки, который мы нуждаться.
Для этого в YAML-манифесте нужное изображение определяется путем подстановки значения параметра, и это происходит на шаге 5 с помощью Сценарий оболочки задачи и команды Linux СЭД .
Опубликовать Артефакт. Наконец, мы подошли к последнему, шестому шагу нашего процесса CI. Поскольку приложение работает в контейнере, образ Docker которого мы опубликовали в ACR на шаге 4, мы не будем публиковать какие-либо другие артефакты приложения.
Единственный артефакт, который нам нужен для процесса CD, — это модифицированный манифест YAML для развертывания в Kubernetes. Мы опубликуем его на этом этапе.
Опубликованный артефакт YAML будет использоваться далее в определении выпуска для развертывания приложения с помощью задачи Kubernetes. 
Наш процесс CI почти настроен, осталось лишь несколько дополнительных настроек и мы можем проверить процесс сборки.
Чтобы запускать процесс CI после каждого изменения в выбранной ветке исходного кода (например, master), необходимо включить опцию Непрерывная интеграция в свойствах определения сборки.
Кроме того, вы можете одновременно включить опцию сборки по расписанию.
Наше определение сборки готово, и сейчас самое время его протестировать.
Нажмите «Сохранить и поставить в очередь», после чего VSTS предложит нам подтвердить настройки сборки и наслаждаться процессом.
Как только сборка будет помещена в очередь, процессу будет присвоен идентификатор сборки, о котором нас уведомит VSTS. 
Перейдя по ссылке с Build ID, вы увидите процесс сборки и выполнения тех задач, которые мы определили ранее.
После завершения сборки вы можете просмотреть статистику тестирования, покрытие кода (если вы это настроили), журналы и, наконец, загрузить артефакты, опубликованные в результате сборки.
Мы публикуем наш образ Docker после каждой сборки в реестре контейнеров Azure и открываем Лазурный портал console для нашего реестра, мы действительно можем быть уверены, что наш образ опубликован.
Как только процесс CI будет завершен, мы готовы двигаться дальше и настроить процесс CD для нашего Java-приложения.
Для этого нам нужно создать новый Определение выпуска в нашем проекте.
Для приложения мы будем использовать пустое определение и добавлять в него необходимые задачи.
На следующем шаге VSTS предложит указать проект и определение сборки, на основе которых будет происходить наше развертывание.
Дополнительно включите опцию Непрерывное развертывание , а это значит, что развертывание начнется сразу после успешного завершения сборки (процесса CI) нашего приложения.
Для процесса компакт-диска вам необходимо выполнить некоторые настройки: дать осмысленное имя определению и среде компакт-диска и выбрать Агент выпуска который будет использоваться для развертывания.
В нашем случае мы продолжаем использовать Предварительный просмотр хостинга Linux .
Обратите внимание на концепцию среда в контексте Определение выпуска .
Среды — это логические объекты, которые определяют, где мы будем развертывать приложение.
В нашем простом примере это только среда разработки, но для промышленных решений сюда можно добавить среды Test, Q&A, Stage, Prod и т. д. Соответственно, каждая среда может иметь свой набор задач с разными алгоритмами развертывания в разных физических или виртуальных средах.
Кроме того, существует специальный механизм одобрения , что позволяет не начинать развертывание в следующей среде до тех пор, пока пользователь или группа пользователей с соответствующими правами не одобрит (или не откажет) продолжение процесса компакт-диска.
Например, развертывайте приложения в Prod после этапа только после одобрения одного или нескольких пользователей.
Теперь мы готовы добавить одну задачу для процесса CD — Задача Кубернетеса .
Однако по умолчанию этого расширения нет в каталоге VSTS, но оно опять же помогает Торговая площадка Visual Studio , о котором я уже упоминал выше, где его найти и установить? для вашей учетной записи VSTS. 
По сути, в задаче Kubernetes он используется кубектл CLI и используя команду применять наш YAML-манифест применяется и приложение развертывается в Kubernetes (помните, что мы собираемся опубликовать приложение в облачном контейнерном сервисе).
Служба контейнеров Azure ).
Процесс компакт-диска готов, и пришло время начать развертывание.
После запуска развертывания мы увидим в списке наш процесс, после чего сможем открыть его и отслеживать ход и результат. 
Как видно из результатов выполнения, процесс CD завершился успешно, а объекты развертывания и сервиса были успешно созданы в Kubernetes. 
Результаты развертывания можно проверить, проверив состояние модулей, развертываний и сервисов через CLI kubectl. И конечно, просто перейдя по ссылке в любимом браузере: http:// :8080 
Что еще полезно Java-разработчикам в VSTS?
VSTS поддерживает интеграцию с различными IDE, что позволяет разработчикам работать с платформой, практически не покидая среду разработки.То есть просматривать список поставленных перед вами задач, проводить code review, создавать Pull Requests и многое другое, не говоря уже об обычной работе с GIT-репозиторием.
В настоящее время поддерживается интеграция через плагины для популярных Java IDE: IntelliJ IDEA, Android Studio, Eclipse. Давайте на простом примере проверим, как это работает для IntelliJ IDEA IDE. Для этого вам необходимо установить плагин для VSTS. Где скачать и как установить описано здесь .
Предположим, что нам назначили новую задачу из бэклога в VSTS и предварительно создали новую ветку Git с именем домашняя страница (эту операцию можно выполнить в консоли VSTS).
Первым шагом является клонирование необходимого репозитория Git на рабочую машину.
Самый простой способ сделать это — использовать опцию «Клонировать» и выбрать IntelliJ IDEA. Специальный скрипт автоматически запустит IDE и процесс оформления заказа.
Например, отредактируем файл index.jsp , добавив новый элемент в список с заголовком Deployment и выполните commit и push. 
В окне Commit помимо основных настроек вы можете указать непосредственную задачу, с которой связан этот коммит. Далее мы делаем коммит и пуш.
Следующим шагом будет создание запроса на включение непосредственно в IntelliJ IDEA и указание основной ветки в качестве целевой ветки.
Мы также указываем наш последний коммит как изменения и создаем запрос на включение.
После создания запроса на включение его можно открыть и просмотреть в консоли VSTS в браузере.
Чтобы завершить запрос на включение, он должен быть одобрен.
Пользователи или группы пользователей с особыми правами в VSTS имеют доступ для утверждения.
После завершения процесса утверждения запрос на включение может быть завершен.
При необходимости вы можете удалить рабочую ветку домашней страницы, которую мы использовали для разработки определенного функционала приложения, и выполнить сквош-слияние.
Слияние изменений с основной веткой автоматически запускает процесс CI/CD по сборке, тестированию и развертыванию нашего приложения в службе контейнеров Azure. Переходим в раздел Сборка и выпуск , вы можете отслеживать ход сборки и развертывания.
После завершения процессов CI/CD откройте любимый браузер и наслаждайтесь изменениями в приложении.
Часто задаваемые вопросы
- Мой процесс CI построен на Jenkins, зачем мне VSTS? Jenkins и VSTS хорошо интегрируются и дополняют друг друга.
Например, вы можете продолжать использовать Jenkins Server для сборок CI (локально или в облаках) и использовать VSTS для процессов CD. Более того, у вас может быть сложный процесс CI, в котором сборка Jenkins является лишь частью определения сборки VSTS. Интеграция Jenkins с VSTS осуществляется с помощью специального Плагин Team Foundation Server модуль.
- А как насчет нагрузочного тестирования? Могу ли я использовать JMeter в VSTS? Да, Apache JMeter доступен в VSTS «из коробки».
Вы можете увидеть, как его использовать в документация .
- Могу ли я написать собственное расширение для VSTS? Да, можете, доступен специальный SDK для разработчиков.
Подробную информацию можно найти здесь: Напишите свое первое расширение для Visual Studio Team Services. .
- Где я могу найти дополнительные материалы и примеры по разработке Java в VSTS? Для Java-разработчиков существует отдельный портал с информацией, примерами, туториалами по теме использования VSTS в Java-разработке: http://java.visualstudio.com/ .
И конечно это доступно официальная документация VSTS .
Заключение
В этой статье был рассмотрен лишь простой пример использования VSTS в Java DevOps и некоторые аспекты подробно не обсуждались, например, интеграция с инструментами покрытия кода (JaCoCo, Cobertura) и статический анализ кода (SonarQube, PMD, CheckStyle и т. д.)..
Как я отмечал в начале статьи, самым большим преимуществом платформы VSTS для разработчиков является ее гибкость, универсальность, расширяемость и простота, и это девиз «Любой разработчик, любой язык, любая платформа» полностью себя оправдывает! Теги: #microsoft #Microsoft Azure #DevOps #java #cloud #Visual Studio #ci/cd #azure #Microsoft Developer #visual studio Team Services
-
Что Нового В Продуктах Ms Office 2010
19 Oct, 24 -
1С В Кризисе
19 Oct, 24 -
Кодируемость: Советы И Примеры
19 Oct, 24 -
Устаревшие Теги Mp3
19 Oct, 24
