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

Azure DevOps Services

この記事では、プロジェクトの可視性をパブリックまたはプライベートに変更する方法について説明します。

プライベート プロジェクトをパブリック表示に切り替えると、その内容はすべてパブリックになります。 特定のリポジトリ、エリア パス、またはビルド フォルダーをプライベートに選択的に保持することはできません。

セキュリティ

プライベート プロジェクトをパブリックに切り替えると、プロジェクト メンバーには次の変更が発生します。

• アクセス許可: Deny がマークされているアクセス許可が認識されません。 非メンバーには、任意のプロジェクト メンバーに割り当てることができる最小レベルの機能が自動的に付与されます。
• ビルド パイプライン: ビルド パイプラインが Project Collection スコープに設定されている場合は、代わりに Project スコープで実行されるため、悪意のあるユーザーがビルド サービスの認証トークンにアクセスするリスクが軽減されます。
• 利害関係者:
  • リポジトリ: 利害関係者はパブリック プロジェクトでこれらの機能にフル アクセスできますが、プライベート プロジェクトではアクセス権がありません。
  • ボード: 利害関係者はパブリック プロジェクトではフル アクセスできますが、プライベート プロジェクトでは部分的なアクセス権しか持っていません。 詳細については、「利害関係者アクセスクイック リファレンス」を参照してください。
• Basic + Test Plans ユーザー: Basic + Test Plans ユーザーは、テスト プランからテストを表示および実行できます。 Basic ユーザーは、アクセス レベルを Basic + Test Plans にアップグレードして、テスト 計画を作成し、テスト ケースを追加する機能を含め、フル アクセスを取得できます。

アクセス

アクセスは、サインインしていないユーザー (匿名/パブリック ユーザー) とサインインしているがプロジェクトのメンバーではないユーザー (非プロジェクト メンバー) に制限されます。 非メンバーと呼ばれるユーザーの両方のカテゴリには、次の表に示すように、制限付きの読み取り専用アクセス権が付与されます。

前提条件

• Permissions: Project コレクション管理者グループのメンバーになる。 組織の所有者は、自動的にこのグループのメンバーになります。
• 組織: Azure DevOps 組織 があります。
• 認識:
  • パブリック プロジェクトのアクセス レベルと利用できない機能について理解します。
  • 部分的な移行オプションに注意してください。
  • 移行チェックリストの項目を 確認します。

移行チェックリスト

ほとんどのプライベート プロジェクトには、大量の履歴データが含まれています。 古い作業項目、早期コミット、および以前のビルド パイプラインには、パブリックに共有したくない情報が含まれている場合があります。

次のチェックリストは、プロジェクトを公開する前に確認したい項目を示しています。 また、現在および将来のコンテンツのみを公開できるように、作業項目またはファイルを新しいプロジェクトに移行するためのヒントも提供します。

1. プロジェクトへの匿名アクセスを有効にする

プライベート プロジェクトをパブリック プロジェクトに変更する前に、次の手順を実行して、組織の匿名アクセスを有効にします。

1. 組織にサインインします (https://dev.azure.com/{yourorganization})。

2. [組織の設定] を選択します。

   

3. Policiesを選択し、パブリック プロジェクトセキュリティ ポリシーを有効にします。

   

2. プロジェクトの可視性を設定する

1. プロジェクトにサインインします(https://dev.azure.com/{Your_Oganization}{Your_Project})。

2. プロジェクト設定>Overview> Visibility ドロップダウン メニューを選択し、Public または Private を選択し、保存をします。

   

パブリック プロジェクト用の制限付き UI 要素

次のユーザー インターフェイス要素は、非メンバーでは非表示です。

非メンバーは、次のタスクを実行できません。

• ファイル、作業項目、パイプラインなどの成果物を編集または作成します。
• お気に入りで、既存の成果物に従います。
• プロジェクト メンバーのメール アドレスとその他の連絡先情報を表示する。非メンバーは、名前と画像のみを表示できます。 また、ID で成果物の一覧をフィルター処理します。
• 同じ組織内の 2 つのパブリック プロジェクトを切り替えます。非メンバーは、URL を使用してパブリック プロジェクトにのみ直接移動できます。
• organization全体でコードまたは作業項目の検索を実行します。

パブリック プロジェクトに共同作成者を追加する

パブリック プロジェクトに投稿するには、メンバーとして追加され、利害関係者、基本、または基本 + テスト 計画のいずれかのアクセス権が割り当てられます。 詳細については、「アクセス レベルについて」を参照してください。

プロジェクト メンバー 追加 プライベート プロジェクトの場合と同じ方法で追加できます。 外部ユーザーを招待 の影響を理解していることを確認。 プロジェクトを作成した場合は、プロジェクト管理者グループに自動的に割り当てられます。

部分的な移行

組織に機密性の高い資料が含まれている場合は、パブリック プロジェクト ポリシーを有効にしないでください。 パブリック プロジェクトをホストするために、完全に別の組織を作成することをお勧めします。

作業項目をプライベート プロジェクトに移動する

機密性の高い作業項目がある場合は、別のプライベート プロジェクトに移動できます。 プロジェクト間リンクはメンバーに対して引き続き機能しますが、メンバー以外のユーザーは、プライベート プロジェクト内に存在するため、コンテンツにアクセスできません。

機密性の高い作業項目が多数ある場合は、現在のプロジェクトを非公開にすることを検討してください。 代わりに、別のorganizationで新しいパブリック プロジェクトを作成します。 作業項目の移行は、Microsoft が管理するオープンソース WiMigrator を使用して行うことができます。

Git ヒントのみを移行する

問題のある履歴のためにリポジトリを共有できない場合は、別のプロジェクトの新しいリポジトリへのヒントのみの移行を行うことを検討してください。 問題のあるリポジトリを含むプロジェクトをプライベートのままにします。 パブリックにしても構わないプロジェクトに新しいリポジトリを作成します。

Git ヒントのみを移行するには、次の手順を実行します。

1. 既存のリポジトリを複製します: git clone <clone_URL>。
2. リポジトリのルート ( cd <reponame>) にいることを確認します。
3. 開始するブランチの先端にあることを確認します: git checkout main。
4. Git データを削除します。Windows では rmdir /s .git 、macOS または Linux では rm -rf .git 。
5. 新しい Git リポジトリ ( git init) を初期化します。
6. パブリック プロジェクトに新しい空のリポジトリを作成します。
7. 新しいリポジトリを配信元リモートとして追加します: git remote add origin <new_clone_URL>。
8. 新しいリポジトリをプッシュします: git push --set-upstream origin main。

次のステップ

関連記事

• プロジェクトなどのユーザーの可視性を制限する
• プロジェクトを削除する
• 外部ユーザーの追加
• プライバシー ポリシーの URL を追加する