Azure DevOps est désormais disponible sur la Marketplace HYCU

Azure DevOps constitue la colonne vertébrale des processus de livraison de dizaines de milliers d’équipes d’ingénierie, et il est très présent dans les secteurs où les logiciels sont soumis à une surveillance réglementaire stricte. Plus de 30 000 entreprises l’utilisent, et bon nombre d’entre elles y gèrent leurs produits les plus réglementés et les plus critiques pour leur activité. Une plateforme d’une telle importance nécessite une protection des données de niveau entreprise. 

Nous sommes ravis d’annoncer aujourd’hui la disponibilité générale de HYCU Backup and Recovery for Azure DevOps, une solution spécialement conçue pour la protection des données et la restauration granulaire de la plateforme via laquelle vos équipes déploient leurs produits. 

Pourquoi la protection d’Azure DevOps est-elle essentielle 

Lorsque les équipes réfléchissent à la protection d’Azure DevOps, elles pensent aux référentiels. Or, ceux-ci ne constituent qu’une petite partie du problème. La partie bien plus importante réside dans le système de déploiement qui les entoure. 

• Le plan, l’historique et la configuration n’existent que dans le service. Les éléments de travail contiennent les exigences, les décisions, les commentaires et l’historique complet des révisions. Les tableaux, les backlogs, les requêtes, les tableaux de bord, les modèles de processus et les types d’éléments de travail personnalisés ont nécessité des années de développement et ne se trouvent dans aucun clone. Ils sont recréés à partir de la mémoire, des tickets et des captures d’écran. 
• Sans l’automatisation, la livraison s’arrête. Les définitions de pipeline, les groupes de variables, les environnements, les files d’attente d’agents et les hooks de service permettent de transformer le code fonctionnel en logiciel livrable. Si vous les perdez, le code reste intact, mais rien n’est livré.
• Les preuves d’audit sont détruites. Dans le cadre d’un développement soumis à une réglementation, les éléments de travail et les plans de test constituent le registre de traçabilité entre les exigences et les tests qu’un auditeur exige. Si vous ne pouvez pas le produire, vous vous exposez à une constatation d’audit et à un retard de mise en production, le temps que quelqu’un reconstitue la documentation.  
• Les jetons et les extensions ont une portée bien plus étendue que ce que l’on pourrait croire. Un jeton d’accès personnel, un compte de service ou une extension du Marketplace dotée d’autorisations étendues peut accéder à bien plus de ressources et causer bien plus de dégâts que ne l’avait prévu la personne qui l’a créé. Le jeton d’un ingénieur ayant quitté l’entreprise est souvent l’identifiant dont dépend un pipeline critique.
• La récupération native est bien réelle, mais elle présente des limites. Une organisation ou un projet supprimé est récupérable pendant 28 jours, un référentiel pendant 30 jours, les plans et suites de test pendant 14 jours, et il n’existe aucune restauration à un instant donné. Un script qui appelle l’API de suppression avec le paramètre « destroy » contourne la corbeille, et la documentation de Microsoft elle-même prévient que ces éléments de travail ne peuvent pas être récupérés. Pour le reste, Microsoft est catégorique : « Nous ne prenons pas en charge la restauration des ressources que les clients suppriment accidentellement. » 

Ce qui rend Azure DevOps difficile à protéger par vous-même

• Cinq services, cinq modèles de données. « Repos » est un graphe d’objets Git. « Boards » est un référentiel de suivi des tâches. Pipelines correspond à des métadonnées de définition. Les plans de test sont des éléments de travail qui se comportent différemment des autres éléments de travail. Les artefacts sont des charges utiles de paquets binaires. Chacun nécessite sa propre méthode de capture et son propre chemin d’écriture ; par conséquent, aucune exportation unique ne permet d’obtenir une copie utilisable.
• Le schéma est une donnée, et il doit être récupéré en premier. Un modèle de processus définit chaque type d’élément de travail, chaque champ, chaque règle et chaque état du projet. Les éléments de travail en sont des instances. Si vous les restaurez avant que le schéma n’existe, ils n’auront nulle part où être stockés.
• Un pipeline dépend d’éléments stockés ailleurs. Une définition de build résout ses groupes de variables, ses connexions de service, ses groupes de tâches et ses environnements à partir des paramètres du projet, et ses files d’attente d’agents à partir des paramètres de l’organisation. Si vous sauvegardez la définition seule, vous obtenez un pipeline qui ne peut pas s’exécuter ; la protection doit donc couvrir les deux portées, qu’Azure DevOps maintient séparées.
• Les wikis sont des dépôts déguisés. Un wiki est un dépôt Git surmonté d’un enregistrement au niveau du service ; il ne s’agit donc ni purement de code, ni purement de contenu. Le protéger implique de le traiter comme les deux à la fois. 

Si une sauvegarde capture les objets sans enregistrer la manière dont ils s’articulent entre eux, ce que vous récupérez est un projet sur lequel personne ne peut travailler. 

HYCU R-Cloud pour Azure DevOps : Récupérez exactement ce qui a été endommagé 

HYCU pour Azure DevOps est conçu pour répondre au déroulement habituel de ces incidents : un élément important est supprimé ou corrompu, et quelqu’un s’en rend compte plus tard. Voici ce que cela signifie concrètement : 

• Protection complète du système de livraison : La plupart des outils protègent le référentiel. R-Cloud protège également tout ce qui l’entoure : les éléments de travail et leur historique, les tableaux et les requêtes, les définitions de pipeline, les wikis, les plans de test et les paramètres de l’organisation. 
• Le schéma est inclus dans la sauvegarde : Les modèles de processus et les types d’éléments de travail personnalisés sont protégés au même titre que les éléments de travail qui en découlent ; ainsi, la structure dans laquelle le travail a été créé est récupérable, sans qu’il soit nécessaire de la reconstruire de mémoire. 
• Récupération à tous les niveaux : Que vous ayez besoin d’un élément de travail, d’un référentiel, d’un pipeline, d’un projet complet ou des paramètres de votre organisation, R-Cloud gère tout cela depuis la même plateforme. Les restaurations s’effectuent sur place, ce qui permet aux équipes non concernées de poursuivre leur travail sans interruption. 
• Des preuves qui perdurent au-delà de la période de conservation : L’historique des builds et des versions, les exécutions de tests et le journal d’audit de l’organisation sont enregistrés et exportables ; ainsi, lorsqu’un auditeur vous interroge sur une version datant de dix-huit mois, vous pouvez toujours lui montrer ce qui a été livré, ce qui a été testé et qui a modifié quoi. 
• Immuabilité au niveau du stockage : Le verrouillage d’objet et l’immuabilité WORM sont disponibles, et les identifiants Azure DevOps n’ont pas accès à la sauvegarde ; ainsi, un jeton compromis ou une erreur de l’administrateur n’a aucune incidence sur celle-ci. 
• Votre stockage, votre contrôle : Les sauvegardes sont stockées dans un espace de stockage qui vous appartient, au sein de votre compte et de votre région.  
• Conservation flexible : C'est vous qui décidez de la durée de conservation des copies, indépendamment de la période de 28 jours que la plateforme vous accorde. 
• Protection Microsoft unifiée : Azure DevOps, Microsoft 365, Entra ID, Azure et GitHub protégés depuis une seule plateforme, dans un cadre de politique unique, avec un point de gestion unique pour la restauration. 

Le système via lequel votre entreprise effectue ses livraisons mérite le même niveau de protection des données que tout autre système critique de votre organisation.

Découvrez une restauration en action

Prêt à le tester sur votre propre organisation Azure DevOps ?

Essayez cette visite autoguidée pour découvrir comment récupérer les éléments perdus en quelques minutes.