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.
Gdy przełączysz projekt prywatny na publiczny wgląd, cała jego zawartość stanie się publiczna. Nie można selektywnie przechowywać niektórych repozytoriów, ścieżek obszaru ani folderów kompilacji prywatnych.
Zabezpieczenia
Po przełączeniu projektu prywatnego na publiczny członkowie projektu doświadczają następujących zmian:
- Uprawnienia: Uprawnienia oznaczone jako Odmowa nie są rozpoznawane. Liczba nieczłonków jest automatycznie przydzielana minimalnemu poziomowi możliwości, które można przypisać do dowolnego członka projektu.
- Potoki kompilacji: jeśli potok kompilacji jest ustawiony na zakres kolekcji projektów, jest uruchamiany z zakresem projektu , co zmniejsza ryzyko uzyskania przez złośliwych użytkowników dostępu do tokenu uwierzytelniania usługi kompilacji.
- Uczestnicy projektu:
- Repozytoria: Uczestnicy projektu mają pełny dostęp do tych funkcji w projektach publicznych, ale nie mają dostępu do projektów prywatnych.
- Zarządy: Uczestnicy projektu mają pełny dostęp do projektów 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: użytkownicy planów podstawowych i testowych mogą wyświetlać i uruchamiać testy z planów testów. Użytkownicy podstawowi mogą podwyższyć poziom dostępu do planów podstawowych i testowych, aby uzyskać pełny dostęp, w tym możliwość tworzenia planów testów i dodawania przypadków testowych.
Access
Dostęp jest ograniczony dla użytkowników, którzy nie są zalogowani (użytkownicy anonimowi/publiczni) i użytkownicy, którzy są zalogowani, ale nie są członkami projektu (członkowie nieprojektu). Obie kategorie użytkowników, określane jako liczba nieczłonkowa, mają ograniczony dostęp tylko do odczytu, jak opisano w poniższej tabeli.
| 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 administratora 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 | odczyt | partial | pełne | odczyt | odczyt-zapis | read-write-administer |
| Repos | odczyt | pełne | pełne | odczyt | odczyt-zapis | read-write-administer |
| Pipelines | odczyt | pełne | pełne | odczyt | odczyt-zapis | read-write-administer |
| Plany testów | brak dostępu | brak dostępu | dostęp częściowy | odczyt | odczyt-zapis | read-write-administer |
| Powiadomienia | brak dostępu | pełne | pełne | odczyt | odczyt-zapis | read-write-administer |
| Wyszukaj | pełne | pełne | pełne | pełne | pełne | pełne |
| Ustawienia | brak dostępu | pełne | pełne | odczyt | odczyt | read-write-administer |
Wymagania wstępne
- Uprawnienia: być członkiem grupy Administratorzy kolekcji projektów. Właściciele organizacji są automatycznie członkami tej grupy.
- Organizacja: organizacja w usłudze Azure DevOps.
- Świadomość:
- 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 ustawień zabezpieczeń zablokowanych. 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
Przed zmianą projektu prywatnego na projekt publiczny włącz anonimowy dostęp dla organizacji, wykonując następujące czynności:
Zaloguj się do swojej organizacji (
https://dev.azure.com/{yourorganization}).Wybierz pozycję Ustawienia organizacji.
Wybierz pozycję Zasady, a następnie włącz zasady zabezpieczeń Zezwalaj na projekty publiczne.
2. Ustawianie widoczności projektu
Zaloguj się do projektu (
https://dev.azure.com/{Your_Oganization}{Your_Project}).Wybierz pozycję Ustawienia projektu>— przegląd> menu rozwijanego Widoczność, wybierz pozycję Publiczny lub Prywatny, a następnie pozycję Zapisz.
Ograniczone elementy interfejsu użytkownika dla projektów publicznych
Następujące elementy interfejsu użytkownika są ukryte dla elementów innych niż.
Usługa
Ukryte elementy interfejsu użytkownika
Boards
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ń:
- Edytuj lub twórz artefakty, takie jak pliki, elementy robocze i potoki.
- Ulubione i postępuj zgodnie z istniejącymi artefaktami.
- Wyświetl adresy e-mail członków projektu i inne informacje kontaktowe; liczba nieczłonków może wyświetlać tylko nazwy i obrazy. Ponadto filtruj listy artefaktów według tożsamości.
- Przełączanie między dwoma publicznymi projektami w tej samej organizacji; spoza listy może przejść bezpośrednio do projektu publicznego tylko przy użyciu adresu URL.
- Przeprowadź wyszukiwanie kodu lub elementu roboczego w organizacji.
Dodawanie współautorów do projektu publicznego
Aby współtworzyć projekt publiczny, dodaj go jako członka i przypisz dostęp do planów Projektu podstawowego lub Podstawowego lub Podstawowego i testowego. Aby uzyskać więcej informacji, zobacz About access levels (Informacje o poziomach dostępu).
Dodasz członków projektu w taki sam sposób, jak w przypadku projektów prywatnych. Upewnij się, że rozumiesz implikacje zapraszania użytkownika zewnętrznego. Jeśli projekt został utworzony, zostanie automatycznie przypisany do grupy Administratorzy projektu.
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.
Wykonaj następujące kroki, aby zmigrować tylko poradę usługi Git:
- Sklonuj istniejące repozytorium:
git clone <clone_URL>. - Upewnij się, że jesteś w katalogu głównym repozytorium:
cd <reponame>. - Upewnij się, że znajdujesz się na wierzchołku gałęzi, od której chcesz zacząć od:
git checkout main. - Usuń dane git:
rmdir /s .gitw systemie Windows,rm -rf .gitw systemie macOS lub Linux. - Zainicjuj nowe repozytorium Git:
git init. - Utwórz nowe, puste repozytorium w projekcie publicznym.
- Dodaj nowe repozytorium jako zdalne źródło:
git remote add origin <new_clone_URL>. - Wypchnij nowe repozytorium:
git push --set-upstream origin main.