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, а в 2015 году она была переименована в Visual Studio Team Services). Облачный сервис поддерживается облачной платформой 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 или экземплярах SQL Server. В базе данных конфигурации Oe для каждого экземпляра Azure DevOps хранятся метаданные коллекции проектов. Данные из баз данных коллекции проектов агрегируются в базу данных хранилища, которая денормализует данные при подготовке к загрузке в куб служб Analysis Services. Хранилище и куб позволяют создавать сложные отчеты о тенденциях и анализировать данные.
Azure DevOps может интегрироваться с существующей фермой SharePoint . Службы отчетов SQL Server поддерживаются для более сложных отчетов по хранилищу данных или кубу данных служб аналитики. Эти установки могут находиться в одной системе или в разных системах. В инфраструктуру также можно добавить серверы сборки, серверы управления лабораториями, серверы управления выпусками и прокси-серверы (чтобы снизить часть нагрузки на уровень приложений), машины тестирования и машины нагрузочного тестирования. [7] Для поддержки команд, которым требуется планирование корпоративных проектов, Azure DevOps также интегрируется с Microsoft Project Server , что позволяет управлять портфелем, ресурсами и отслеживанием проектов на уровне предприятия.
Microsoft предоставляет два автономных распространяемых API для подключения к Azure DevOps. Один из них — это пакет SDK для Java , другой — пакет SDK для .NET Framework . Эти API позволяют подключать клиентов к Azure DevOps. Поскольку Azure DevOps написан на сервис-ориентированной архитектуре , он может взаимодействовать практически с любым инструментом, который может вызывать веб-службу. Еще одним расширяемым механизмом является подписка на системные оповещения: например, оповещения об изменении рабочего элемента или завершении сборки. Существует около 20 предварительно настроенных оповещений, и команды могут настроить столько дополнительных оповещений, сколько необходимо. [8] При использовании в расширяемом сценарии эти оповещения можно отправлять в веб-службу, запуская действия по изменению или обновлению рабочих элементов (например, внедрение расширенных бизнес-правил или программную генерацию рабочих элементов на основе заданного сценария).
Хранилище данных также можно расширить за счет создания пользовательских адаптеров хранилища данных. [9] С появлением TFS 2012 для Team 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. Кроме того, если разработчики не хотят использовать подключаемый модуль Microsoft Team Explorer Everywhere для 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 и другие инструменты отчетности. В каждый готовый шаблон процесса входит набор отчетов для служб отчетности, которые охватывают информацию о сборке, результатах и ходе тестирования, управлении проектами, гибкие отчеты (обзор невыполненной работы, выработку релиза, выработку спринта и скорость), данные об ошибках и проблемах. Новые отчеты можно создавать с помощью построителя отчетов для 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 ( расширяемый язык разметки приложений ) хранились в системе управления версиями и могли редактироваться и управлять версиями непосредственно из системы управления версиями. В TFS 2013 эти файлы были удалены, чтобы устранить беспорядок и упростить процесс сборки. При желании шаблоны WF по-прежнему можно загружать, редактировать и сохранять в системе управления версиями, и TFS 2013 не нарушает существующие шаблоны процессов сборки TFS 2010 или 2012. Благодаря поддержке Git в TFS 2013 Team Build был улучшен и теперь позволяет автоматизировать создание проектов Git, а также проектов TFVC.
Рабочий процесс Windows управляет общим потоком процесса сборки, а Azure DevOps включает множество предварительно созданных действий рабочего процесса для управления распространенными задачами, выполняемыми во время сборки. [22] MSBuild — это язык разметки, который находится в файлах .proj (csproj для проектов C# и vbproj для проектов Visual Basic). Система сборки является расширяемой: пользователи могут создавать свои собственные действия рабочего процесса, внедрять MSBuild в процесс и выполнять внешние процессы. Характер рабочего процесса сборки обеспечивает неограниченную гибкость, но для достижения этой гибкости может потребоваться определенная работа. Были начаты совместные [23] проекты и проекты с открытым исходным кодом для создания поддерживаемых сообществом мероприятий по расширению возможностей Team Build.
Процесс сборки можно настроить для различных типов сборок, включая запланированные сборки, непрерывную интеграцию , закрытую регистрацию и скользящие сборки. Сборка с закрытой проверкой откладывает код, который проверяет разработчик, выполняет «получение последней версии» кода сервера и выполняет сборку. Если сборка прошла успешно, код возвращается от имени разработчика, отправившего его. Если сборка завершается неудачно, разработчик получает уведомление и может исправить код перед повторной попыткой возврата.
Сборки имеют политики хранения, чтобы они не накапливались, когда они не нужны (или сборки могут быть направлены на то, чтобы не создавать какие-либо сохраненные выходные данные), или выходные данные сборки могут быть заблокированы и сохранены навсегда. Новым в TFS 2013 является возможность проверять результаты сборки в системе контроля версий. Это было необходимое улучшение для поддержки автоматических сборок в службах Azure DevOps, где нет места для размещения сборок. В локальной версии выходные данные сборки можно настроить так, чтобы они попадали в любую доступную общую папку.
Процесс сборки в 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 перестроила управление выпусками для Visual Studio Team Services и локальной версии TFS с учетом новых изменений в обновлении 2 2015 года. Новая версия управления выпусками использует веб-браузер в качестве клиента и использует ту же архитектуру агента, что и Team Foundation Build. . Управление выпусками обеспечивает возможности DevOps для Azure DevOps.
Эта первая версия Team Foundation Server была выпущена 17 марта 2006 г. [26]