Azure DevOps Server , anteriormente conocido como Team Foundation Server ( TFS ) y Visual Studio Team System ( VTSS ), es un producto de Microsoft que proporciona control de versiones (ya sea con Team Foundation Version Control (TFVC) o Git ), informes, gestión de requisitos , proyectos. gestión (tanto para equipos de desarrollo de software ágil como en cascada ), capacidades de gestión de versiones , pruebas y compilaciones automatizadas . Cubre todo el ciclo de vida de la aplicación y habilita las capacidades de DevOps . [2] Azure DevOps se puede utilizar como back-end para numerosos entornos de desarrollo integrados (IDE), pero está diseñado para Microsoft Visual Studio y Eclipse en todas las plataformas. [3]
Azure DevOps está disponible en dos formas diferentes: local ("Servidor") y en línea ("Servicios"). [4] La última forma se llama Azure DevOps Services (anteriormente Visual Studio Online antes de cambiar su nombre a Visual Studio Team Services en 2015). El servicio en la nube está respaldado por la plataforma en la nube Microsoft Azure . Utiliza el mismo código que la versión local de Azure DevOps, con modificaciones menores, e implementa las características más recientes. Un usuario inicia sesión con una cuenta de Microsoft para configurar un entorno, crear proyectos y agregar miembros al equipo. Las nuevas funciones desarrolladas en ciclos de desarrollo cortos se agregan primero a la versión en la nube. Estas características migran a la versión local como actualizaciones, en intervalos de aproximadamente tres meses. [5]
Azure DevOps se basa en una arquitectura escalable de varios niveles . La estructura principal consta de un nivel de aplicación responsable de procesar la lógica y mantener el portal de la aplicación web (denominado Team Web Access o TWA). Azure DevOps se crea utilizando los servicios web de Windows Communication Foundation . Estos pueden ser consumidos por cualquier cliente, aunque se recomienda el modelo de objetos de cliente. El nivel de datos y el nivel de aplicación pueden existir en la misma máquina.
Para admitir la escalabilidad, se puede equilibrar la carga del nivel de aplicación y agrupar el nivel de datos. Si utiliza Microsoft SQL Server 2012 o posterior, se admiten los grupos de disponibilidad y los clústeres de conmutación por error de AlwaysOn SQL Server, lo que permite la replicación geográfica de los datos. [6] El contenedor principal es la colección de proyectos. Una colección de proyectos es una base de datos que contiene un grupo de proyectos de equipo. La colección de proyectos es otro mecanismo de escalabilidad, ya que cada colección se puede colocar en diferentes servidores SQL o instancias de SQL Server. La base de datos de configuración 'Oe' por instancia de Azure DevOps almacena metadatos de la colección de proyectos. Los datos de las bases de datos de la colección de proyectos se agregan a la base de datos del almacén, lo que desnormaliza los datos en preparación para cargarlos en un cubo de Analysis Services. El almacén y el cubo permiten elaborar informes de tendencias y análisis de datos complejos.
Azure DevOps se puede integrar con una granja de SharePoint existente . SQL Server Reporting Services es compatible con informes más avanzados sobre el almacén de datos o el cubo de datos de Analysis Services. Estas instalaciones pueden ser en el mismo sistema o en diferentes sistemas. También se pueden agregar a la infraestructura servidores de compilación, servidores de administración de laboratorio, servidores de administración de versiones y servidores proxy (para reducir parte de la carga en el nivel de aplicación), máquinas de prueba y máquinas de prueba de carga. [7] Para respaldar a los equipos que requieren programación de proyectos empresariales, Azure DevOps también se integra con Microsoft Project Server , que permite la gestión de carteras a nivel empresarial, la gestión de recursos y el seguimiento de proyectos.
Microsoft proporciona dos API redistribuidas independientes para conectarse a Azure DevOps. Uno es un SDK de Java y el otro es un SDK de .NET Framework . Estas API permiten la conectividad del cliente con Azure DevOps. Debido a que Azure DevOps está escrito en una arquitectura orientada a servicios , puede comunicarse con prácticamente cualquier herramienta que pueda llamar a un servicio web. Otro mecanismo extensible es la suscripción a alertas del sistema: por ejemplo, alertas de que se cambió un elemento de trabajo o se completó una compilación. Hay aproximadamente 20 alertas preconfiguradas y los equipos pueden configurar tantas alertas adicionales como sea necesario. [8] Cuando se utilizan en un escenario extensible, estas alertas se pueden enviar a un servicio web, lo que desencadena acciones para alterar o actualizar elementos de trabajo (como implementar reglas comerciales avanzadas o generar elementos de trabajo mediante programación en función de un escenario determinado).
El almacén de datos también se puede ampliar mediante la creación de adaptadores de almacén de datos personalizados. [9] Con la introducción de TFS 2012, también se pueden crear complementos personalizados para Team Web Access, llamados Web Access Extensions .
Azure DevOps es compatible con Visual Studio 2010 y versiones posteriores, Microsoft Test Manager (MTM) 2012 y 2013. Eclipse, versiones anteriores de Visual Studio y otros entornos se pueden conectar a Azure DevOps utilizando el proveedor de integración de control de código fuente de Microsoft (proveedor MSSCCI – pronunciado “Señorita-llave”). [10] Estas herramientas brindan acceso completo a las funciones de Azure DevOps.
Microsoft Excel y Microsoft Project también son compatibles para ayudar a administrar elementos de trabajo, lo que permite actualizaciones, entradas y exportaciones masivas de elementos de trabajo. Microsoft Project se puede utilizar para programar el trabajo cuando se sigue una metodología de desarrollo de software en cascada. Tanto Excel como Project admiten actualizaciones bidireccionales de datos. Esto permite, por ejemplo, que los gerentes de proyecto establezcan un cronograma en Project, importen ese trabajo a Azure DevOps donde los desarrolladores actualizan el trabajo y luego el cronograma se puede actualizar sin que el gerente del proyecto tenga que realizar trabajo adicional.
Con Team Foundation Server 2012, Microsoft PowerPoint también se integró con Azure DevOps para permitir el desarrollo rápido de guiones gráficos para ayudar con el proceso de gestión de requisitos. La integración proporciona formas de guiones gráficos extensibles que se pueden usar para crear cualquier tipo de maqueta de interfaz que luego se puede animar con las funciones integradas de PowerPoint. Estos guiones gráficos luego se pueden vincular a elementos de trabajo.
En un esfuerzo por manejar la creciente dispersión geográfica de los equipos e involucrar a las partes interesadas antes y con más frecuencia en el proceso, Microsoft agregó Feedback Client. [11] Esta herramienta permite a los usuarios ejercitar una aplicación, anotar lo que están viendo con audio y video, capturar pantallas y proporcionar comentarios contextuales al equipo de desarrollo. Esto proporciona comentarios específicos sobre las funciones de una aplicación desde la perspectiva de los usuarios sin requerir reuniones ni sesiones de demostración. Azure DevOps también proporciona herramientas de línea de comandos para entornos Unix y Windows. Power Tools para TFS incluye una integración de shell de Windows que permite a los usuarios registrar y retirar archivos, agregar archivos y realizar otras tareas básicas haciendo clic derecho en un archivo o carpeta.
En el corazón de Azure DevOps se encuentra el "elemento de trabajo". Un elemento de trabajo representa una cosa: puede ser un trabajo que debe realizarse, un riesgo que rastrear, un caso de prueba, un error o prácticamente cualquier otra cosa que un usuario pueda imaginar. Los elementos de trabajo se definen a través de documentos XML y son altamente extensibles. [12] Los elementos de trabajo se combinan en una plantilla de proceso que contiene estos y otros elementos de información para proporcionar un marco de desarrollo. Azure DevOps incluye plantillas de procesos para Microsoft Solutions Framework para Agile, Scrum y CMMI. Los equipos pueden optar por utilizar una plantilla integrada o una de las muchas plantillas disponibles para usar creadas por terceros. Las plantillas de proceso se pueden personalizar utilizando el Editor de plantillas de proceso, que forma parte de Power Tools. [13]
Los elementos de trabajo se pueden vincular entre sí mediante diferentes relaciones para crear un árbol jerárquico de elementos de trabajo o una relación plana entre elementos de trabajo. Los elementos de trabajo también se pueden vincular a artefactos externos, como páginas web, documentos en un recurso compartido de archivos o documentos almacenados en otro repositorio como SharePoint. Los elementos de trabajo también se pueden vincular al código fuente, resultados de compilación, resultados de pruebas y versiones específicas de elementos en el control de fuente.
La flexibilidad del sistema de elementos de trabajo permite a Azure DevOps desempeñar muchas funciones, desde la gestión de requisitos hasta el seguimiento de errores, el seguimiento de riesgos y problemas, además de registrar los resultados de las revisiones. Las capacidades de enlace extensibles garantizan que la trazabilidad desde los requisitos hasta el código fuente, los casos de prueba y los resultados se pueda lograr e informar con fines de auditoría, así como para la comprensión histórica de los cambios.
Azure DevOps admite dos tipos diferentes de control de código fuente : su motor de control de código fuente original llamado Team Foundation Version Control (TFVC) y con el lanzamiento de TFS 2013, admite Git como repositorio central de control de código fuente.
TFVC es un sistema de control de versiones centralizado que permite a los equipos almacenar cualquier tipo de artefacto dentro de su repositorio. [14] TFVC admite dos tipos diferentes de espacios de trabajo cuando se trabaja con herramientas cliente: espacios de trabajo de servidor y espacios de trabajo locales. [15] Los espacios de trabajo del servidor permiten a los desarrolladores bloquear archivos para su extracción y notificar a otros desarrolladores que los archivos se están editando. Una queja frecuente de este modelo es que los archivos de la máquina de desarrollo están marcados como de sólo lectura. También requiere que los desarrolladores "se desconecten" cuando no se puede contactar con el servidor. Los espacios de trabajo locales fueron diseñados para evitar estos problemas. En un escenario de espacio de trabajo local, los archivos no son de solo lectura y no es necesario extraerlos antes de trabajar en ellos. Mientras los archivos estén en la máquina local del desarrollador, no importa si el servidor está conectado o no. Los conflictos se solucionan en el momento del check-in .
Para mejorar el rendimiento de los clientes remotos, Azure DevOps incluye la capacidad de instalar servidores proxy . [16] Los servidores proxy permiten que los contenidos de control de fuente se almacenen en caché en un sitio más cercano a los desarrolladores para evitar largos viajes de red y la latencia asociada. Los registros todavía se realizan directamente en el nivel de aplicación de Azure DevOps, por lo que el servidor proxy es más beneficioso en escenarios de lectura.
Como parte del motor de control de código fuente, Azure DevOps admite una serie de características para ayudar a los desarrolladores a garantizar que el código que se registra siga reglas configurables. Este motor de reglas se denomina política de registro. Existen varias políticas listas para usar, como la Política de comentarios del conjunto de cambios, que no permitirá un registro a menos que el desarrollador ingrese un comentario de registro. Estas políticas son extensibles y se pueden utilizar para examinar todos los aspectos del código que se está incorporando, los comentarios y los elementos de trabajo relacionados. Azure DevOps también admite una característica de análisis de código que, cuando se usa de forma independiente, se conoce como FxCop . La inclusión en Azure DevOps significa que el análisis se puede ejecutar con el código registrado en el servidor y durante las compilaciones automatizadas.
La extensión Azure Repos para Visual Studio Code admite TFVC. [17]
Con el lanzamiento de TFS 2013, Microsoft agregó soporte nativo para Git . Esta no es una implementación específica de Microsoft sino una implementación estándar basada en la biblioteca libgit2 [18] . Esta es la misma biblioteca que impulsa el popular GitHub y el código está disponible gratuitamente en GitHub. Debido a que Microsoft adoptó el enfoque de usar una biblioteca estándar, ahora cualquier cliente Git se puede usar de forma nativa con Azure DevOps (en otras palabras, los desarrolladores pueden usar sus herramientas favoritas y nunca instalar los clientes estándar de Azure DevOps). Esto permite que las herramientas de cualquier plataforma y cualquier IDE que admita Git se conecten a Azure DevOps. Por ejemplo, tanto Xcode como Android Studio admiten complementos de Git. Además, si los desarrolladores no quieren utilizar el complemento Team Explorer Everywhere de Microsoft para Eclipse , pueden optar por utilizar eGit [19] para conectarse a Azure DevOps.
El uso de Git no excluye el beneficio de usar el elemento de trabajo o el sistema de compilación de Azure DevOps. Al registrar el código con Git, hacer referencia al ID del elemento de trabajo en el comentario de registro asociará el registro con el elemento de trabajo determinado. Asimismo, Team Build también creará proyectos Git.
Una de las principales razones para utilizar Azure DevOps como repositorio de Git es que está respaldado por SQL Server y ofrece la misma protección que Team Foundation Version Control (TFVC). Esto brinda a los desarrolladores algunas opciones a la hora de elegir el tipo de proyecto y estilo de trabajo que mejor les convenga.
Los informes han sido un componente central de Azure DevOps desde su lanzamiento inicial en 2005. La infraestructura de informes consta de un almacén de datos [20] (Tfs_Warehouse), que es una base de datos relacional y un cubo de datos de SQL Server Analysis Services. [21] Ambas fuentes están disponibles para generar informes a través de SQL Server Reporting Services cuando esta opción está instalada. Dado que se trata de estructuras de cubos y bases de datos estándar, cualquier herramienta que pueda apuntar a estas fuentes de datos puede informar desde ellas. Esto incluye herramientas como Cognos, Tableau, Excel y otras herramientas de generación de informes. Con cada plantilla de proceso lista para usar se incluye un conjunto de informes para servicios de informes que cubren información de compilación, resultados y progreso de pruebas, gestión de proyectos, informes ágiles (descripción general del trabajo pendiente, análisis de versiones, análisis de sprint y velocidad), datos de errores y problemas. Se pueden crear nuevos informes utilizando Report Builder para SSRS y cualquiera de los informes existentes se puede modificar.
Hay informes más especializados disponibles para los resultados de las pruebas de carga. Estos datos están disponibles directamente en Visual Studio y se pueden exportar a Excel para un análisis detallado.
TFS 2013 introdujo una nueva característica llamada "informes ligeros" que brinda la capacidad de crear informes en tiempo real basados en los resultados de la consulta y que no dependen del almacén o cubo. TFS 2012 (y continuará en 2013) ofrece diagramas de combustión, velocidad y CFD en tiempo real directamente dentro de Team Web Access.
Team Build (anterior a TFS 2015) es una aplicación de servidor de compilación incluida con Team Foundation Server. Dos componentes componen Team Build: MSBuild y Windows Workflow Foundation . MSBuild es un lenguaje XML declarativo similar a Apache Ant . WF se agregó al proceso de compilación a partir de TFS 2010; Antes de eso, solo MSBuild estaba disponible. Las capacidades de compilación han seguido evolucionando con cada versión posterior de Azure DevOps. En TFS 2010 y 2012, los archivos de plantillas WF ( Lenguaje de marcado de aplicaciones extensible ) se almacenaban en el control de código fuente y se podían editar y versionar directamente desde el control de código fuente. En TFS 2013, estos archivos se eliminaron para eliminar el desorden y agilizar el proceso de compilación. Las plantillas de WF aún se pueden descargar, editar y almacenar en el control de código fuente si lo desea y TFS 2013 no interrumpe las plantillas de proceso de compilación de TFS 2010 o 2012 existentes. Con el soporte de Git en TFS 2013, Team Build se ha mejorado para permitir la creación automatizada de proyectos Git y proyectos TFVC.
Windows Workflow controla el flujo general del proceso de compilación y Azure DevOps incluye muchas actividades de flujo de trabajo prediseñadas para administrar tareas comunes que se realizan durante una compilación. [22] MSBuild es el lenguaje de marcado que se encuentra en los archivos .proj (csproj para proyectos de C# y vbproj para proyectos de Visual Basic). El sistema de compilación es extensible y los usuarios pueden crear sus propias actividades de flujo de trabajo, la capacidad de inyectar MSBuild en el proceso y ejecutar procesos externos. La naturaleza del flujo de trabajo de la compilación permite una flexibilidad ilimitada, pero puede requerir algo de trabajo lograr esa flexibilidad. Se han iniciado proyectos compartidos [23] y de código abierto para crear actividades respaldadas por la comunidad para mejorar las capacidades de Team Build.
El proceso de compilación se puede configurar para varios tipos de compilaciones, incluidas compilaciones programadas, integración continua , registro cerrado y compilaciones continuas. Una compilación de registro cerrado archivará el código que un desarrollador registra, realizará una "obtención de la última versión" en el código del servidor y realizará una compilación. Si la compilación se realiza correctamente, el código se registra en nombre del desarrollador que envió el código. Si la compilación falla, se notifica al desarrollador y éste puede corregir el código antes de intentar realizar otro check-in.
Las compilaciones tienen políticas de retención para que no se acumulen cuando no se necesitan (o se puede ordenar a las compilaciones que no produzcan ningún resultado guardado) o la salida de la compilación se puede bloquear y guardar para siempre. Lo nuevo de TFS 2013 es la capacidad de registrar los resultados de la compilación en el control de fuente. Esta fue una mejora necesaria para admitir compilaciones automatizadas en Azure DevOps Services donde no hay una ubicación para colocar las compilaciones. En la versión local, la salida de la compilación se puede configurar para que termine en cualquier ubicación de carpeta compartida accesible.
El proceso de compilación en Azure DevOps también es parte del mecanismo de trazabilidad en el sentido de que Team Build reúne muchos de los artefactos que se crean y almacenan en Azure DevOps. Suponiendo que los desarrolladores asocian el código fuente con los elementos de trabajo en el momento del check-in, Team Build tiene la capacidad de informar sobre los cambios en cada compilación, tanto los cambios en el código fuente como los cambios en los elementos de trabajo, así como los resultados de las pruebas (esto incluye los resultados de las pruebas unitarias y las automatizadas). resultados de pruebas funcionales (CodedUI)). A medida que los errores y los PBI se resuelven e integran en las compilaciones, los elementos de trabajo que rastrean estos artefactos se actualizan automáticamente para indicar en qué compilación se integraron correctamente. Combinado con las herramientas de prueba, los evaluadores obtienen una vista integrada de qué código se cambió en cada compilación, pero también qué errores, PBI y otros trabajos cambiaron de una compilación a otra.
Inicialmente, en TFS 2015 y con Visual Studio Team Services (VSTS), Microsoft reinventó la arquitectura del motor de compilación para que se base en una aplicación Node.js compatible con múltiples plataformas. Actualmente se admiten agentes de compilación para Windows, Mac y Linux. Azure DevOps proporciona capacidades de compilación elástica a través del alojamiento de compilación en Microsoft Azure. [24]
A mediados de 2013, Microsoft compró un producto llamado InRelease de InCycle Software. [25] InRelease se incorporó completamente a Team Foundation Server 2013. Esta capacidad complementó los procesos automatizados de compilación y prueba al permitir una verdadera solución de implementación continua . Las herramientas pasaron a denominarse "Gestión de versiones" para TFS 2013. Las capacidades de Gestión de versiones brindan a los equipos la capacidad de realizar una versión controlada, impulsada por el flujo de trabajo (proporcionado por Windows Workflow Foundation ) para entornos de desarrollo, prueba y producción, y proporciona paneles para monitorear el progreso de uno o más lanzamientos.
Microsoft ha reconstruido Release Management para Visual Studio Team Services y la versión local de TFS con los nuevos cambios en la Actualización 2 de 2015. La nueva versión de Release Management aprovecha el navegador web como cliente y se basa en la misma arquitectura de agente que Team Foundation Build. . Release Management habilita las capacidades de DevOps para Azure DevOps.
Esta primera versión de Team Foundation Server se lanzó el 17 de marzo de 2006. [26]