Ändern der Projektsichtbarkeit in öffentliche oder private

Azure DevOps Services

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

Wenn Sie ein privates Projekt auf die öffentliche Sichtbarkeit umstellen, umfasst es den gesamten Inhalt. Es ist nicht möglich, bestimmte Repositorys, Bereichspfade oder Buildordner selektiv privat zu halten.

Der Zugriff ist für Benutzer eingeschränkt, die nicht angemeldet sind, häufig als anonyme oder öffentliche Benutzer bezeichnet. Es gibt auch Benutzer, die bei Azure DevOps angemeldet sind, aber nicht Teil eines Projekts sind. Beide Benutzerkategorien erhalten eingeschränkten, schreibgeschützten Zugriff, wie in der folgenden Tabelle beschrieben.

Wenn Sie ein privates Projekt in "Öffentlich" wechseln, treten bei allen Projektmitgliedern die folgenden Änderungen auf:

• Berechtigungen, die als "Verweigern" gekennzeichnet sind, werden nicht erkannt. Die Berechtigungen, die einem Nicht-Mitglied zugewiesen werden, legen ein Mindestmaß an Funktionen fest, die jedem Projektmitglied zugewiesen werden können.
• Wenn eine Buildpipeline auf den Projektsammlungsbereich 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 haben vollzugriff auf Repos - oder Codefeatures in öffentlichen Projekten, haben aber keinen Zugriff in privaten Projekten.
• Die Projektbeteiligten haben Vollzugriff auf Boards oder Arbeiten in öffentlichen Projekten, aber nur teilweisen Zugriff in privaten Projekten. Weitere Informationen finden Sie unter Kurzreferenz zu Beteiligtenzugriff.
• Basic + Test Plans Benutzer können Tests aus Test Plans oder Test anzeigen und ausführen. Einfache Benutzer müssen ihre Zugriffsebene auf Basic + Test Plans aktualisieren, um Vollzugriff zu erhalten, einschließlich der Möglichkeit, Testpläne zu erstellen und Testfälle hinzuzufügen.

Hub/Einstellungen	Zugriff auf nicht verwaltete Benutzer	Projektbeteiligtenzugriff	Basic-Zugriff	Leserzugriff	Zugriff auf Mitwirkende	Project Admin-Zugriff
Dashboards	read (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 (Arbeit)	Lesen	partial	Voll	Lesen	Lese-/Schreibzugriff	Read-Write-Administer
Repos (Code)	Lesen	Voll	Voll	Lesen	Lese-/Schreibzugriff	Read-Write-Administer
Pipelines (Build und Release)	Lesen	Voll	Voll	Lesen	Lese-/Schreibzugriff	Read-Write-Administer
Test Plans	kein Zugriff	kein Zugriff	Teilweiser Zugriff (siehe letztes Aufzählungszeichen vor der Tabelle)	Lesen	Lese-/Schreibzugriff	Read-Write-Administer
Benachrichtigungen	kein Zugriff	Vollständig	Vollständig	Überwachungsdaten	Lese-/Schreibzugriff	Read-Write-Administer
Suchen,	Voll	Voll	Voll	Voll	Voll	Voll
Einstellungen	Kein Zugriff	Vollständig	Vollständig	Lesen	Lesen	Read-Write-Administer

Voraussetzungen

• Sie müssen über eine Organisation in Azure DevOps verfügen.
• Sie müssen Mitglied der Gruppe Projektsammlungsadministratoren sein. Organisationsbesitzer sind automatisch Mitglieder dieser Gruppe.
• Grundlegendes zu Zugriffsebenen und nicht verfügbaren Features für öffentliche Projekte.
• Beachten Sie die Teilmigrationsoptionen.
• Überprüfen Sie die Elemente in der Migrationsprüfliste.

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 keiner 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 können, müssen Sie den anonymen Zugriff für Ihre organization aktivieren.

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

2. Wählen Sie Organisationseinstellungen aus.

   

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

   

2. Festlegen der Projektsichtbarkeit

1. Melden Sie sich bei Ihrem Projekt an (https://dev.azure.com/{YourOganization}{YourProject}).

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

   

Zugriffsebenen und nicht verfügbare Features für öffentliche Projekte

Ein Projektmitglied hat basierend auf der zugewiesenen Zugriffsebene Zugriff auf Features. Nichtmembern/öffentlichen Benutzern wird automatisch eingeschränkter Zugriff gewährt. Wenn Sie zu einem öffentlichen Projekt beitragen möchten, müssen Sie als Mitglied dieses Projekts hinzugefügt werden und entweder den Zugriff "Stakeholder", "Basic" oder "Basic+ Test Plans" zugewiesen werden. Zugriffsebenen bestimmen die Benutzeroberflächen, auf die Sie zugreifen können. Die Sicherheitsgruppe, denen Sie zugewiesen sind, bestimmt die Features, die Sie ausführen können. Weitere Informationen finden Sie unter Informationen zu Zugriffsebenen.

Sie fügen Projektmember auf die gleiche Weise hinzu wie bei privaten Projekten. Stellen Sie sicher, dass Sie verstehen, was es bedeutet , einen externen Benutzer zum Zugriff auf Ihr Projekt einzuladen. Wenn Sie das Projekt erstellt haben, werden Sie automatisch der Gruppe Projektadministratoren zugewiesen.

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 von Artefakten, z. B. Dateien, Arbeitsaufgaben und Pipelines
• Favoriten und Folgen vorhandener Artefakte
• Anzeigen der E-Mail-Adressen der Projektmitglieder und anderer Kontaktinformationen; Nichtmember können nur Namen und Bild sehen. Filtern von Artefakten nach Identität
• Wechseln zwischen zwei öffentlichen Projekten in derselben Organisation; Nichtmitglieder müssen direkt zu einem öffentlichen Projekt über eine URL wechseln.
• Ausführen von Code- oder Arbeitsaufgabensuchen in einer Organisation

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.

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

Verwandte Artikel

• Einschränken der Benutzersichtbarkeit für Projekte und mehr
• Löschen eines Projekts
• Hinzufügen von externen Benutzern
• Hinzufügen einer URL für Datenschutzrichtlinien