Azure DevOps Server , anteriormente conocido como Team Foundation Server ( TFS ) y Visual Studio Team System ( VSTS ), 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 , gestión de proyectos (tanto para equipos de desarrollo de software ágil como en cascada ), compilaciones automatizadas, pruebas y capacidades de gestión de versiones . 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 formatos diferentes: local ("Servidor") y en línea ("Servicios"). [4] El último formato se denomina Azure DevOps Services (anteriormente Visual Studio Online antes de que se le cambiara el 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 del equipo. Las nuevas características 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 aplicaciones web (denominado Team Web Access o TWA). Azure DevOps se basa en servicios web de Windows Communication Foundation . Estos pueden ser utilizados 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 respaldar la escalabilidad, se puede equilibrar la carga del nivel de aplicación y se puede agrupar el nivel de datos. Si se utiliza Microsoft SQL Server 2012 o posterior, se admiten los clústeres de conmutación por error y los grupos de disponibilidad 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 en la base de datos del almacén, que desnormaliza los datos en preparación para cargarlos en un cubo de Analysis Services. El almacén y el cubo permiten la generación de informes de tendencias complejos y el análisis de datos.
Azure DevOps se puede integrar con una granja de SharePoint existente . SQL Server Reporting Services es compatible para generar informes más avanzados en relación con el almacén de datos o el cubo de datos de Analysis Services. Estas instalaciones pueden estar en el mismo sistema o en sistemas diferentes. 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 brindar soporte a los equipos que requieren una programación de proyectos empresariales, Azure DevOps también se integra con Microsoft Project Server , lo que permite la administración de carteras a nivel empresarial, la administración de recursos y el seguimiento de proyectos.
Microsoft proporciona dos API redistribuidas independientes para conectarse a Azure DevOps. Una es un SDK de Java y la otra 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 modificó 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 de manera programática 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 Extensiones de acceso web .
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 mediante el proveedor de integración de control de código fuente de Microsoft (proveedor MSSCCI, que se pronuncia “Miss-Key”). [10] Estas herramientas proporcionan acceso completo a las funciones de Azure DevOps.
También se admiten Microsoft Excel y Microsoft Project para administrar elementos de trabajo, lo que permite la actualización, la entrada y la exportación masivas de elementos de trabajo. Microsoft Project se puede utilizar para programar el trabajo cuando se cumple 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 proyectos coloquen un cronograma en Project, importen ese trabajo en Azure DevOps, donde los desarrolladores actualizan el trabajo y luego se puede actualizar el cronograma sin que el gerente de proyectos 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 que ayuden 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 se pueden vincular a los 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 retroalimentación contextual al equipo de desarrollo. Esto proporciona retroalimentación específica sobre las funciones de una aplicación desde la perspectiva de los usuarios sin necesidad de reuniones y sesiones de demostración. Azure DevOps también proporciona herramientas de línea de comandos para entornos Unix y Windows. Las Power Tools para TFS incluyen 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 se debe realizar, un riesgo que se debe 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 datos para proporcionar un marco de desarrollo. Azure DevOps incluye plantillas de proceso 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 su uso creadas por terceros. Las plantillas de proceso se pueden personalizar mediante el Editor de plantillas de proceso, que forma parte de las herramientas avanzadas. [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 a código fuente, resultados de compilación, resultados de pruebas y versiones específicas de elementos en el control de código fuente.
La flexibilidad del sistema de elementos de trabajo permite que Azure DevOps desempeñe muchas funciones, desde la gestión de requisitos hasta el seguimiento de errores, riesgos y problemas, así como el registro de los resultados de las revisiones. Las capacidades de vinculación extensibles garantizan que se pueda lograr la trazabilidad desde los requisitos hasta el código fuente, los casos de prueba y los resultados, y que se pueda informar sobre ellos para fines de auditoría, así como para comprender el historial 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 de control de código fuente principal.
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 de cliente: espacios de trabajo de servidor y espacios de trabajo locales. [15] Los espacios de trabajo de servidor permiten a los desarrolladores bloquear archivos para su extracción y proporcionar notificaciones a otros desarrolladores de que se están editando los archivos. Una queja frecuente sobre este modelo es que los archivos en la máquina de desarrollo están marcados como de solo lectura. También requiere que los desarrolladores se "desconecten" cuando no se puede contactar con el servidor. Los espacios de trabajo locales se diseñaron 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 tratan en el momento del registro .
Para mejorar el rendimiento de los clientes remotos, Azure DevOps incluye la capacidad de instalar servidores proxy . [16] Los servidores proxy permiten almacenar en caché los contenidos de control de origen en un sitio más cercano a los desarrolladores para evitar largos viajes de red y la latencia asociada. Los registros se siguen realizando 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 sigue 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 de 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 usar para examinar todos los aspectos del código que se registra, 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 en 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 de forma gratuita en GitHub. Debido a que Microsoft adoptó el enfoque de usar una biblioteca estándar, cualquier cliente Git ahora 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 en 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 usar el complemento Team Explorer Everywhere de Microsoft para Eclipse , pueden optar por usar eGit [19] para conectarse a Azure DevOps.
El uso de Git no excluye el beneficio de usar un elemento de trabajo o un sistema de compilación de Azure DevOps. Al registrar código con Git, hacer referencia al identificador del elemento de trabajo en el comentario de registro asociará el registro con el elemento de trabajo determinado. Asimismo, Team Build también compilará proyectos de Git.
Una de las principales razones para usar Azure DevOps como repositorio de Git es que cuenta con el respaldo de SQL Server y ofrece la misma protección que Team Foundation Version Control (TFVC) [ aclaración necesaria ] . Esto ofrece a los desarrolladores algunas opciones a la hora de elegir el tipo de proyecto y el estilo de trabajo que mejor se adapta a sus necesidades.
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 la generación de informes a través de SQL Server Reporting Services cuando se instala esta opción. Dado que se trata de estructuras de cubo y base de datos estándar, cualquier herramienta que pueda apuntar a estas fuentes de datos puede generar informes 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 los servicios de generación de informes que cubren la información de compilación, los resultados y el progreso de las pruebas, la gestión de proyectos, los informes ágiles (Descripción general de la cartera de pedidos, Actualización de la versión, Actualización de sprints y Velocidad), los datos de errores y problemas. Se pueden crear nuevos informes utilizando el Generador de informes para SSRS y se puede modificar cualquiera de los informes existentes.
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 realizar un análisis detallado.
TFS 2013 introdujo una nueva característica llamada "informes livianos" que brinda la posibilidad de crear informes en tiempo real basados en resultados de consultas y que no dependen del almacén o cubo. TFS 2012 (y continúa en 2013) ofrece diagramas de evolución, velocidad y CFD en tiempo real directamente en 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 conforman 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 estaba disponible MSBuild. 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 aplicación 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 WF aún se pueden descargar, editar y almacenar en el control de código fuente si se desea y TFS 2013 no altera 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 así como de proyectos TFVC.
Windows Workflow controla el flujo general del proceso de compilación y Azure DevOps incluye muchas actividades de flujo de trabajo predefinidas 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 controlado y compilaciones continuas. Una compilación con registro controlado 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 puede corregir el código antes de intentar otro registro.
Las compilaciones tienen políticas de retención para que no se acumulen cuando no se necesitan (o se puede indicar a las compilaciones que no produzcan ningún resultado guardado) o se puede bloquear y guardar el resultado de la compilación para siempre. Una novedad de TFS 2013 es la capacidad de registrar los resultados de la compilación en el control de origen. Esta era una mejora necesaria para admitir compilaciones automatizadas en Azure DevOps Services, donde no hay una ubicación de colocación para colocar las compilaciones. En la versión local, el resultado 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 forma parte del mecanismo de trazabilidad, ya 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 registro, 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 los resultados de las pruebas funcionales automatizadas [CodedUI]). A medida que se resuelven los errores y las PBI y se 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. Combinados con las herramientas de prueba, los evaluadores obtienen una vista integrada de qué código se modificó en cada compilación, pero también qué errores, PBI y otro trabajo 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 basara 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 ofrece capacidades de compilación elásticas a través del alojamiento de compilaciones en Microsoft Azure. [24]
A mediados de 2013, Microsoft compró un producto llamado InRelease de InCycle Software. [25] InRelease se incorporó por completo 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 fueron renombradas "Release Management" para TFS 2013. Las capacidades de Release Management brindan a los equipos la capacidad de realizar un lanzamiento controlado, impulsado por flujo de trabajo (proporcionado por Windows Workflow Foundation ) a 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 de 2015 Update 2. 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]