Ä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.
Melden Sie sich bei Ihrem organization (
https://dev.azure.com/{yourorganization}) an.Wählen Sie Organisationseinstellungen aus.
Wählen Sie "Richtlinien" aus, und aktivieren Sie dann die Sicherheitsrichtlinie "Öffentliche Projekte zulassen".
2. Festlegen der Projektsichtbarkeit
Melden Sie sich bei Ihrem Projekt an (
https://dev.azure.com/{YourOganization}{YourProject}).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.
- 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 sich auf der Spitze der Verzweigung befinden, von der aus Sie beginnen möchten:
git checkout main. - Löschen Sie die Git-Daten:
rmdir /s .gitunter Windows,rm -rf .gitunter 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 Ursprung remote hinzu:
git remote add origin <new_clone_URL>. - Pushen Sie Ihr neues Repository:
git push --set-upstream origin main.