Azure DevOps Server , ранее известный как Team Foundation Server ( TFS ) и Visual Studio Team System ( VSTS ), — это продукт Microsoft , который обеспечивает управление версиями (с помощью Team Foundation Version Control (TFVC) или Git ), создание отчетов, управление требованиями , управление проектами (как для гибкой разработки программного обеспечения , так и для каскадных команд ), автоматизированные сборки, возможности тестирования и управления выпусками . Он охватывает весь жизненный цикл приложения и обеспечивает возможности DevOps . [2] Azure DevOps можно использовать в качестве бэкэнда для многочисленных интегрированных сред разработки (IDE), но он адаптирован для Microsoft Visual Studio и Eclipse на всех платформах. [3]
Azure DevOps доступен в двух различных формах: локальной («Сервер») и онлайн («Сервисы»). [4] Последняя форма называется Azure DevOps Services (ранее Visual Studio Online, до переименования в Visual Studio Team Services в 2015 году). Облачная служба поддерживается облачной платформой Microsoft Azure . Она использует тот же код, что и локальная версия Azure DevOps, с небольшими изменениями, и реализует самые последние функции. Пользователь входит в систему, используя учетную запись Microsoft , чтобы настроить среду, создать проекты и добавить членов команды. Новые функции, разработанные в коротких циклах разработки, сначала добавляются в облачную версию. Эти функции переносятся в локальную версию как обновления примерно с трехмесячными интервалами. [5]
Azure DevOps построен на многоуровневой масштабируемой архитектуре. Основная структура состоит из уровня приложения, отвечающего за логику обработки и поддержку портала веб-приложений (называемого Team Web Access или TWA). Azure DevOps построен с использованием веб-служб Windows Communication Foundation . Они могут использоваться любым клиентом, хотя рекомендуется использовать клиентскую объектную модель. Уровень данных и уровень приложения могут существовать на одной машине.
Для поддержки масштабируемости уровень приложений может быть сбалансирован по нагрузке, а уровень данных может быть кластеризован. При использовании Microsoft SQL Server 2012 или более поздней версии поддерживаются отказоустойчивые кластеры и группы доступности AlwaysOn SQL Server, что позволяет выполнять географическую репликацию данных. [6] Основным контейнером является коллекция проектов. Коллекция проектов — это база данных, которая содержит группу проектов команды. Коллекция проектов — это еще один механизм масштабируемости, поскольку каждая коллекция может быть размещена на разных серверах SQL Server или экземплярах SQL Server. База данных конфигурации «Oe» для каждого экземпляра Azure DevOps хранит метаданные коллекции проектов. Данные из баз данных коллекций проектов объединяются в базу данных хранилища, которая денормализует данные при подготовке к загрузке в куб служб Analysis Services. Хранилище и куб позволяют создавать сложные отчеты о тенденциях и анализировать данные.
Azure DevOps может интегрироваться с существующей фермой SharePoint . SQL Server Reporting Services поддерживаются для более продвинутой отчетности по хранилищу данных или кубу данных Analysis Services. Эти установки могут быть в одной и той же системе или в разных системах. Серверы сборки, серверы управления лабораториями, серверы управления выпусками и прокси-серверы (для снижения нагрузки на уровень приложений), тестовые машины и машины для нагрузочного тестирования также могут быть добавлены в инфраструктуру. [7] Для поддержки групп, которым требуется планирование корпоративных проектов, Azure DevOps также интегрируется с Microsoft Project Server , что позволяет управлять портфелем на уровне предприятия, управлять ресурсами и отслеживать проекты.
Microsoft предоставляет два автономных перераспределенных API для подключения к Azure DevOps. Один из них — Java SDK, другой — .NET Framework SDK. Эти API позволяют подключать клиентов к Azure DevOps. Поскольку Azure DevOps написан на архитектуре, ориентированной на службы , он может взаимодействовать практически с любым инструментом, который может вызывать веб-службу. Еще один расширяемый механизм — подписка на системные оповещения: например, оповещения об изменении рабочего элемента или завершении сборки. Существует около 20 предварительно настроенных оповещений, и команды могут настраивать столько дополнительных оповещений, сколько необходимо. [8] При использовании в расширяемом сценарии эти оповещения могут отправляться в веб-службу, вызывая действия по изменению или обновлению рабочих элементов (например, внедрение расширенных бизнес-правил или программная генерация рабочих элементов на основе заданного сценария).
Хранилище данных также может быть расширено путем создания пользовательских адаптеров хранилища данных. [9] С появлением TFS 2012 для Team Web Access также могут быть созданы пользовательские надстройки, называемые расширениями Web Access .
Azure DevOps поддерживает Visual Studio 2010 и более поздние версии, Microsoft Test Manager (MTM) 2012 и 2013. Eclipse, более старые версии Visual Studio и другие среды можно подключить к Azure DevOps с помощью поставщика интеграции управления исходным кодом Microsoft (поставщик MSSCCI — произносится как «Мисс-Кей»). [10] Эти инструменты предоставляют полный доступ к функциям Azure DevOps.
Microsoft Excel и Microsoft Project также поддерживаются для управления рабочими элементами, что позволяет выполнять массовое обновление, массовый ввод и массовый экспорт рабочих элементов. Microsoft Project можно использовать для планирования работы при соблюдении каскадной методологии разработки программного обеспечения. И Excel, и Project поддерживают двунаправленные обновления данных. Это позволяет, например, менеджерам проектов помещать расписание в Project, импортировать эту работу в Azure DevOps, где разработчики обновляют работу, а затем расписание можно обновить без необходимости выполнения дополнительной работы менеджером проекта.
С Team Foundation Server 2012 Microsoft PowerPoint также был интегрирован с Azure DevOps для обеспечения быстрой разработки раскадровки, чтобы помочь в процессе управления требованиями. Интеграция обеспечивает расширяемые формы раскадровки, которые можно использовать для создания любого типа макета интерфейса, который затем можно анимировать с помощью встроенных функций PowerPoint. Затем эти раскадровки можно связать с рабочими элементами.
В попытке справиться с растущей географической разбросанностью команд и вовлекать заинтересованные стороны в процесс раньше и чаще, Microsoft добавила Feedback Client. [11] Этот инструмент позволяет пользователям тренировать приложение, комментировать то, что они видят, с помощью аудио и видео, захватывать экраны и предоставлять контекстную обратную связь команде разработчиков. Это обеспечивает конкретную обратную связь о функциях приложения с точки зрения пользователей, не требуя встреч и демонстрационных сеансов. Azure DevOps также предоставляет инструменты командной строки для сред Unix и Windows. Power Tools для TFS включают интеграцию оболочки Windows , которая позволяет пользователям проверять и извлекать файлы, добавлять файлы и выполнять другие основные задачи, щелкая правой кнопкой мыши по файлу или папке.
В основе Azure DevOps лежит «рабочий элемент». Рабочий элемент представляет собой нечто — это может быть работа, которую необходимо выполнить, риск для отслеживания, тестовый случай, ошибка или практически все, что может себе представить пользователь. Рабочие элементы определяются с помощью XML- документов и являются весьма расширяемыми. [12] Рабочие элементы объединяются в шаблон процесса , который содержит эти и другие фрагменты информации для предоставления среды разработки. Azure DevOps включает шаблоны процессов для Microsoft Solutions Framework для Agile, Scrum и CMMI. Команды могут использовать встроенный шаблон или один из множества шаблонов, доступных для использования, созданных третьими лицами. Шаблоны процессов можно настраивать с помощью редактора шаблонов процессов, который является частью Power Tools. [13]
Рабочие элементы могут быть связаны друг с другом с помощью различных отношений для создания иерархического дерева рабочих элементов или плоских отношений между рабочими элементами. Рабочие элементы также могут быть связаны с внешними артефактами, такими как веб-страницы, документы в файловом ресурсе или документы, хранящиеся в другом репозитории, таком как SharePoint. Рабочие элементы также могут быть связаны с исходным кодом, результатами сборки, результатами тестирования и определенными версиями элементов в системе управления исходным кодом.
Гибкость системы рабочих элементов позволяет Azure DevOps играть множество ролей от управления требованиями до отслеживания ошибок, отслеживания рисков и проблем, а также записи результатов проверок. Расширяемые возможности связывания гарантируют, что прослеживаемость от требований до исходного кода, тестовых случаев и результатов может быть достигнута и сообщена для целей аудита, а также исторического понимания изменений.
Azure DevOps поддерживает два различных типа управления исходным кодом : оригинальный механизм управления исходным кодом под названием Team Foundation Version Control (TFVC), а с выпуском TFS 2013 он поддерживает Git в качестве основного репозитория управления исходным кодом.
TFVC — это централизованная система управления версиями, позволяющая командам хранить любые типы артефактов в своем репозитории. [14] TFVC поддерживает два различных типа рабочих пространств при работе с клиентскими инструментами — серверные рабочие пространства и локальные рабочие пространства. [15] Серверные рабочие пространства позволяют разработчикам блокировать файлы для извлечения и уведомлять других разработчиков о том, что файлы редактируются. Частой жалобой на эту модель является то, что файлы на машине разработки помечаются как доступные только для чтения. Она также требует от разработчиков «переходить в автономный режим», когда сервер не может связаться. Локальные рабочие пространства были разработаны для того, чтобы избежать этих проблем. В сценарии локального рабочего пространства файлы не доступны только для чтения, и их не нужно извлекать перед работой над ними. Пока файлы находятся на локальной машине разработчика, неважно, подключен ли сервер или нет. Конфликты решаются во время регистрации .
Для повышения производительности удаленных клиентов Azure DevOps включает возможность установки прокси-серверов . [16] Прокси-серверы позволяют кэшировать содержимое исходного контроля на сайте, расположенном ближе к разработчикам, чтобы избежать длительных сетевых поездок и связанной с ними задержки. Проверка по-прежнему выполняется напрямую на уровне приложений Azure DevOps, поэтому прокси-сервер наиболее выгоден в сценариях чтения.
Как часть механизма управления исходным кодом, Azure DevOps поддерживает ряд функций, помогающих разработчикам гарантировать, что код, который проверяется, следует настраиваемым правилам. Этот механизм правил называется политикой проверки. Существует несколько готовых политик, таких как политика комментариев к набору изменений, которая не позволяет выполнять проверку, пока разработчик не введет комментарий проверки. Эти политики являются расширяемыми и могут использоваться для проверки всех аспектов кода, который проверяется, комментариев и связанных рабочих элементов. Azure DevOps также поддерживает функцию анализа кода, которая при независимом использовании известна как FxCop . Включение в Azure DevOps означает, что анализ может выполняться для кода, проверенного на сервере, и во время автоматизированных сборок.
Расширение Azure Repos для Visual Studio Code поддерживает TFVC. [17]
С выпуском TFS 2013 компания Microsoft добавила встроенную поддержку Git . Это не специфическая реализация Microsoft, а стандартная реализация на основе библиотеки libgit2 [18] . Это та же библиотека, которая поддерживает популярный GitHub , и код доступен бесплатно на GitHub. Поскольку компания Microsoft выбрала подход использования стандартной библиотеки, любой клиент Git теперь может использоваться с Azure DevOps нативно (другими словами, разработчики могут использовать свои любимые инструменты и никогда не устанавливать стандартные клиенты Azure DevOps). Это позволяет инструментам на любой платформе и любой IDE, поддерживающим Git, подключаться к Azure DevOps. Например, и Xcode , и Android Studio поддерживают подключаемые модули Git. Кроме того, если разработчики не хотят использовать подключаемый модуль Team Explorer Everywhere от Microsoft для Eclipse , они могут использовать eGit [19] для подключения к Azure DevOps.
Использование Git не исключает преимущества использования рабочего элемента или системы сборки Azure DevOps. При регистрации кода с помощью Git ссылка на идентификатор рабочего элемента в комментарии регистрации свяжет регистрацию с данным рабочим элементом. Аналогично, Team Build также будет строить проекты Git.
Одной из основных причин использования Azure DevOps в качестве репозитория Git является то, что он поддерживается SQL Server и обеспечивает ту же защиту, что и Team Foundation Version Control (TFVC) [ необходимо разъяснение ] . Это дает разработчикам возможность выбора типа проекта и стиля работы, который им подходит лучше всего.
Отчетность является основным компонентом Azure DevOps с момента его первоначального выпуска в 2005 году. Инфраструктура отчетности состоит из хранилища данных [20] (Tfs_Warehouse), которое представляет собой реляционную базу данных, и куба данных SQL Server Analysis Services. [21] Оба эти источника доступны для отчетности через SQL Server Reporting Services, если эта опция установлена. Поскольку это стандартные структуры базы данных и куба, любой инструмент, который может указывать на эти источники данных, может создавать отчеты из них. Сюда входят такие инструменты, как Cognos, Tableau, Excel и другие инструменты отчетности. В каждый готовый шаблон процесса включен набор отчетов для служб отчетности, которые охватывают информацию о сборке, результаты и ход тестирования, управление проектами, гибкие отчеты (обзор журнала невыполненных работ, выработка релиза, выработка спринта и скорость), данные об ошибках и проблемах. Новые отчеты можно создавать с помощью Report Builder для SSRS, а любые существующие отчеты можно изменять.
Более специализированная отчетность доступна для результатов нагрузочного теста. Эти данные доступны непосредственно в Visual Studio и могут быть экспортированы в Excel для детального анализа.
TFS 2013 представил новую функцию под названием «легкая отчетность», которая обеспечивает возможность создания отчетов в реальном времени на основе результатов запросов и которые не зависят от хранилища или куба. TFS 2012 (и далее в 2013) предлагает диаграммы выработки, скорости и CFD в реальном времени непосредственно в Team Web Access.
Team Build (до TFS 2015) — это приложение сервера сборки, входящее в состав Team Foundation Server. В состав Team Build входят два компонента — MSBuild и Windows Workflow Foundation . MSBuild — это декларативный язык XML, похожий на Apache Ant . WF был добавлен в процесс сборки, начиная с TFS 2010; до этого был доступен только MSBuild. Возможности сборки продолжали развиваться с каждым последующим выпуском Azure DevOps. В TFS 2010 и 2012 файлы шаблонов WF ( Extensible Application Markup Language ) хранились в системе управления исходным кодом и могли редактироваться и версионироваться непосредственно из системы управления исходным кодом. В TFS 2013 эти файлы были удалены, чтобы устранить беспорядок и упростить процесс сборки. Шаблоны WF по-прежнему можно загружать, редактировать и сохранять в системе управления исходным кодом, если это необходимо, и TFS 2013 не нарушает существующие шаблоны процесса сборки TFS 2010 или 2012. Благодаря поддержке Git в TFS 2013 Team Build был усовершенствован и теперь позволяет автоматизировать сборку проектов Git, а также проектов TFVC.
Windows Workflow управляет общим потоком процесса сборки, а Azure DevOps включает в себя множество предварительно созданных действий рабочего процесса для управления общими задачами, которые выполняются во время сборки. [22] MSBuild — это язык разметки, который находится в файлах .proj (csproj для проектов C# и vbproj для проектов Visual Basic). Система сборки расширяема, так как пользователи могут создавать свои собственные действия рабочего процесса, могут внедрять MSBuild в процесс и выполнять внешние процессы. Характер рабочего процесса сборки обеспечивает неограниченную гибкость, но для достижения этой гибкости может потребоваться определенная работа. Были начаты общие [23] и проекты с открытым исходным кодом для создания поддерживаемых сообществом действий с целью расширения возможностей Team Build.
Процесс сборки можно настроить для различных типов сборок, включая запланированные сборки, непрерывную интеграцию , контрольную проверку и непрерывные сборки. Контрольная проверка сборки откладывает код, который разработчик проверяет, выполняет «получение последних» для кода сервера и выполняет сборку. Если сборка проходит успешно, код проверяется от имени разработчика, который отправил код. Если сборка не удалась, разработчик получает уведомление и может исправить код перед попыткой повторной проверки.
Сборки имеют политики хранения, чтобы они не накапливались, когда не нужны (или сборки можно настроить так, чтобы они не создавали никаких сохраненных выходных данных), или выходные данные сборки можно заблокировать и сохранить навсегда. Новое в TFS 2013 — это возможность регистрировать результаты сборки в системе управления исходным кодом. Это было необходимым улучшением для поддержки автоматизированных сборок в Azure DevOps Services, где нет места для размещения сборок. В локальной версии выходные данные сборки можно настроить так, чтобы они попадали в любую доступную общую папку.
Процесс сборки в Azure DevOps также является частью механизма прослеживаемости, поскольку Team Build объединяет многие артефакты, которые создаются и хранятся в Azure DevOps. Предполагая, что разработчики связывают исходный код с рабочими элементами при регистрации, Team Build может сообщать об изменениях в каждой сборке — как об изменениях исходного кода, так и об изменениях рабочих элементов, а также о результатах тестирования (сюда входят результаты модульного тестирования , а также результаты автоматизированного функционального тестирования (CodedUI)). По мере устранения и интеграции ошибок и PBI в сборки рабочие элементы, которые отслеживают эти артефакты, автоматически обновляются, чтобы указать, в какой сборке они были успешно интегрированы. В сочетании с инструментами тестирования тестировщики получают интегрированное представление о том, какой код был изменен в каждой сборке, а также о том, какие ошибки, PBI и другая работа изменились от сборки к сборке.
Первоначально, в TFS 2015 и с Visual Studio Team Services (VSTS), Microsoft переосмыслила архитектуру для движка сборки, чтобы она была основана на кроссплатформенном дружественном приложении Node.js. В настоящее время поддерживаются агенты сборки Windows, Mac и Linux. Azure DevOps предоставляет возможности эластичной сборки через хостинг сборки в Microsoft Azure. [24]
В середине 2013 года Microsoft приобрела продукт под названием InRelease у InCycle Software. [25] InRelease был полностью включен в Team Foundation Server 2013. Эта возможность дополняла автоматизированные процессы сборки и тестирования, позволяя реализовать настоящее решение для непрерывного развертывания . Инструменты были переименованы в «Управление релизами» для TFS 2013. Возможности управления релизами дают командам возможность выполнять контролируемый рабочий процесс (предоставляемый Windows Workflow Foundation ), управляемый релизом в средах разработки, тестирования и производства, и предоставляют панели мониторинга для мониторинга хода выполнения одного или нескольких релизов.
Microsoft переделала Release Management для Visual Studio Team Services и локальной версии TFS с новыми изменениями в обновлении 2015 года. Новая версия Release Management использует веб-браузер в качестве клиента и опирается на ту же архитектуру агента, что и Team Foundation Build. Release Management обеспечивает возможности DevOps для Azure DevOps.
Первая версия Team Foundation Server была выпущена 17 марта 2006 года. [26]