プロジェクトの可視性をパブリックまたはプライベートに変更する

[アーティクル]
12/06/2023

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 .git Linux) を削除します。
新しい Git リポジトリを初期化します git init。
パブリックプロジェクトに新しい空のリポジトリを作成します。
新しいリポジトリを配信元リモートとして追加します git remote add origin <new_clone_URL>。
新しいリポジトリをプッシュします。 git push --set-upstream origin main

次のステップ

Git を使用したコード

次の方法で共有

プロジェクトの可視性をパブリックまたはプライベートに変更する