✖


Jump to content

Сервер Azure DevOps

(Перенаправлено с Team Foundation Server )
Сервер Azure DevOps
Разработчик(и) Майкрософт
Первоначальный выпуск 2005 г .; 19 лет назад ( 2005 )
Стабильная версия
2022 год / 6 декабря 2022 г .; 19 месяцев назад ( 06.12.2022 ) [1]
Операционная система Microsoft Windows
Тип Управление жизненным циклом приложений
Лицензия Пробная версия
Веб-сайт лазурный .microsoft .с /en-нас /услуги /девопс /сервер /  Edit this on Wikidata

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 в качестве основного репозитория контроля версий.

Контроль версий Team Foundation

[ редактировать ]

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. [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 ), выпускаемый в средах разработки, тестирования и производства, а также предоставляют информационные панели для мониторинга прогресс одного или нескольких выпусков.

Корпорация Майкрософт перестроила управление выпусками для Visual Studio Team Services и локальной версии TFS с учетом новых изменений в обновлении 2 2015 года. Новая версия управления выпусками использует веб-браузер в качестве клиента и использует ту же архитектуру агента, что и Team Foundation Build. . Управление выпусками обеспечивает возможности DevOps для Azure DevOps.

История

[ редактировать ]

Эта первая версия Team Foundation Server была выпущена 17 марта 2006 года. [26]

Название продукта Форма Год выпуска Номер версии [27] [28]
Team Foundation Server 2005 Локально 2006 8
Team Foundation Server 2008 Локально 2008 9
Team Foundation Server 2010 [29] Локально 2010 10
Предварительная версия службы Team Foundation Облако 2012
Team Foundation Server 2012 Локально 2012 11
Visual Studio онлайн [30] Облако 2013
Team Foundation Server 2013 Локально 2013 12
Team Foundation Server 2015 Локально 2015 14
Командные службы Visual Studio Облако 2015
Team Foundation Server 2017 Локально 2017 15
Team Foundation Server 2018 Локально 2017 16
Службы Azure DevOps [31] Облако 2018
Azure DevOps-сервер 2019 [32] Локально 2019 17
Azure DevOps Сервер 2020 Локально 2020 18
Azure DevOps Сервер 2022 [33] Локально 2022

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ «Сервер Azure DevOps 2022» . Документы Майкрософт . 14 ноября 2023 г.
  2. ^ «Управление жизненным циклом приложений с помощью Visual Studio и Team Foundation Server» . MSDN . Майкрософт. 2013 . Проверено 15 октября 2013 г.
  3. ^ «Повсеместное внедрение Team Explorer» . MSDN . Майкрософт. 28 апреля 2015 года . Проверено 26 мая 2017 г.
  4. ^ «Что такое Azure DevOps? Сервисы, примеры и лучшие практики» . codefresh.io .
  5. ^ «Новый выпуск Cadence начинается с обновления 2 для Visual Studio 2012» . 1105 СМИ. 2013 . Проверено 15 октября 2013 г.
  6. ^ «Улучшения доступности (движок базы данных)» . Майкрософт. 2012 . Проверено 17 октября 2013 г.
  7. ^ «Серверная архитектура Team Foundation» . Майкрософт. 2012 . Проверено 17 октября 2013 г.
  8. ^ «Установите оповещения и получайте уведомления при возникновении изменений» . Майкрософт. 2013 . Проверено 17 октября 2013 г.
  9. ^ «Как создать адаптер» . Майкрософт. 2008 год . Проверено 17 октября 2013 г.
  10. ^ «Поставщик Microsoft Visual Studio Team Foundation Server 2012 MSSCCI» . Майкрософт. 2012 . Проверено 17 октября 2013 г.
  11. ^ «Запросить и просмотреть обратную связь» . Майкрософт. 2012 . Проверено 17 октября 2013 г.
  12. ^ «Как настроить рабочие элементы и рабочие процессы TFS 2010» . Тед Густав. 2010. Архивировано из оригинала 19 октября 2013 г. Проверено 17 октября 2013 г.
  13. ^ «Электроинструменты Microsoft Visual Studio Team Foundation Server 2013» . Майкрософт. 2013 . Проверено 17 октября 2013 г.
  14. ^ «Контроль версий Team Foundation (TFVC)» . Azure DevOps. Документы Майкрософт . Проверено 23 сентября 2019 г.
  15. ^ «Рабочие области сервера и локальные рабочие области» . Фил Келли. 2013 . Проверено 17 октября 2013 г.
  16. ^ «Как: установить Team Foundation Proxy и настроить удаленный сайт» . Майкрософт. 2013 . Проверено 17 октября 2013 г.
  17. ^ «Поддержка контроля версий Team Foundation (TFVC)» . Расширение Azure Repos для кода Visual Studio. Гитхаб . Проверено 23 сентября 2019 г.
  18. ^ «GitHub libgit2/libgit2» . Гитхаб. 2013 . Проверено 31 октября 2013 г.
  19. ^ «ЭГит» . Затмение. 2013 . Проверено 31 октября 2013 г.
  20. ^ «Компоненты хранилища данных TFS» . Майкрософт. 2013 . Проверено 17 октября 2013 г.
  21. ^ «Перспективы и группы мер, представленные в кубе Analysis Services для Team System» . Майкрософт. 2013 . Проверено 17 октября 2013 г.
  22. ^ «Командная деятельность по созданию фундамента» . Майкрософт. 2013 . Проверено 17 октября 2013 г.
  23. ^ «Расширения сборки TFS сообщества» . Кодплекс. 2013. Архивировано из оригинала 11 октября 2013 г. Проверено 17 октября 2013 г.
  24. ^ «Microsoft Azure — Портал» . Майкрософт. 2016 . Проверено 17 мая 2016 г.
  25. ^ «Microsoft приобретает InRelease, добавляя в Visual Studio непрерывное развертывание Team Foundation Server» . Следующая сеть. 2013 . Проверено 15 ноября 2013 г.
  26. ^ Тафт, Дэррил К. (16 марта 2006 г.). «Microsoft объявляет о выпуске Team Foundation Server» . Разработка. электронная неделя . Зифф Дэвис . Проверено 13 октября 2019 г.
  27. ^ кексугит (21 ноября 2013 г.). «Какая у меня версия Team Foundation Server?» . docs.microsoft.com . Проверено 26 августа 2020 г.
  28. ^ «Хронология функций Azure DevOps» . docs.microsoft.com . Проверено 15 февраля 2021 г.
  29. ^ «Microsoft представляет следующую версию Visual Studio и .NET Framework» . Новости компании . Майкрософт . 29 сентября 2008 года . Проверено 13 октября 2019 г.
  30. ^ Брайт, Питер (12 ноября 2013 г.). «Microsoft переносит разработку в облако с помощью Visual Studio Online» . Информационные технологии. Арс Техника . Конде Наст . Проверено 13 октября 2019 г.
  31. ^ Круто, Джейми (10 сентября 2018 г.). «Представляем Azure DevOps» . Блог. Microsoft Azure . Майкрософт . Проверено 13 октября 2019 г.
  32. ^ Маки, Курт (5 марта 2019 г.). «Теперь доступно: Azure DevOps Server 2019» . Блог. Microsoft Azure . Майкрософт . Проверено 13 октября 2019 г.
  33. ^ Моралес, Глоридель (6 декабря 2022 г.). «Теперь доступно: Azure DevOps Server 2022 RTW» . Блог. Блог Azure DevOps . Майкрософт .
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Azure_DevOps_Server&oldid=1222180037"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: b5b3512b8aac8a10da0a4e9e6c1d43a8__1714812540
URL1:https://arc.ask3.ru/arc/aa/b5/a8/b5b3512b8aac8a10da0a4e9e6c1d43a8.html
Заголовок, (Title) документа по адресу, URL1:
Azure DevOps Server - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)