Azure DevOps ist ab sofort im HYCU Marketplace verfügbar

Azure DevOps bildet das Rückgrat für die Bereitstellung bei Zehntausenden von Entwicklungsorganisationen und ist in Branchen, in denen Software unter strenger behördlicher Aufsicht bereitgestellt wird, stark vertreten. Mehr als 30.000 Unternehmen nutzen die Plattform, und viele von ihnen verwalten ihre am stärksten regulierten, geschäftskritischen Produkte darüber. Eine Plattform von dieser Bedeutung benötigt Datenschutz auf Unternehmensniveau. 

Wir freuen uns, heute die allgemeine Verfügbarkeit von HYCU Backup und Wiederherstellung für Azure DevOps – speziell entwickelte Datensicherung und granulare Wiederherstellung für die Plattform, über die Ihre Teams ihre Produkte bereitstellen. 

Warum der Schutz von Azure DevOps von entscheidender Bedeutung ist 

Wenn Teams über den Schutz von Azure DevOps nachdenken, denken sie an Repositorys. Repositorys sind jedoch nur ein kleiner Teil des Problems. Der weitaus größere Teil ist das sie umgebende Bereitstellungssystem. 

• Der Plan, die Aufzeichnungen und die Konfiguration existieren ausschließlich im Dienst. Arbeitselemente enthalten Anforderungen, Entscheidungen, Kommentare und den vollständigen Revisionsverlauf. Boards, Backlogs, Abfragen, Dashboards, Prozessvorlagen und benutzerdefinierte Arbeitselementtypen wurden über Jahre hinweg aufgebaut und befinden sich in keinem Klon. Sie werden anhand von Erinnerungen, Tickets und Screenshots neu erstellt. 
• Ohne die Automatisierung kommt die Bereitstellung zum Stillstand. Pipeline-Definitionen, Variablengruppen, Umgebungen, Agentenwarteschlangen und Service-Hooks sorgen dafür, dass aus funktionierendem Code ausgelieferte Software wird. Gehen diese verloren, bleibt der Code zwar intakt, doch es wird nichts ausgeliefert.
• Die Nachweise für die Prüfung gehen verloren. In der regulierten Entwicklung sind Arbeitselemente und Testpläne die Nachverfolgbarkeitsunterlagen für die Zuordnung von Anforderungen zu Tests, die ein Prüfer verlangt. Wenn Sie diese nicht vorlegen können, müssen Sie mit einem Audit-Befund rechnen und die Veröffentlichung wird verzögert, bis jemand die Unterlagen neu erstellt.  
• Token und Erweiterungen haben eine größere Reichweite, als man erwartet. Ein persönliches Zugriffstoken, ein Dienstkonto oder eine Marketplace-Erweiterung mit weitreichenden Berechtigungen kann weitaus mehr erreichen und zerstören, als die Person, die es erstellt hat, beabsichtigt hat. Das Token eines ausgeschiedenen Entwicklers ist oft die Anmeldeinformation, auf die sich eine kritische Pipeline stützt.
• Eine native Wiederherstellung ist möglich, unterliegt jedoch Einschränkungen. Eine gelöschte Organisation oder ein gelöschtes Projekt kann 28 Tage lang wiederhergestellt werden, ein Repository 30 Tage lang, Testpläne und Testsuiten 14 Tage lang, und eine Wiederherstellung zu einem bestimmten Zeitpunkt ist überhaupt nicht möglich. Ein Skript, das die Lösch-API mit dem Parameter „destroy“ aufruft, umgeht den Papierkorb, und Microsofts eigene Dokumentation warnt davor, dass diese Arbeitselemente nicht wiederhergestellt werden können. Im Übrigen äußert sich Microsoft unmissverständlich: „Wir unterstützen keine Wiederherstellung von Assets, die Kunden versehentlich löschen.“ 

Was macht es so schwierig, Azure DevOps auf eigene Faust

• Fünf Dienste, fünf Datenmodelle. „Repos“ ist ein Git-Objektgraph. „Boards“ ist ein Speicher für die Arbeitsverfolgung. Pipelines sind Definitionsmetadaten. Testpläne sind Arbeitselemente, die sich anders verhalten als andere Arbeitselemente. Artefakte sind binäre Paket-Nutzdaten. Jedes benötigt eine eigene Erfassungsmethode und einen eigenen Schreibpfad, sodass kein einzelner Export eine brauchbare Kopie liefert.
• Das Schema ist Daten, und es muss zuerst zurückgegeben werden. Eine Prozessvorlage definiert jeden Arbeitselementtyp, jedes Feld, jede Regel und jeden Zustand im Projekt. Arbeitselemente sind Instanzen dieser Vorlage. Stellen Sie diese wieder her, bevor das Schema vorhanden ist, da sie sonst nirgendwo abgelegt werden können.
• Eine Pipeline ist von Elementen abhängig, die an anderer Stelle gespeichert sind. Eine Build-Definition löst ihre Variablengruppen, Dienstverbindungen, Aufgabengruppen und Umgebungen aus den Projekteinstellungen auf und ihre Agentenwarteschlangen aus den Organisationseinstellungen. Wenn Sie die Definition isoliert sichern, erhalten Sie eine Pipeline, die nicht ausgeführt werden kann; daher muss der Schutz beide Bereiche umfassen, die Azure DevOps getrennt hält.
• Wikis sind Repositorys in Verkleidung. Ein Wiki ist ein Git-Repo mit einer Registrierung auf Serviceebene darüber, es handelt sich also weder um reinen Code noch um reine Inhalte. Es zu schützen bedeutet, es als beides zu behandeln. 

Wenn ein Backup die Objekte erfasst, ohne zu erfassen, wie sie zusammenpassen, erhalten Sie ein Projekt zurück, in dem niemand arbeiten kann. 

HYCU R-Cloud für Azure DevOps: Stellen Sie genau das wieder her, was beschädigt wurde 

HYCU für Azure DevOps ist speziell auf den typischen Verlauf solcher Vorfälle ausgelegt: Ein wichtiges Element wird gelöscht oder beschädigt, und erst später wird dies bemerkt. In der Praxis bedeutet dies Folgendes: 

• Umfassender Schutz des gesamten Bereitstellungssystems: Die meisten Tools schützen das Repository. R-Cloud schützt auch alles drum herum: Arbeitselemente und deren Historie, Boards und Abfragen, Pipeline-Definitionen, Wikis, Testpläne und Organisationseinstellungen. 
• Das Schema ist in der Sicherung enthalten: Prozessvorlagen und benutzerdefinierte Arbeitselementtypen werden zusammen mit den darauf basierenden Arbeitselementen geschützt, sodass die Struktur, in der die Arbeit erstellt wurde, wiederhergestellt werden kann, anstatt sie aus dem Gedächtnis neu aufbauen zu müssen. 
• Wiederherstellung auf jeder Ebene: Ganz gleich, ob Sie ein Arbeitselement, ein Repository, eine Pipeline, ein komplettes Projekt oder Ihre Organisationseinstellungen benötigen – R-Cloud wickelt dies alles über dieselbe Plattform ab. Die Wiederherstellung erfolgt an Ort und Stelle, sodass die nicht betroffenen Teams ihre Arbeit währenddessen fortsetzen können. 
• Nachweise, die über den Prüfungszeitraum hinaus Bestand haben: Der Build- und Release-Verlauf, Testläufe sowie das Audit-Protokoll der Organisation werden erfasst und können exportiert werden. Wenn ein Prüfer also nach einem Release von vor achtzehn Monaten fragt, können Sie dennoch nachweisen, was ausgeliefert wurde, was getestet wurde und wer welche Änderungen vorgenommen hat. 
• Unveränderlichkeit auf Speicherebene: Objektsperren und WORM-Unveränderlichkeit sind verfügbar, und Azure DevOps-Anmeldedaten haben keinen Zugriff auf das Backup; somit können sich ein kompromittiertes Token oder ein Fehler des Administrators nicht darauf auswirken. 
• Ihr Speicher, Ihre Kontrolle: Backups werden in Ihrem eigenen Speicher, in Ihrem Konto und in Ihrer Region gespeichert.  
• Flexible Aufbewahrungsdauer: Sie entscheiden, wie lange Kopien aufbewahrt werden – unabhängig von dem 28-tägigen Zeitfenster, das Ihnen die Plattform zur Verfügung stellt. 
• Einheitlicher Microsoft-Schutz: Azure DevOps, Microsoft 365, Entra ID, Azure und GitHub – geschützt über eine einzige Plattform, unter einem einheitlichen Richtlinienrahmen und mit einer zentralen Verwaltungsstelle für die Wiederherstellung. 

Das System, über das Ihr Unternehmen seine Produkte ausliefert, verdient denselben Datenschutz wie jedes andere geschäftskritische System in Ihrem Unternehmen.

Sehen Sie sich eine Wiederherstellung in Aktion an

Sind Sie bereit, dies anhand Ihrer eigenen Azure DevOps-Organisation zu überprüfen?

Nutzen Sie diese selbstgeführte Tour an, um zu erfahren, wie Sie die verlorenen Elemente innerhalb weniger Minuten wiederherstellen können.