Freigeben über

Ändern der Projektsichtbarkeit in öffentliche oder private

  • Artikel

Azure DevOps Services

In diesem Artikel erfahren Sie, wie Sie die Sichtbarkeit Ihres Projekts in öffentlich oder privat ändern.

Wenn Sie ein privates Projekt in die öffentliche Sichtbarkeit wechseln, werden alle inhalte öffentlich. Es ist nicht möglich, bestimmte Repositorys, Bereichspfade oder Buildordner selektiv privat zu halten.

Sicherheit

Wenn Sie ein privates Projekt in öffentliche Projekte umstellen, treten die folgenden Änderungen auf:

  • Berechtigungen: Berechtigungen, die als "Verweigern" gekennzeichnet sind, werden nicht erkannt. Nonmembers erhalten automatisch eine Mindeststufe an Funktionen, die jedem Projektmitglied zugewiesen werden können.
  • Buildpipeline: Wenn eine Buildpipeline auf den Project-Sammlungsbereich festgelegt ist, wird sie stattdessen mit einem Project-Bereich ausgeführt, wodurch das Risiko verringert wird, dass böswillige Benutzer Zugriff auf das Authentifizierungstoken des Builddiensts erhalten.
  • Projektbeteiligte:
    • Repos: Projektbeteiligte haben vollzugriff auf diese Features in öffentlichen Projekten, haben aber keinen Zugriff in privaten Projekten.
    • Boards: Projektbeteiligte haben vollzugriff in öffentlichen Projekten, aber nur teilweisen Zugriff in privaten Projekten. Weitere Informationen finden Sie unter Kurzreferenz zu Beteiligtenzugriff.
  • Benutzer mit Standard- und Testplänen: Benutzer von Standard- und Testplänen können Tests über Testpläne anzeigen und ausführen. Grundlegende Benutzer können ihre Zugriffsebene auf Basic + Testpläne aktualisieren, um vollzugriff zu erhalten, einschließlich der Funktion zum Erstellen von Testplänen und Hinzufügen von Testfällen.

Access

Der Zugriff ist für Benutzer eingeschränkt, die nicht angemeldet sind (anonyme/öffentliche Benutzer) und Benutzer, die angemeldet sind, aber keine Mitglieder eines Projekts sind (Nichtprojektmitglieder). Beide Kategorien von Benutzern, die als Nichtmitglieder bezeichnet werden, erhalten eingeschränkten, schreibgeschützten Zugriff, wie in der folgenden Tabelle beschrieben.

Hub/Einstellungen Zugriff auf nicht verwaltete Benutzer Projektbeteiligtenzugriff Basic-Zugriff Leserzugriff Zugriff auf Mitwirkende Zugriff auf Projektadministratoren
Dashboards lesen, + viele Widgets sind nicht verfügbar partial Voll Lesen Lese-/Schreibzugriff Read-Write-Administer
Wiki Lesen Voll Voll Lesen Lese-/Schreibzugriff Read-Write-Administer
Boards Lesen partial Voll Lesen Lese-/Schreibzugriff Read-Write-Administer
Repos Lesen Voll Voll Lesen Lese-/Schreibzugriff Read-Write-Administer
Pipelines Lesen Voll Voll Lesen Lese-/Schreibzugriff Read-Write-Administer
Test Plans kein Zugriff kein Zugriff Teilweiser Zugriff Lesen Lese-/Schreibzugriff Read-Write-Administer
Benachrichtigungen kein Zugriff Voll Voll Lesen Lese-/Schreibzugriff Read-Write-Administer
Suchen, Voll Voll Voll Voll Voll Voll
Einstellungen kein Zugriff Voll Voll Lesen Lesen Read-Write-Administer

Voraussetzungen

Migrationscheckliste

Die meisten privaten Projekte enthalten eine große Menge an historischen Daten. Alte Arbeitsaufgaben, frühe Commits und frühere Buildpipelinen enthalten möglicherweise Informationen, die Sie nicht öffentlich freigeben möchten.

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

Kategorie

Leitfaden

Organisationsidentitäten und -einstellungen

Verstehen Sie, dass ein Benutzer Zugriff auf die folgenden Ressourcen und Details zum organization erhält:

  • Identitäten: Liste aller Mitglieder, die dem organization und der E-Mail-Adresse für jedes Mitglied hinzugefügt wurden.
  • Einstellungen: Schreibgeschützte Ansicht aller organization und Projekteinstellungen.
  • Verarbeiten von Metadaten: Alle Auswahllistenwerte in allen Projekten im organization.
  • Builds und Releases: Namen von Personen, die sie ausgelöst haben, plus Identitäten, einschließlich E-Mail-Adressen, die in Git-Commits eingebettet sind.
  • Commits und Arbeitselemente: Eingebettete Informationen, z. B. Vorname, Nachname und E-Mail-Adresse.

Projektübergreifende Objektverknüpfung

Überprüfen Sie, ob Verknüpfungen zwischen Projekten vorhanden sind, da Details zum verknüpften Artefakt im privaten Projekt innerhalb des öffentlichen Projekts sichtbar sind. Sie können die folgenden Linktypen verwenden: branch, build, changeset, commit, found in build, integrated in build, pull request, and versionsed item. Titel und Namen werden in den folgenden Linktypen verfügbar gemacht: versionsiertes Element, Branch, Wiki-Seite, Pull Request und Arbeitselement.

Agile Tools und Arbeitselemente

Vergewissern Sie sich, dass Ihre Arbeitselemente, auch geschlossene, keine vertraulichen Details enthalten: nicht offenbarte Sicherheitslücken, Anmeldeinformationen und Kundendaten. Arbeitselemente behalten ihren Verlauf bei, wenn sie von einem privaten zu einem öffentlichen Projekt migriert werden. Alle Diskussionen und Beschreibungen sind verfügbar. Überprüfen Sie, ob keine problematische Sprache enthält.

Vergewissern Sie sich, dass keine Ihrer Bereichspfade über spezielle gesperrte Sicherheitseinstellungen verfügt. Verweigerte Berechtigungen werden in einem öffentlichen Projekt nicht erzwungen, sodass Pfade für eingeschränkte Bereiche öffentlich werden.

Code

Vergewissern Sie sich, dass im Verlauf Ihrer Repositorys keine vertraulichen Details enthalten sind: nicht gepatchte Sicherheitsfehler, Anmeldeinformationen und Code, zu deren Verteilung Sie nicht berechtigt sind.

Alle Dateiinhalte und Commitnachrichten sind verfügbar. Überprüfen Sie, ob keine problematische Sprache enthält. Wenn Sie nicht damit vertraut sind, ein gesamtes Repository verfügbar zu machen, können Sie den Tipp zu einem anderen Projekt migrieren. Weitere Informationen finden Sie unter Anweisungen für eine Tippmigration.

Build und Release

Vergewissern Sie sich, dass keine Ihrer Pipelines vertrauliche Daten verfügbar macht: Anmeldeinformationen/Geheimnisse, obskure 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. Wenn Sie Buildpipelines zu einem neuen Projekt migrieren müssen, können Sie sie mithilfe von YAML importieren und exportieren.

Test

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

Analysen und Dashboards

Erwägen Sie die Erstellung eines Dashboard für die Öffentlichkeit. Einige Widgets sind für Nichtmitglieder nicht verfügbar .

Artefakte

Vergewissern Sie sich, dass keines der Pakete in einem der Feeds, die für das Projekt gelten, Bedenken hinsichtlich des Datenschutzes hat. Alle Pakete in den Feeds, die für das Projekt gelten, werden öffentlich. Alle vorhandenen Upstream Einstellungen der Feeds, die für das Projekt gelten, werden deaktiviert, sobald das Projekt öffentlich wird.

Erweiterungen

Überprüfen Sie, ob Erweiterungen vorhanden sind, die für die Benutzererfahrung Ihres Projekts von entscheidender Bedeutung sind. Verfügen Sie für instance über ein Steuerelement für Ihr Arbeitselementformular, das Daten auf eine 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 verfügbar gemacht hat, indem Sie sie testen. Falls nicht, bitten Sie den Erweiterungsautor, Unterstützung für Nichtmitglieder hinzuzufügen.

1. Anonymen Zugriff auf Projekte aktivieren

Bevor Sie ein privates Projekt in ein öffentliches Projekt ändern, aktivieren Sie anonymen Zugriff für Ihre Organisation, indem Sie die folgenden Schritte ausführen:

  1. Melden Sie sich bei Ihrem organization (https://dev.azure.com/{yourorganization}) an.

  2. Wählen Sie Organisationseinstellungen aus.

    Screenshot der hervorgehobenen Schaltfläche

  3. Wählen Sie "Richtlinien" aus, und aktivieren Sie dann die Sicherheitsrichtlinie "Öffentliche Projekte zulassen".

    Screenshot: Organisationseinstellungen, Seite

2. Festlegen der Projektsichtbarkeit

  1. Melden Sie sich bei Ihrem Projekt (https://dev.azure.com/{Your_Oganization}{Your_Project}).

  2. Wählen Sie project settings>Overview> the Visibility dropdown menu, choose Public or Private, and then Save.

    Screenshot: Projekteinstellungen, Übersicht, Sichtbarkeitsfluss

Eingeschränkte UI-Elemente für öffentliche Projekte

Die folgenden Benutzeroberflächenelemente werden für Nichtmitglieder ausgeblendet.

Dienst

Ausgeblendete UI-Elemente

Boards

Arbeitselemente sind verfügbar, aber Backlogs, Boards, Sprints, Abfragen und Pläne sind ausgeblendet.

Repos

Team Foundation-Versionskontrolle -Repositorys (TFVC) sind ausgeblendet.

Pipelines

Builds und Releases sind verfügbar, aber Bibliothek, Aufgabengruppen, Bereitstellungsgruppen, Pakete und XAML-Buildsystem sind ausgeblendet. Pipeline- und Task-Editoren für Build- und Releasepipelines sind nicht verfügbar. Es ist nur die Seite "Neue Releases" verfügbar, die sich in der öffentlichen Vorschau befindet.

Test Plans

Test Plans und die zugehörigen Features für manuelle und Cloudlastentests sind ausgeblendet.

Analyse

Analyseansichten sind ausgeblendet, und der OData-Feed "Analytics" wird für Nichtmitglieder nicht unterstützt. Die Power BI-Integration wird im Allgemeinen nicht unterstützt.

Einstellungen

Einstellungen und Administrative Seiten werden ausgeblendet.

Nichtmember können die folgenden Aufgaben nicht ausführen:

  • Bearbeiten oder erstellen Sie Artefakte, z. B. Dateien, Arbeitselemente und Pipelines.
  • Favoriten und folgen Sie vorhandenen Artefakten.
  • Anzeigen der E-Mail-Adressen der Projektmitglieder und anderer Kontaktinformationen; Nichtmitglieder können nur Namen und Bilder sehen. Filtern Sie außerdem Listen von Artefakten nach Identität.
  • Wechseln zwischen zwei öffentlichen Projekten in derselben Organisation; Nichtmitglieder können nur direkt zu einem öffentlichen Projekt über eine URL wechseln.
  • Führen Sie Code- oder Arbeitselementsuchen in einer organization durch.

Hinzufügen von Mitwirkenden zu einem öffentlichen Projekt

Um zu einem öffentlichen Projekt beizutragen, werden Sie als Mitglied hinzugefügt und entweder Stakeholder, Basic oder Basic + Test Plans Zugriff zugewiesen. Weitere Informationen finden Sie unter Informationen zu Zugriffsebenen.

Sie fügen Projektmitglieder auf die gleiche Weise wie für private Projekte hinzu. Stellen Sie sicher, dass Sie die Auswirkungen des Einladens eines externen Benutzers verstehen. Wenn Sie das Projekt erstellt haben, werden Sie automatisch der Gruppe Projektadministratoren zugewiesen.

Teilweise Migration

Wenn Ihre Organisation vertrauliche Materialien enthält, sollten Sie die Richtlinie für öffentliche Projekte nicht aktivieren. Es wird empfohlen, eine völlig separate Organisation zum Hosten Ihrer öffentlichen Projekte zu erstellen.

Verschieben von Arbeitselementen in ein privates Projekt

Wenn Arbeitsaufgaben vertraulich sind, können Sie sie in ein separates, privates Projekt verschieben. Projektübergreifende Links funktionieren weiterhin für Mitglieder, aber Nichtmitglieder haben keinen Zugriff auf die Inhalte, da sie sich in einem privaten Projekt befinden.

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 einem anderen organization. Die Migration von Arbeitselementen kann mithilfe des von Microsoft verwalteten Open Source WiMigrator erfolgen.

Nur Git-Tipp migrieren

Wenn ein Repository aufgrund eines problematischen Verlaufs nicht freigegeben werden kann, sollten Sie eine Nur-Tipp-Migration zu einem neuen Repository in einem anderen Projekt durchführen. Halten Sie das Projekt, das das problematische Repository enthält, privat. Erstellen Sie das neue Repository in einem Projekt, das Ihnen nichts ausmacht, öffentlich zu machen.

Warnung

  • Das neue Repository stellt keine Verbindung mit dem alten Repository her.
  • Sie können änderungen nicht einfach zwischen ihnen in Zukunft migrieren.
  • Ihr Pullanforderungsverlauf wird nicht migriert.

Führen Sie die folgenden Schritte aus, um nur den Git-Tipp zu migrieren:

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

Nächste Schritte

Mit Git codieren