Azure DevOps ya está disponible en el HYCU Marketplace

Azure DevOps constituye la columna vertebral de las operaciones de entrega de decenas de miles de organizaciones de ingeniería, y cuenta con una fuerte presencia en sectores en los que el lanzamiento de software está sujeto a un estricto control normativo. Más de 30 000 empresas lo utilizan, y muchas de ellas gestionan a través de él sus productos más regulados y críticos para el negocio. Una plataforma de esta importancia requiere una protección de datos de nivel empresarial. 

Hoy nos complace anunciar la disponibilidad general de HYCU Backup and Recovery para Azure DevOps, una solución de protección de datos y recuperación granular diseñada específicamente para la plataforma a través de la cual sus equipos realizan sus entregas. 

Por qué es fundamental proteger Azure DevOps 

Cuando los equipos piensan en proteger Azure DevOps, piensan en los repositorios. Los repositorios son solo una pequeña parte del problema. La parte mucho más importante es el sistema de entrega que los rodea. 

• El plan, el historial y la configuración solo existen en el servicio. Los elementos de trabajo contienen requisitos, decisiones, comentarios y el historial completo de revisiones. Los tableros, las listas de tareas pendientes, las consultas, los paneles de control, las plantillas de procesos y los tipos de elementos de trabajo personalizados tardaron años en crearse y no figuran en el clon de nadie. Se reconstruyen a partir de la memoria, los tickets y las capturas de pantalla. 
• La entrega se detiene sin la automatización. Las definiciones de pipeline, los grupos de variables, los entornos, las colas de agentes y los hooks de servicio son los elementos que permiten que el código funcional se convierta en software entregado. Si se pierden, el código permanece intacto, pero no se entrega nada.
• Se destruyen las pruebas de auditoría. En el desarrollo regulado, los elementos de trabajo y los planes de pruebas constituyen el registro de trazabilidad de los requisitos a probar que solicita un evaluador. Si no puede presentarlo, se enfrentará a una observación de auditoría y a un lanzamiento que quedará en suspenso mientras alguien vuelve a preparar la documentación.  
• Los tokens y las extensiones tienen un alcance mayor de lo que la gente espera. Un token de acceso personal, una cuenta de servicio o una extensión de Marketplace con amplios permisos pueden acceder y destruir mucho más de lo que pretendía la persona que los creó. El token de un ingeniero que ya no forma parte de la plantilla suele ser la credencial de la que depende un proceso crítico.
• La recuperación nativa es una realidad, pero tiene sus límites. Una organización o un proyecto eliminado se puede recuperar durante 28 días; un repositorio, durante 30; los planes y conjuntos de pruebas, durante 14; y no existe en absoluto la posibilidad de restauración a un momento concreto. Un script que invoque la API de eliminación con el parámetro «destroy» omite la papelera de reciclaje, y la propia documentación de Microsoft advierte de que esos elementos de trabajo no se pueden recuperar. En cuanto al resto, Microsoft es tajante: «No ofrecemos soporte para la restauración de activos que los clientes eliminen accidentalmente». 

Lo que hace que Azure DevOps sea difícil de proteger por su cuenta

• Cinco servicios, cinco modelos de datos. «Repos» es un grafo de objetos de Git. «Boards» es un almacén de seguimiento del trabajo. Pipelines son metadatos de definición. Los planes de prueba son elementos de trabajo que se comportan de forma diferente a otros elementos de trabajo. Los artefactos son cargas útiles de paquetes binarios. Cada uno requiere su propio método de captura y su propia ruta de escritura, por lo que ninguna exportación por sí sola produce una copia utilizable.
• El esquema es información, y debe recuperarse en primer lugar. Una plantilla de proceso define todos los tipos de elementos de trabajo, campos, reglas y estados del proyecto. Los elementos de trabajo son instancias de dicha plantilla. Si los restaura antes de que exista el esquema, no tendrán dónde alojarse.
• Un pipeline depende de elementos almacenados en otra parte. Una definición de compilación resuelve sus grupos de variables, conexiones de servicio, grupos de tareas y entornos a partir de la configuración del proyecto, y sus colas de agentes a partir de la configuración de la organización. Si realiza una copia de seguridad solo de la definición, obtendrá un pipeline que no podrá ejecutarse, por lo que la protección debe abarcar ambos ámbitos, que Azure DevOps mantiene separados.
• Los wikis son repositorios encubiertos. Un wiki es un repositorio de Git con un registro a nivel de servicio superpuesto, por lo que no es ni código puro ni contenido puro. Protegerlo significa tratarlo como ambas cosas. 

Si una copia de seguridad captura los objetos sin registrar cómo encajan entre sí, lo que se recupera es un proyecto en el que nadie puede trabajar. 

HYCU R-Cloud para Azure DevOps: Recupere exactamente lo que se ha dañado 

HYCU para Azure DevOps está diseñado teniendo en cuenta cómo suelen desarrollarse estos incidentes: se borra o se daña algo importante y alguien se da cuenta más tarde. Esto es lo que significa en la práctica: 

• Protección completa del sistema de entrega: La mayoría de las herramientas protegen el repositorio. R-Cloud protege también todo lo que lo rodea: elementos de trabajo y su historial, tableros y consultas, definiciones de canalizaciones, wikis, planes de pruebas y configuraciones de la organización. 
• El esquema se incluye en la copia de seguridad: Las plantillas de procesos y los tipos de elementos de trabajo personalizados se protegen junto con los elementos de trabajo creados a partir de ellos, de modo que la estructura en la que se creó el trabajo se puede recuperar, en lugar de tener que reconstruirse de memoria. 
• Recuperación a cualquier nivel: Tanto si necesita un elemento de trabajo, un repositorio, un canal, un proyecto completo o la configuración de su organización, R-Cloud se encarga de ello desde la misma plataforma. Las restauraciones se realizan in situ, por lo que los equipos que no se han visto afectados siguen trabajando sin interrupciones. 
• Pruebas que perduran más allá del plazo: El historial de compilaciones y lanzamientos, las ejecuciones de pruebas y el registro de auditoría de la organización se registran y pueden exportarse, de modo que, cuando un evaluador le pregunte por un lanzamiento de hace dieciocho meses, aún podrá mostrar qué se entregó, qué se probó y quién modificó qué. 
• Inmutabilidad a nivel de almacenamiento: Se dispone de bloqueo de objetos e inmutabilidad WORM, y una credencial de Azure DevOps no puede acceder a la copia de seguridad, por lo que un token comprometido o un error del administrador no se propaga a ella. 
• Su almacenamiento, su control: Las copias de seguridad se almacenan en el almacenamiento de su propiedad, en su cuenta y en su región.  
• Retención flexible: Usted decide durante cuánto tiempo se conservan las copias, independientemente del plazo de 28 días que le ofrece la plataforma. 
• Protección unificada de Microsoft: Azure DevOps, Microsoft 365, Entra ID, Azure y GitHub protegidos desde una única plataforma, bajo un único marco normativo y con un único lugar desde el que gestionar la recuperación. 

El sistema a través del cual su empresa realiza envíos merece el mismo nivel de protección de datos que cualquier otro sistema de misión crítica de su organización.

Vea una recuperación en acción

¿Está listo para comprobarlo con su propia organización de Azure DevOps?

Realice este recorrido autoguiado para ver cómo puede recuperar los elementos perdidos en cuestión de minutos.