プロジェクトの可視性をパブリックまたはプライベートに変更する
Azure DevOps Services
この記事では、プロジェクトの可視性をパブリックまたはプライベートに変更する方法について説明します。
プライベート プロジェクトをパブリック可視性に切り替えると、そのすべての内容が含まれます。 特定のリポジトリ、エリア パス、またはビルド フォルダーをプライベートに選択的に保持することはできません。
アクセスは、サインインしていないユーザー (多くの場合、匿名またはパブリック ユーザーと呼ばれます) に制限されます。 Azure DevOps にサインインしているが、プロジェクトの一部ではないユーザーもいます。 次の表に示すように、これらの両方のカテゴリのユーザーには、制限付きの読み取り専用アクセス権が付与されます。
プライベート プロジェクトをパブリックに切り替えると、すべてのプロジェクト メンバーに次の変更が加えられます。
- 拒否とマークされたアクセス許可は認識されません。 メンバー以外に自動的に付与されるアクセス許可は、任意のプロジェクト メンバーに割り当てることができる最小レベルの機能を設定します。
- ビルド パイプラインが Project Collection スコープに設定されている場合は、代わりに Project スコープで実行されるため、悪意のあるユーザーがビルド サービスの認証トークンにアクセスするリスクが軽減されます。
- 利害関係者はパブリック プロジェクトのリポジトリまたはコード機能にフル アクセスできますが、プライベート プロジェクトではアクセス権がありません。
- 利害関係者は、パブリック プロジェクトでは Boards または Work にフル アクセスできますが、プライベート プロジェクトでは部分的なアクセスのみが可能です。 詳細については、「利害関係者アクセスクイック リファレンス」を参照してください。
- Basic + Test Plans ユーザーは、Test Plansまたはテストからテストを表示および実行できます。 Basic ユーザーは、フル アクセスを取得するには、アクセス レベルを Basic + Test Plans にアップグレードする必要があります。これには、テスト 計画を作成し、テスト ケースを追加する機能が含まれます。
| ハブ/設定 | 非メンバー アクセス | 利害関係者アクセス | 基本アクセス | 閲覧者アクセス | 共同作成者アクセス | プロジェクト 管理 アクセス |
|---|---|---|---|---|---|---|
| ダッシュボード | read (多くのウィジェットは使用できません) | partial | フル | 読み取り | 読み取り/書き込み | read-write-administer |
| Wiki | 読み取り | フル | フル | 読み取り | 読み取り/書き込み | read-write-administer |
| ボード (作業) | 読み取り | partial | フル | 読み取り | 読み取り/書き込み | read-write-administer |
| Repos (コード) | 読み取り | フル | フル | 読み取り | 読み取り/書き込み | read-write-administer |
| パイプライン (ビルドとリリース) | 読み取り | フル | フル | 読み取り | 読み取り/書き込み | 読み取り/書き込み/管理 |
| Test Plans | アクセスなし | アクセスなし | 部分アクセス (表の前の最後の行頭文字を参照) | 読み取り | 読み取り/書き込み | 読み取り/書き込み/管理 |
| 通知 | アクセスなし | [完全] | [完全] | 読み取り | 読み取り/書き込み | read-write-administer |
| Search | フル | フル | フル | フル | フル | フル |
| 設定 | アクセス権なし | [完全] | [完全] | Read | Read | 読み取り/書き込み/管理 |
前提条件
- Azure DevOps に組織が必要です。
- プロジェクト コレクション管理者グループのメンバーである必要があります。 組織の所有者は、自動的にこのグループのメンバーになります。
- パブリック プロジェクトのアクセス レベルと利用できない機能について理解します。
- 部分的な移行オプションに注意してください。
- 移行チェックリストの項目を 確認します。
移行チェックリスト
ほとんどのプライベート プロジェクトには、大量の履歴データが含まれています。 古い作業項目、早期コミット、および以前のビルド パイプラインには、パブリックに共有したくない情報が含まれている場合があります。
次のチェックリストは、プロジェクトを公開する前に確認したい項目を示しています。 また、現在および将来のコンテンツのみを公開できるように、作業項目またはファイルを新しいプロジェクトに移行するためのヒントも提供します。
カテゴリ
ガイダンス
組織の ID と設定
ユーザーが次のリソースにアクセスし、organizationに関する詳細を取得することを理解します。
- ID: 各メンバーのorganizationとメール アドレスに追加されたすべてのメンバーの一覧。
- 設定: すべてのorganizationとプロジェクト設定の読み取り専用ビュー。
- プロセス メタデータ: organization内のすべてのプロジェクトのすべての選択リスト値。
- ビルドとリリース: それらをトリガーしたユーザーの名前と、Git コミットに埋め込まれたメール アドレスを含む ID。
- コミットと作業項目: 名、姓、電子メール アドレスなどの埋め込み情報。
プロジェクト間のオブジェクト リンク
プライベート プロジェクト内のリンクされた成果物の詳細がパブリック プロジェクト内に表示されるため、プロジェクト間にリンクが存在するかどうかを確認します。 ブランチ、ビルド、変更セット、コミット、ビルド内にあるコミット、ビルド、プル要求、バージョン管理された項目のリンクの種類を使用できます。 タイトルと名前は、バージョン管理された項目、ブランチ、Wiki ページ、pull request、および作業項目のリンクの種類で公開されます。
アジャイル ツールと作業項目
未公開のセキュリティ上の欠陥、資格情報、顧客データなど、作業項目が閉じられているものであっても、機密性の高い詳細が含まれていないことを確認します。 作業項目は、プライベート プロジェクトからパブリック プロジェクトに移行されたときに履歴を保持します。 すべてのディスカッションと説明を利用できます。 問題のある音声が含まれていないことを確認します。
どのエリア パスにも特別なロックダウン セキュリティ設定がないことを確認します。 拒否されたアクセス許可はパブリック プロジェクトでは適用されないため、制限された領域パスはパブリックになります。
"コード"
リポジトリの履歴に機密性の高い詳細がないことを確認します。パッチが適用されていないセキュリティバグ、資格情報、および配布する権利がないコード。
すべてのファイルの内容とコミット メッセージを使用できます。 問題のある音声が含まれていないことを確認します。 リポジトリ全体の公開に慣れていない場合は、ヒントを別のプロジェクトに移行できます。
詳細については、「 ヒント移行の手順」を参照してください。
ビルドとリリース
資格情報/シークレット、あいまいな URL、プライベート環境名など、どのパイプラインも機密データを公開していないことを確認します。
メンバー以外のユーザーがプライベート フィードへのアクセスを必要としないことを確認します。 ビルドは引き続きフィードにアクセスできますが、メンバー以外はアクセスできません。 ビルド パイプラインを新しいプロジェクトに移行する必要がある場合は、 YAML を使用してそれらをインポートおよびエクスポートできます。
テスト
パブリック プロジェクトのメンバー以外は、手動およびクラウドのロード テスト機能を使用できないことを理解してください。
分析とダッシュボード
一般向けのダッシュボードを構築することを検討してください。 一部 のウィジェットは、メンバー以外では使用できません 。
アイテム
プロジェクトのスコープが設定されているフィードのどのパッケージにもプライバシーに関する懸念がないことを確認します。 プロジェクトのスコープが設定されているフィード内のすべてのパッケージがパブリックになります。 プロジェクトのスコープが設定されているフィードの既存のアップストリーム設定はすべて、プロジェクトがパブリックになると無効になります。
拡張機能
プロジェクトのエクスペリエンスに不可欠な拡張機能があるかどうかを確認します。 たとえば、特定の方法でデータをレンダリングする作業項目フォームにコントロールがありますか? 重要な詳細を公開するカスタム拡張機能はありますか?
各拡張機能の作成者が、それをテストして非メンバーで使用できるようにしたことを確認します。
そうでない場合は、拡張機能の作成者に非メンバーのサポートを追加するよう依頼してください。
1. プロジェクトへの匿名アクセスを有効にする
プライベート プロジェクトをパブリック プロジェクトに変更する前に、organizationの匿名アクセスを有効にする必要があります。
組織にサインインします (
https://dev.azure.com/{yourorganization})。[組織の設定] を選択します。
[ポリシー] を選択し、[パブリック プロジェクトを許可する] セキュリティ ポリシーをオンにします。
2. プロジェクトの可視性を設定する
プロジェクトにサインインします (
https://dev.azure.com/{YourOganization}{YourProject})。[プロジェクト設定>の概要>] の [可視性] ドロップダウン メニューを選択し、[パブリック] または [プライベート] を選択して、[保存] を選択します。
パブリック プロジェクトのアクセス レベルと使用できない機能
プロジェクト メンバーは、割り当てられたアクセス レベルに基づいて機能にアクセスできます。 非メンバー/パブリック ユーザーには、制限付きアクセスが自動的に付与されます。 パブリック プロジェクトに投稿するには、そのプロジェクトのメンバーとして追加し、利害関係者、Basic、または Basic + Test Plans アクセスを割り当てる必要があります。 アクセス レベルによって、アクセスできるユーザー インターフェイスが決まります。 割り当てられているセキュリティ グループによって、実行できる機能が決まります。 詳細については、「 アクセス レベルについて」を参照してください。
プロジェクト メンバーは、プライベート プロジェクトの場合と同じ方法で追加します。 プロジェクトへのアクセス権を 持つ外部ユーザーを招待 する意味を理解していることを確認してください。 プロジェクトを作成した場合は、プロジェクト管理者グループに自動的に割り当てられます。
次のユーザー インターフェイス要素は、非メンバーでは非表示です。
サービス
非表示の UI 要素
Boards
作業項目は使用できますが、バックログ、ボード、スプリント、クエリ、プランは非表示になります。
Repos
Team Foundation バージョン管理 (TFVC) リポジトリは非表示になっています。
Pipelines
ビルドとリリースは使用できますが、ライブラリ、タスク グループ、配置グループ、パッケージ、XAML ビルド システムは非表示になります。 ビルド パイプラインとリリース パイプラインのパイプラインエディターとタスク エディターは使用できません。 パブリック プレビュー段階の新しい [リリース] ページのみが使用できます。
Test Plans
Test Plansと、関連付けられている手動およびクラウドのロード テスト機能は非表示になります。
Analytics
Analytics ビューは非表示であり、非メンバーでは Analytics OData フィードはサポートされていません。 一般に、Power BI の統合はサポートされていません。
設定
設定と管理ページは非表示になります。
非メンバーは、次のタスクを実行できません。
- ファイル、作業項目、パイプラインなどの成果物を編集または作成する
- 既存の成果物をお気に入りに追加してフォローする
- プロジェクト メンバーのメール アドレスとその他の連絡先情報を表示する。非メンバーは名前と画像のみを表示できます。 また、ID で成果物の一覧をフィルター処理する
- 同じ組織内の 2 つのパブリック プロジェクトを切り替えます。非メンバーは、URL を使用してパブリック プロジェクトに直接移動する必要があります
- 組織全体でコードまたは作業項目の検索を実行する
部分的な移行
組織に機密性の高い資料が含まれている場合は、パブリック プロジェクト ポリシーを有効にしないでください。 パブリック プロジェクトをホストするために、完全に別の組織を作成することをお勧めします。
作業項目をプライベート プロジェクトに移動する
作業項目が機密性の高い場合は、個別のプライベート プロジェクトに移動できます。 プロジェクト間リンクはメンバーに対して引き続き機能しますが、メンバー以外のユーザーは、プライベート プロジェクト内に存在するため、コンテンツにアクセスできません。
機密性の高い作業項目が多数ある場合は、現在のプロジェクトを非公開にすることを検討してください。 代わりに、別のorganizationで新しいパブリック プロジェクトを作成します。 作業項目の移行は、Microsoft が管理するオープンソース WiMigrator を使用して行うことができます。
Git ヒントのみを移行する
問題のある履歴のためにリポジトリを共有できない場合は、別のプロジェクトの新しいリポジトリへのヒントのみの移行を行うことを検討してください。 問題のあるリポジトリを含むプロジェクトをプライベートのままにします。 パブリックにしても構わないプロジェクトに新しいリポジトリを作成します。
警告
- 新しいリポジトリは古いリポジトリに接続されません。
- 今後、それらの間で変更を簡単に移行することはできません。
- pull request 履歴は移行されません。
- 既存のリポジトリを複製します。
git clone <clone_URL> - リポジトリのルートにいることを確認します
cd <reponame>。 - 開始するブランチの先端にあることを確認します
git checkout main。 - Git データ
rmdir /s .git(Windows、macOS またはrm -rf .gitLinux) を削除します。 - 新しい Git リポジトリを初期化します
git init。 - パブリック プロジェクトに新しい空のリポジトリを作成します。
- 新しいリポジトリを配信元リモートとして追加します
git remote add origin <new_clone_URL>。 - 新しいリポジトリをプッシュします。
git push --set-upstream origin main
次のステップ
関連記事
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示