Zmienianie widoczności projektu na publiczny lub prywatny

Azure DevOps Services

Z tego artykułu dowiesz się, jak zmienić widoczność projektu na publiczny lub prywatny.

Przełączenie projektu prywatnego na widoczność publiczną obejmuje całą jego zawartość. Nie można selektywnie przechowywać niektórych repozytoriów, ścieżek obszaru ani folderów kompilacji prywatnych.

Dostęp jest ograniczony dla użytkowników, którzy nie są zalogowani, często nazywani użytkownikami anonimowi lub publicznymi. Istnieją również użytkownicy, którzy są zalogowani do usługi Azure DevOps, ale nie są częścią projektu. Obie te kategorie użytkowników mają ograniczony dostęp tylko do odczytu, jak opisano w poniższej tabeli.

Po przełączeniu projektu prywatnego na publiczny wszystkie elementy członkowskie projektu mają następujące zmiany:

• Uprawnienia oznaczone odmów nie są rozpoznawane. Uprawnienia automatycznie nadane członkom niezwiązanym ustawiają minimalny poziom możliwości, które można przypisać do dowolnego elementu członkowskiego projektu.
• Jeśli potok kompilacji jest ustawiony na zakres kolekcji projektów, jest uruchamiany z zakresem projektu, co zmniejsza ryzyko uzyskania dostępu przez złośliwych użytkowników do tokenu uwierzytelniania usługi kompilacji.
• Uczestnicy projektu mają pełny dostęp do funkcji repozytoriów lub kodu w projektach publicznych, ale nie mają dostępu do projektów prywatnych.
• Uczestnicy projektu mają pełny dostęp do tablic lub pracy w projektach publicznych, ale tylko częściowy dostęp w projektach prywatnych. Aby uzyskać więcej informacji, zobacz Stakeholder access quick reference (Dostęp uczestnika projektu — krótki przewodnik).
• Użytkownicy planów podstawowych i testowych mogą wyświetlać i uruchamiać testy z planów testów lub testów. Użytkownicy podstawowi muszą podwyższyć poziom dostępu do planów podstawowych i testowych, aby uzyskać pełny dostęp, co obejmuje możliwość tworzenia planów testów i dodawania przypadków testowych.

Koncentrator/Ustawienia	Dostęp niezwiązany z numerem	Dostęp uczestników projektu	Dostęp podstawowy	Dostęp czytelnika	Dostęp współautora	Dostęp do Administracja projektu
Pulpity nawigacyjne	odczyt (wiele widżetów nie jest dostępnych)	partial	pełne	odczyt	odczyt-zapis	read-write-administer
Witryna Wiki	odczyt	pełne	pełne	odczyt	odczyt-zapis	read-write-administer
Tablice (praca)	odczyt	partial	pełne	odczyt	odczyt-zapis	read-write-administer
Repozytoria (kod)	odczyt	pełne	pełne	odczyt	odczyt-zapis	read-write-administer
Potoki (kompilacja i wydanie)	odczyt	pełne	pełne	odczyt	odczyt-zapis	Read-Write-Administracja ister
Plany testów	brak dostępu	brak dostępu	dostęp częściowy (zobacz ostatni punktor przed tabelą)	odczyt	odczyt-zapis	Read-Write-Administracja ister
Powiadomienia	brak dostępu	Pełny	Pełny	Czytaj	odczyt-zapis	read-write-administer
Wyszukaj	pełne	pełne	pełne	pełne	pełne	pełne
Ustawienia	Brak dostępu	Pełny	Pełny	Przeczytaj	Przeczytaj	Read-Write-Administracja ister

Wymagania wstępne

• Musisz mieć organizację w usłudze Azure DevOps.
• Musisz być członkiem grupy Administracja istratorów kolekcji projektów. Właściciele organizacji są automatycznie członkami tej grupy.
• Omówienie poziomów dostępu i niedostępnych funkcji dla projektów publicznych.
• Należy pamiętać o opcjach migracji częściowej.
• Przejrzyj elementy na liście kontrolnej migracji.

Lista kontrolna migracji

Większość projektów prywatnych zawiera dużą ilość danych historycznych. Stare elementy robocze, wczesne zatwierdzenia i poprzednie potoki kompilacji mogą zawierać informacje, które nie chcesz udostępniać publicznie.

Poniższa lista kontrolna wskazuje te elementy, które warto przejrzeć przed upublicznienie projektu. Zawiera również porady dotyczące migrowania elementów roboczych lub plików do nowego projektu, dzięki czemu można uwidocznić tylko bieżącą i przyszłą zawartość.

Kategoria

Wskazówki

Tożsamości i ustawienia organizacji

Dowiedz się, że użytkownik uzyskuje dostęp do następujących zasobów i szczegółów dotyczących organizacji:

• Tożsamości: lista wszystkich członków dodanych do organizacji i adresu e-mail dla każdego członka.
• Ustawienia: widok tylko do odczytu wszystkich ustawień organizacji i projektu.
• Metadane procesu: wszystkie wartości listy wyboru we wszystkich projektach w organizacji.
• Kompilacje i wydania: nazwy osób, które je wyzwoliły, oraz tożsamości, w tym adresy e-mail osadzone w zatwierdzeniach usługi Git.
• Zatwierdzenia i elementy robocze: informacje osadzone, takie jak imię, nazwisko i adres e-mail.

Łącza między obiektami projektu

Sprawdź, czy istnieją łącza między projektami, ponieważ szczegółowe informacje o połączonym artefaktie w projekcie prywatnym są widoczne w projekcie publicznym. Można użyć następujących typów linków: gałąź, kompilacja, zestaw zmian, zatwierdzenie, znalezione w kompilacji, zintegrowane w kompilacji, żądanie ściągnięcia i wersja elementu. Tytuły i nazwy są widoczne w następujących typach linków: element wersji, gałąź, strona typu wiki, żądanie ściągnięcia i element roboczy.

Narzędzia agile i elementy robocze

Upewnij się, że elementy robocze, nawet zamknięte, nie zawierają poufnych szczegółów: nieujawnione wady zabezpieczeń, poświadczenia i dane klienta. Elementy robocze zachowują swoją historię podczas migracji z projektu prywatnego do publicznego. Dostępne są wszystkie dyskusje i opisy. Sprawdź, czy żadna z nich nie zawiera problematycznej mowy.

Upewnij się, że żadne ze ścieżek obszaru nie ma specjalnych, zablokowanych ustawień zabezpieczeń. Odmowa uprawnień nie jest wymuszana w projekcie publicznym, dlatego ścieżki z ograniczeniami obszaru stają się publiczne.

Kod

Upewnij się, że nie masz poufnych informacji w historii repozytoriów: niesprawdzone usterki zabezpieczeń, poświadczenia i kod, którego nie masz prawa do rozpowszechniania.

Dostępna jest cała zawartość pliku i komunikaty zatwierdzenia. Sprawdź, czy żadna z nich nie zawiera problematycznej mowy. Jeśli nie masz pewności co do uwidaczniania całego repozytorium, możesz zmigrować poradę do innego projektu. Aby uzyskać więcej informacji, zobacz Instrukcje dotyczące migracji porad.

Kompilowanie i wydawanie

Upewnij się, że żaden z potoków nie uwidacznia poufnych danych: poświadczenia/wpisy tajne, niejasne adresy URL i nazwy środowisk prywatnych.

Upewnij się, że liczba nieczłonków nie wymaga dostępu do prywatnych źródeł danych. Kompilacje nadal mogą uzyskiwać dostęp do kanałów informacyjnych, ale nie można ich użyć. Jeśli musisz przeprowadzić migrację potoków kompilacji do nowego projektu, możesz je zaimportować i wyeksportować przy użyciu języka YAML.

  Test

Dowiedz się, że funkcje testowania obciążenia ręcznego i chmurowego nie są dostępne dla elementów innych niż w projekcie publicznym.

Analiza i pulpity nawigacyjne

Rozważ utworzenie pulpitu nawigacyjnego przeznaczonego dla społeczeństwa. Niektóre elementy widget są niedostępne dla nienumerowanych elementów.

Artefakty

Upewnij się, że żadne pakiety w żadnym z kanałów informacyjnych, które są objęte zakresem projektu, mają obawy dotyczące prywatności. Wszystkie pakiety w kanałach informacyjnych, które są ograniczone do projektu, stają się publiczne. Wszystkie istniejące ustawienia nadrzędne kanałów informacyjnych, które są ograniczone do projektu, są wyłączone, gdy projekt stanie się publiczny.

Rozszerzenia

Upewnij się, że istnieją jakieś rozszerzenia istotne dla środowiska projektu. Czy na przykład masz kontrolę nad formularzem elementu roboczego, który renderuje dane w określony sposób? Czy istnieją rozszerzenia niestandardowe, które uwidaczniają ważne szczegóły?

Upewnij się, że autor każdego rozszerzenia udostępnił go dla nieczłonków, testując je. Jeśli nie, poproś autora rozszerzenia o dodanie obsługi nieczłonków.

1. Włączanie anonimowego dostępu do projektów

Aby można było zmienić projekt prywatny na projekt publiczny, musisz włączyć dostęp anonimowy dla organizacji.

1. Zaloguj się do organizacji (https://dev.azure.com/{yourorganization}).

2. Wybierz pozycję Ustawienia organizacji.

   

3. Wybierz pozycję Zasady, a następnie włączzasady zabezpieczeń Zezwalaj na projekty publiczne.

   

2. Ustawianie widoczności projektu

1. Zaloguj się do projektu (https://dev.azure.com/{YourOganization}{YourProject}).

2. Wybierz pozycję Ustawienia projektu>— przegląd> menu rozwijanego Widoczność, wybierz pozycję Publiczny lub Prywatny, a następnie pozycję Zapisz.

   

Poziomy dostępu i niedostępne funkcje dla projektów publicznych

Członek projektu ma dostęp do funkcji na podstawie przypisanego poziomu dostępu. Użytkownicy niebędący członkami/użytkownikami publicznymi mają automatycznie ograniczony dostęp. Aby współtworzyć projekt publiczny, musisz dodać go jako członka tego projektu i przypisać dostęp do projektu Uczestnik projektu, Podstawowy lub Podstawowy lub Podstawowy i TestOwy. Poziomy dostępu określają interfejsy użytkownika, do których można uzyskać dostęp. Przypisana grupa zabezpieczeń określa funkcje, które można wykonać. Aby uzyskać więcej informacji, zobacz About access levels (Informacje o poziomach dostępu).

Możesz dodawać członków projektu w taki sam sposób, jak w przypadku projektów prywatnych. Upewnij się, że rozumiesz, co to znaczy zaprosić użytkownika zewnętrznego do uzyskania dostępu do projektu. Jeśli projekt został utworzony, zostanie automatycznie przypisany do grupy Project Administracja istrators.

Następujące elementy interfejsu użytkownika są ukryte dla elementów innych niż.

Usługa

Ukryte elementy interfejsu użytkownika

Tablice

Elementy robocze są dostępne, ale listy prac, tablice, przebiegi, zapytania i plany są ukryte.

Repos

repozytoria Kontrola wersji serwera Team Foundation (TFVC) są ukryte.

Pipelines

Kompilacje i wydania są dostępne, ale biblioteka, grupy zadań, grupy wdrożeń, pakiety i system kompilacji XAML są ukryte. Edytory potoków i zadań dla potoków kompilacji i wydania są niedostępne. Dostępna jest tylko nowa strona Wydania, która jest dostępna w publicznej wersji zapoznawczej.

Test Plans

Plany testów oraz skojarzone funkcje testowania obciążenia ręcznego i chmurowego są ukryte.

Analiza

Widoki analizy są ukryte, a źródło danych OData analizy nie jest obsługiwane w przypadku numerów innych niż. Integracja usługi Power BI w ogóle nie jest obsługiwana.

Ustawienia

Ustawienia i strony administracyjne są ukryte.

Liczba nie może wykonywać następujących zadań:

• Edytowanie lub tworzenie artefaktów, takich jak pliki, elementy robocze i potoki
• Ulubione i obserwowanie istniejących artefaktów
• Wyświetl adresy e-mail członków projektu i inne informacje kontaktowe; liczba nieczłonków może wyświetlać tylko nazwę i obraz. Ponadto filtruj listy artefaktów według tożsamości
• Przełączanie między dwoma publicznymi projektami w tej samej organizacji; spoza sekcji musi przejść bezpośrednio do projektu publicznego przy użyciu adresu URL
• Wykonywanie wyszukiwania kodu lub elementu roboczego w organizacji

Migracja częściowa

Jeśli organizacja zawiera poufne materiały, nie należy włączać zasad projektów publicznych. Zalecamy utworzenie całkowicie oddzielnej organizacji do hostowania projektów publicznych.

Przenoszenie elementów roboczych do projektu prywatnego

Jeśli jakiekolwiek elementy robocze są wrażliwe, możesz przenieść je do oddzielnego, prywatnego projektu. Linki między projektami nadal działają dla członków, ale nie ma dostępu do zawartości, ponieważ znajduje się ona w projekcie prywatnym.

Jeśli masz dużą liczbę poufnych elementów roboczych, rozważ zachowanie bieżącego projektu jako prywatnego. Zamiast tego utwórz nowy projekt publiczny w innej organizacji. Migrowanie elementów roboczych można wykonać przy użyciu biblioteki WiMigrator typu open source obsługiwanej przez firmę Microsoft.

Migrowanie tylko porad usługi Git

Jeśli nie można udostępnić repozytorium z powodu problematycznej historii, rozważ przeprowadzenie migracji tylko do nowego repozytorium w innym projekcie. Zachowaj prywatny projekt zawierający problematyczne repozytorium. Utwórz nowe repozytorium w projekcie, które nie ma nic przeciwko upublicznieniu.

Ostrzeżenie

• Nowe repozytorium nie łączy się ze starym repozytorium.
• Nie można łatwo migrować zmian między nimi w przyszłości.
• Historia żądań ściągnięcia nie jest migrowana.

1. Sklonuj istniejące repozytorium: git clone <clone_URL>.
2. Upewnij się, że jesteś w katalogu głównym repozytorium: cd <reponame>.
3. Upewnij się, że znajdujesz się na wierzchołku gałęzi, od której chcesz zacząć od: git checkout main.
4. Usuń dane git: rmdir /s .git w systemie Windows, rm -rf .git w systemie macOS lub Linux.
5. Zainicjuj nowe repozytorium Git: git init.
6. Utwórz nowe, puste repozytorium w projekcie publicznym.
7. Dodaj nowe repozytorium jako zdalne źródło: git remote add origin <new_clone_URL>.
8. Wypchnij nowe repozytorium: git push --set-upstream origin main.

Następne kroki

Kod za pomocą usługi Git

Powiązane artykuły

• Ogranicz widoczność użytkowników dla projektów i nie tylko
• Usuwanie projektu
• Dodawanie użytkowników zewnętrznych
• Dodawanie adresu URL zasad ochrony prywatności