Skip to content

Latest commit

 

History

History
87 lines (72 loc) · 4.32 KB

9.3. Azure Repos.md

File metadata and controls

87 lines (72 loc) · 4.32 KB
Raw

Azure Repos

  • Supports git, TFVC
    • TFVC = Team Foundation Version Control
      • branches = paths
      • more granular permissions down to file level
  • In Azure DevOps we have Azure Repos
    • It comes with default repository for the project
  • You can import repositories form GitHub, TFVC..
  • You can create PRs in either direction: from fork to upstream, or upstream to fork.
    • Most common = From fork to upstream
    • The destination repository's permissions, policies, builds, and work items will apply to the PR.

Service connections

  • Helps you to connect to external and remote services to execute tasks in a job.
    • e.g. connect to Microsoft Azure subscription, to services you install on remote computers.
  • Created at project scope
  • Permissions
    • User: Creator, Reader, User, Administrator roles
    • Pipeline: Which pipelines can access
    • Project permissions: which other projects can access the project (only its project scope by default)

Permissions

  • Azure Repos supports Git and Team Foundation
    • In Team Foundation Version Control, you can set permissions at the file level.
    • Git is more popular and have better compatibility with IDE's
  • You can grant permissions for Azure repositories at both the repository an the branch level.

Groups

  • Reader: Clone, fetch, explore contents of a repository. Can also create, comment on, vote and contribute to pull requests.
  • Contributor & Build Admins: Contribute to a repository, create branches, create tags, manage notes.
  • Project Admins: Create, delete and rename repositories.
  • You can modify permissions in each group.

Branch policies

  • Require minimum number of reviewers for pull requests
  • Check for linked work items: Enforce traceability to check for linked work items on PR's
  • Check for comment resolution: Check that all comments have been resolved on PR's
  • Enforce a merge strategy
    • No fast-forward merge: merges the commit history of the source branch when the pull request closes and creates a merge commit in the target branch.
    • Squash merge: Complete all pull requests with a squash merge
  • Build validation through build policies
    • It's a pre-merging policy, only if build success then PR will be able to merged
    • You link to a build pipeline that'll be triggered
  • Require approval from additional services using PR Status API
  • Automatically include code reviewers for specific directories and files in your repo
  • Bypass policies: You can assign following to users / groups when
    • completing pull requests
    • or pushing

Branch locks

  • Block updates to a Git branch by preventing
    • Other users from changing the existing commit history
    • Any new commits from being added to the branch by others
  • 💡 Use with branch policies and pull requests to ensure no changes are being done without review/approval
  • Locks can be removed by
  • 👀 Read more: Microsoft Docs

Repository settings

  • Validates commit information against given patterns or limits
  • Can be found on portal: "Project settings -> Repositories"
  • Include
    • Commit author email validation
    • File path validation
    • Case enforcement by blocking that change name casing on paths/branches/tags
    • Reserved names by blocking reserved names/incompatible characters
    • Maximum path length

Authenticating with Git

  • You can authenticate using:
    • SSH
    • Git Credential Managers
      • 💡 Recommended
      • Supports MFA
    • Personal Access Token (PAT)
      • Clone using git clone https://anything:{yourPAT}@dev.azure.com/yourOrgName/yourProjectName/_git/yourRepoName
      • You can also save your PAT in Git Credential Managers