Checkliste für die Migration von privat zu öffentlich

Azure DevOps Services

In diesem Artikel erfahren Sie mehr über die Checkliste für die private zu öffentliche Migration, die Ihnen hilft, zu berücksichtigen, welche Daten nicht mitgliedern verfügbar gemacht werden können, bevor Sie die Sichtbarkeit Ihres privaten Projekts auf öffentliche Weise ändern. Die meisten vorhandenen privaten Projekte enthalten eine große Menge an historischen Daten. Alte Arbeitselemente, frühe Commits und frühere Buildpipelinen haben möglicherweise Inhalte, die Sie nicht öffentlich freigeben möchten.

Die prüfliste in diesem Artikel gibt an, welche Elemente Sie überprüfen möchten, bevor Sie ein Projekt öffentlich machen. Außerdem finden Sie Tipps zum Migrieren von Arbeitselementen oder Dateien zu einem neuen Projekt, sodass Sie nur aktuelle und zukünftige Inhalte verfügbar machen können.

Organisationsidentitäten und -einstellungen

Wenn Sie jemanden einladen, mitglied eines Projekts zu werden, erhält diese Person Zugriff auf zusätzliche Ressourcen und Details zur Organisation. Insbesondere haben sie Zugriff auf die folgenden Informationen.

Bereich Weitere Details, die ein Mitglied empfängt
Identities Liste aller Mitglieder, die der Organisation hinzugefügt wurden
Identities E-Mail-Kontaktinformationen für jedes Projektmitglied
Einstellungen Schreibgeschützte Ansicht aller Organisations- und Projekteinstellungen
Verarbeiten von Metadaten Alle Auswahllistenwerte in allen Projekten in der Organisation

Das Öffnen eines Projekts für die Öffentlichkeit kann auch Identitäten auf verschiedene Weise offenlegen. Builds und Versionen können die Namen von Personen anzeigen, die sie ausgelöst haben, sowie Identitäten (einschließlich E-Mail-Adressen), die in Git-Commits eingebettet sind. Git Commits und Arbeitselemente enthalten möglicherweise eingebettete Identitätsinformationen wie Vorname, Nachname und E-Mail-Adresse.

Projektübergreifende verknüpfte Objekte

In Azure DevOps können Sie Objekte verknüpfen, die in verschiedenen Projekten vorhanden sind, die in derselben Organisation definiert sind. Sie können beispielsweise einen Fehler in Project A mit einer Pullanforderung in Project B verknüpfen. Wenn Verbindungen zwischen einem öffentlichen und einem privaten Projekt vorhanden sind, sind Details zum verknüpften Artefakte im privaten Projekt innerhalb des öffentlichen Projekts sichtbar.

Die Linktypen, die verwendet werden, um diese Links zu erstellen, wie in der folgenden Abbildung dargestellt: Branch, Build, Changeset, Commit, In Build gefunden, integriert in Build, Pull-Anforderung und versioniertes Element.

Cross project link types

Fünf Arten von Projektverknüpfungslinks stellen Inhalte aus dem privaten Projekt zur Verfügung.

Verknüpfungstyp Verfügbar gemachter Inhalt
Element mit Versionsangabe Project Name, Dateinamen
Verzweigung Branchname
Wiki-Seite Dateiname
Pull Request Pull-Anforderungstitel
Arbeitselement Arbeitselementtitel

Agile Tools und Arbeitselemente

Da Arbeitselemente ihren Verlauf bei der Migration von einem privaten zu öffentlichen Projekt beibehalten, sollten Sie folgendes überprüfen:

  • Vergewissern Sie sich, dass Ihre Arbeitselemente, sogar geschlossene, vertrauliche Details nicht enthalten: Nichtermittlungsfehler, Anmeldeinformationen und Kundendaten.
  • Beachten Sie, dass alle Diskussionen und Beschreibungen verfügbar sind. Überprüfen Sie, ob keine peinliche oder problematische Sprache enthalten.
  • Vergewissern Sie sich, dass keine Ihrer Bereichspfade spezielle, gesperrte Sicherheitseinstellungen aufweisen. Die verweigerten Berechtigungen werden in einem öffentlichen Projekt nicht erzwungen, sodass eingeschränkte Bereichspfade öffentlich werden.

Tipp

Wenn Sie nicht bequem sind, die gesamte Arbeitselementdatenbank aufzudecken, verfügen Sie über Migrationsoptionen. Weitere Informationen zum Verschieben von Arbeitselementen finden Sie in den Anweisungen.

Code

  • Vergewissern Sie sich, dass Sie keine vertraulichen Details im Verlauf Ihrer Repositorys haben: Nicht gepatchte Sicherheitsfehler, Anmeldeinformationen und Code, die Sie nicht verteilen können.
  • Beachten Sie, dass alle Dateiinhalte und Commitnachrichten verfügbar sind. Überprüfen Sie, ob keine peinliche oder problematische Sprache enthalten.

Tipp

Wenn Sie kein gesamtes Repository anzeigen, können Sie den Tipp zu einem anderen Projekt migrieren. Weitere Informationen zu einer Tippmigration finden Sie in den Anweisungen.

Build und Release

  • Vergewissern Sie sich, dass keine Ihrer Pipelines vertrauliche Daten verfügbar machen: Anmeldeinformationen/Geheimnisse, verdeckte URLs und private Umgebungsnamen.
  • Vergewissern Sie sich, dass Nichtmitglieder keinen Zugriff auf Ihre privaten Feeds benötigen. Builds können weiterhin auf Feeds zugreifen, aber Nichtmitglieder können nicht mehr auf Feeds zugreifen.

Wenn Sie Buildpipelinen zu einem neuen Projekt migrieren müssen (vielleicht weil Sie Code oder Arbeitselemente verschieben), können Sie sie mithilfe von YAML importieren und exportieren.

Testen

  • Verstehen Sie, dass manuelle und Cloudlastentestfeatures nicht für Nichtmitglieder in einem öffentlichen Projekt verfügbar sind.

Analyse und Dashboards

  • Ziehen Sie das Erstellen eines Dashboards in Betracht, das für die Öffentlichkeit vorgesehen ist. Einige Widgets sind nicht für Mitglieder verfügbar, sodass sie sich nicht auf diese verlassen.

Artifacts

  • Vergewissern Sie sich, dass keine der Pakete in allen Feeds, die für das Projekt gelten, Datenschutzprobleme haben. Alle Pakete in den Feeds, die für das Projekt gelten, werden öffentlich.
  • Beachten Sie, dass öffentliche Feeds keine Upstreamquellen haben können. Alle vorhandenen vorgelagerten Einstellungen der Feeds, die im Bereich des Projekts liegen, werden deaktiviert, sobald das Projekt öffentlich wird.

Erweiterungen

Sind Erweiterungen für die Erfahrung Ihres Projekts wichtig? Haben Sie beispielsweise ein Steuerelement auf Ihrem Arbeitselementformular, das Daten auf bestimmte Weise rendert? Gibt es benutzerdefinierte Erweiterungen, die wichtige Details verfügbar machen?

  • Vergewissern Sie sich, dass der Autor jeder Erweiterung sie für Nichtmitglieder zur Verfügung gestellt hat, indem Sie sie testen.
  • Wenn nicht, bitten Sie den Erweiterungsautor, Unterstützung für Nichtmitglieder hinzuzufügen. Ausführliche Informationen finden Sie unter Erweiterungen und öffentlichem Projektsupport.

Teilmigrationstipps

Organisationen, die vertrauliche Materialien enthalten, sollten die öffentliche Projektrichtlinie nicht aktivieren. In diesem Fall empfehlen wir das Erstellen einer vollständig separaten Organisation, um Ihre öffentlichen Projekte zu hosten.

Verschieben von Arbeitselementen in ein privates Projekt

Wenn eine oder eine Handvoll Arbeitselemente vertraulich sind, können Sie sie in ein separates, privates Projekt verschieben. Projektübergreifende Links funktionieren weiterhin für Mitglieder. Nichtmitglieder verfügen nicht über Zugriff auf den Inhalt, da sie sich in einem privaten Projekt befindet.

Wenn Sie über eine große Anzahl vertraulicher Arbeitselemente verfügen, sollten Sie ihr aktuelles Projekt privat halten. Erstellen Sie stattdessen ein neues öffentliches Projekt in einer anderen Organisation. Die Migration von Arbeitselementen kann mithilfe des von Microsoft verwalteten Open Source WiMigrator durchgeführt werden.

Git-Tipp-only-Migration

Wenn ein Repository aufgrund problematischer Geschichte nicht freigegeben werden kann, sollten Sie eine tippgeschützte Migration zu einem neuen Repository in einem anderen Projekt durchführen. Das Projekt mit dem problematischen Repository sollte privat bleiben. Das neue Repository sollte in einem Projekt erstellt werden, das Sie nicht öffentlich machen.

Warnung

Das neue Repository verfügt nicht über eine Verbindung mit dem alten. Sie können änderungen in Zukunft nicht einfach migrieren. Außerdem werden Ihre Pull-Anforderungsverlauf nicht migriert.

  • Klonen Sie das vorhandene Repository: git clone <clone_URL>
  • Stellen Sie sicher, dass Sie sich im Stammverzeichnis des Repositorys befinden: cd <reponame>
  • Stellen Sie sicher, dass Sie auf der Spitze der Verzweigung sind, von der Sie beginnen möchten, in der Regel haupt: git checkout main
  • Löschen sie die Git-Daten: rmdir /s .git auf Windows, rm -rf .git unter macOS oder Linux
  • Initialisieren eines neuen Git-Repositorys: git init
  • Erstellen Sie ein neues, leeres Repository in Ihrem öffentlichen Projekt.
  • Fügen Sie das neue Repository als Remote-Ursprung hinzu: git remote add origin <new_clone_URL>
  • Pushen Sie Ihr neues Repository: git push --set-upstream origin main

Nächste Schritte