Comparar Azure DevOps Services con Azure DevOps Server

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013

La oferta denube , Azure DevOps Services, proporciona un servicio hospedado escalable, confiable y disponible globalmente. Está respaldo de un Acuerdo de Nivel de Servicio del 99,9 %, supervisado por nuestro equipo de operaciones 24/7 y disponible en centros de datos locales de todo el mundo.

La oferta local, Azure DevOps Server, se basa en un back-end SQL Server local. Los clientes suelen elegir la versión local cuando necesitan que sus datos permanezcan dentro de su red. O bien, cuando quieran acceder a SQL Server servicios de informes que se integran con Azure DevOps Server y herramientas.

Aunque ambas ofertas proporcionan los mismos servicios esenciales,en comparación con Azure DevOps Server, Azure DevOps Services ofrece las siguientes ventajas agregadas:

  • Administración simplificada del servidor.
  • Acceso inmediato a las características más recientes y mejores
  • Conectividad mejorada con sitios remotos.
  • Una transición de los gastos de capital (servidores y otros) a los gastos operativos (suscripciones).

Para determinar qué oferta en la nube o local satisface —— sus necesidades, tenga en cuenta las siguientes diferencias clave.

Diferencias fundamentales entre Azure DevOps Services y Azure DevOps Server

Al elegir la plataforma que quiere o si está pensando en pasar del entorno local a la nube, tenga en cuenta las siguientes áreas:

Diferencias en áreas de características específicas
Aunque Azure DevOps Services es una versión hospedada de Azure DevOps Server, hay algunas diferencias entre las características. Algunas Azure DevOps Server características no se admiten en Azure DevOps Services. Por ejemplo, Azure DevOps Services no admite la integración con SQL Server Analysis Services para admitir informes.

Dos de las otras áreas siguientes difieren en su compatibilidad:

¿Está en Azure DevOps Server está pensando en trasladarse? Lea Opciones de migración para comprender las opciones.

Ámbito y escalado de datos

A medida que crece su negocio, es posible que tenga que escalar verticalmente la Azure DevOps aplicación.

Azure DevOps Services escala mediante organizaciones y proyectos

Azure DevOps Services difiere ligeramente de Azure DevOps Server. Actualmente solo hay dos opciones para el ámbito y el escalado de datos: organizaciones y proyectos. Las organizaciones Azure DevOps Services obtienen sus propias direcciones URL (por ejemplo, ) y https://dev.azure.com/fabrikamfiber siempre tienen exactamente una colección de proyectos. Las organizaciones pueden tener muchos proyectos dentro de una colección.

Se recomienda crear organizaciones en Azure DevOps Services donde quiera crear colecciones en Azure DevOps Server. Se aplican los siguientes escenarios:

  • Puede comprar usuarios Azure DevOps Services por organización: los usuarios de pago solo pueden acceder a la organización en la que se realiza el pago. Si tiene usuarios que necesitan acceso a muchas organizaciones, Visual Studio suscripciones pueden ser una opción atractiva. Visual Studio suscriptores se pueden agregar a cualquier número de organizaciones sin cargo alguno. También estamos considerando otras formas de hacer que el acceso esté disponible para muchas organizaciones que están agrupadas en una sola organización.
  • Actualmente tiene que administrar las organizaciones de una en una. Este proceso puede resultar complicado cuando hay muchas organizaciones.

Más información: Planeación de la estructura organizativa en Azure DevOps.

Azure DevOps Server escala mediante implementaciones, colecciones de proyectos y proyectos

Azure DevOps Server ofrece las tres opciones siguientes para el ámbito y el escalado de datos: implementaciones, colecciones de proyectos y proyectos. En el caso más sencillo, las implementaciones son solo servidores.

Sin embargo, las implementaciones pueden ser más complicadas, lo que podría incluir:

  • Implementación de dos servidores donde SQL se divide en una máquina independiente
  • Granjas de alta disponibilidad con una gran cantidad de servidores

Project colecciones sirven como contenedores para la seguridad y administración, y límites de base de datos física. También se usan para agrupar proyectos relacionados.

Por último, los proyectos se usan para encapsular los recursos de proyectos de software individuales, incluido el código fuente, los elementos de trabajo, entre otros.

Más información: Planeación de la estructura organizativa en Azure DevOps.

Autenticación

Con Azure DevOps Services, se conecta a través de la red pública de Internet (por ejemplo, https://contoso.visualstudio.com ). Puede autenticarse con las credenciales de la cuenta Microsoft o con Azure AD, en función de la configuración de la organización. También puede configurar Azure AD para requerir características como la autenticación multifactor, restricciones de direcciones IP, entre otras.

Se recomienda configurar las organizaciones para que usen Azure AD en lugar de cuentas microsoft. Este método proporciona una mejor experiencia en muchos escenarios y más opciones para mejorar la seguridad.

Más información: Acerca del acceso a Azure DevOps Services con Azure AD.

Con Azure DevOps Server, se conecta a un servidor de intranet (por ejemplo, https://tfs.corp.contoso.com:8080/tfs ). Se autentica con Windows autenticación y las Active Directory de dominio (AD). Este proceso es transparente y nunca se ve ningún tipo de experiencia de inicio de sesión.

Administración de usuarios y grupos

En Azure DevOps Services, puede usar un mecanismo similar para proporcionar acceso a grupos de usuarios. Puede agregar grupos Azure AD a Azure DevOps Services grupos. Si usa cuentas microsoft en lugar de Azure AD, tendrá que agregar usuarios de uno en uno.

En Azure DevOps Server, puede proporcionar a los usuarios acceso a las implementaciones agregando grupos de Active Directory (AD) a varios grupos de Azure DevOps (por ejemplo, el grupo Colaboradores de un proyecto individual). Las pertenencias a grupos de AD se mantienen sincronizadas. A medida que los usuarios se agregan y quitan en AD, también obtienen y pierden acceso a Azure DevOps Server.

Administrar el acceso de los usuarios

Tanto en Azure DevOps Services como Azure DevOps Server, puede administrar el acceso a las características mediante la asignación de usuarios a un nivel de acceso. Todos los usuarios deben estar asignados a un único nivel de acceso. En las ofertas locales y en la nube, puede dar acceso gratuito a las características de elementos de trabajo a un número ilimitado de partes interesadas. Además, un número ilimitado de Visual Studio suscriptores pueden tener acceso a todas las características básicas sin cargo adicional. Solo paga por otros usuarios que necesitan acceso.

En Azure DevOps Services, debe asignar un nivel de acceso a cada usuario de su organización. Azure DevOps Services valida Visual Studio suscriptores a medida que inician sesión. Puede asignar acceso básico de forma gratuita a cinco usuarios sin Visual Studio suscripciones.

Para proporcionar acceso básico o superior a más usuarios, configure la facturación de su organización y pague por más usuarios. De lo contrario, todos los demás usuarios obtienen acceso de las partes interesadas.

Azure AD grupos de usuarios dan acceso a grupos de usuarios. Los niveles de acceso se asignan automáticamente al primer inicio de sesión. En el caso de las organizaciones que están configuradas para usar cuentas de Microsoft para iniciar sesión, debe asignar niveles de acceso a cada usuario explícitamente.

En Azure DevOps Server, todo el uso se hace en el sistema honor. Para establecer los niveles de acceso para los usuarios en función de sus licencias, especifique sus niveles de acceso en la página de administración. Por ejemplo, asigne solo acceso de partes interesadas a usuarios sin licencia.

Los usuarios con una Azure DevOps Server licencia de acceso de cliente (CAL) pueden tener acceso básico. Visual Studio suscriptores pueden tener acceso básico o avanzado, en función de sus suscripciones. Azure DevOps Server no intenta comprobar estas licencias ni aplicar el cumplimiento.

Seguridad y protección de los datos

Muchas entidades quieren saber más sobre la protección de datos cuando consideren la posibilidad de pasar a la nube. Nos comprometemos a garantizar que los proyectos Azure DevOps Services permanezcan seguros y seguros. Tenemos características técnicas y procesos empresariales para cumplir este compromiso. También puede tomar medidas para proteger los datos. Obtenga más información en la introducción a la protección de datos.

Personalización de procesos

Puede personalizar la experiencia de seguimiento del trabajo de dos maneras diferentes, en función del modelo de proceso admitido:

  • Azure DevOps Services: se usa el modelo de proceso de herencia, que admite la personalización de WYSIWYG.
  • Azure DevOps Server: puede elegir el modelo de proceso de herencia o el modelo de proceso XML local, que admite la personalización mediante la importación o exportación de archivos de definición XML para objetos de seguimiento de trabajo.
  • Azure DevOps Server 2018 y versiones anteriores: solo tiene acceso al modelo de proceso XML local

Aunque la opción Modelo de proceso XML local es eficaz, puede causar varios problemas. El problema principal es que los procesos de los proyectos existentes no se actualizan automáticamente.

Azure DevOps Server 2013, por ejemplo, introdujo varias características nuevas que dependían de nuevos tipos de elementos de trabajo y otros cambios en la plantilla de proceso. Al actualizar de 2012 a 2013, cada colección de proyectos obtiene nuevas versiones de cada una de las plantillas de proceso "en el cuadro" que incluyen estos cambios. Sin embargo, estos cambios no se incorporan automáticamente a los proyectos existentes. En su lugar, cuando termine de actualizar, tendrá que incluir los cambios en cada proyecto mediante el Asistente para configurar características o un proceso más manual.

Para ayudarle a evitar estos problemas en Azure DevOps Services, las plantillas de proceso personalizadas y la herramientawitadmin.exe siempre se han deshabilitado. Este enfoque nos ha permitido actualizar automáticamente todos los proyectos con cada Azure DevOps Services actualización. Mientras tanto, el equipo del producto está trabajando duro para que los procesos de personalización sea posible de maneras que podamos admitir de forma fácil y continua. Recientemente presentamos el primero de estos cambios y hay más cambios en camino.

Con la nueva funcionalidad de personalización de procesos, puede realizar cambios directamente dentro de la interfaz de usuario web (UI). Si desea personalizar los procesos mediante programación, puede hacerlo a través de puntos de conexión REST. Al personalizar los proyectos de esta manera, se actualizan automáticamente cuando se lanzan nuevas versiones de sus procesos base con Azure DevOps Services actualizaciones.

Para más información, consulte Personalización de la experiencia de seguimiento de trabajo.

Informes

Azure DevOps Services y Azure DevOps Server ofrecen muchas herramientas que proporcionan información sobre el progreso y la calidad de los proyectos de software. Se incluyen las siguientes herramientas:

  • Paneles y gráficosligeros que están disponibles en las plataformas locales y en la nube. Estas herramientas son fáciles de configurar y usar.

Azure DevOps Services y Azure DevOps Server 2019 también proporcionan acceso a los siguientes servicios:

  • El servicio Analytics y los widgets de Analytics. El servicio Analytics está optimizado para el acceso de lectura rápido y las agregaciones basadas en servidor.
  • Microsoft Power BI integración, que admite la obtención de datos de Analytics en Power BI informes y proporciona una combinación de simplicidad y eficacia.
  • OData admite, que permite consultar directamente el servicio Analytics desde un explorador compatible y, a continuación, usar los datos JSON devueltos como desee. Puede generar consultas que abarquen muchos proyectos o toda la organización.

Para obtener más información sobre el servicio Analytics y las versiones futuras, consulte nuestra hoja de ruta de informes.

SQL Server Reporting Services (SSRS) están disponibles en Azure DevOps Server cuando se configuran con SQL Server Analysis Services.

Visual Studio Team Services es ahora Azure DevOps Services

Muchos de los servicios destacados de VSTS ahora se ofrecen como servicios independientes en Azure DevOps Services y Azure DevOps Server 2019. Puede obtener servicios por separado o todos juntos como Azure DevOps Services. Si es un suscriptor Azure DevOps, ya tiene acceso a todos los servicios.

Nombre de la característica de VSTS Azure DevOps nombre del servicio Descripción
Versión de & compilación Azure Pipelines Integración continua y entrega continua (CI/CD) que funciona con cualquier lenguaje, plataforma y nube.
Código Azure Repos Repositorios de Git y de Control de versiones de Team Foundation privados (TFVC) hospedados en la nube ilimitados para el proyecto.
Work Azure Boards Seguimiento del trabajo con paneles Kanban, trabajos pendientes, paneles de equipo e informes personalizados.
Prueba Azure Test Plans Solución de pruebas todo en uno planeadas y exploratorias.
Paquetes (extensión) Azure Artifacts Maven, npm, Python, Universal Package y NuGet de paquetes de orígenes públicos y privados.

Tanto Azure DevOps Services como Azure DevOps Server 2019 usan la nueva interfaz de usuario de navegación, con una barra lateral vertical para ir a las áreas de servicio principales: Boards, Repos, Pipelines, etc. Para más información, consulte Navegación por el portal web en Azure DevOps.

Nota

Puede deshabilitar la selección de servicios desde la interfaz de usuario. Para obtener más información, vea Activar o desactivar un servicio.

Todavía puede usar para visualstudio.com acceder a Azure DevOps Services. Hemos pasado al nuevo nombre de dominio como dev.azure.com la dirección URL principal de las nuevas organizaciones. Esa dirección URL es https://dev.azure.com/{your organization}/{your project} . Si desea cambiar la dirección URL en la que se basará como principal, un administrador de la organización puede hacerlo desde la página de configuración dev.azure.com de la organización.