Answers: <p>While I haven't tried this, I suppose a solution would be to have a regular pipeline (this should work in either build or release pipelines) that would check out your repo (as it's default first step) then some scripted command that adds the desired remote and pushes to it.</p>
  <p>Some pitfalls I could see you running into:</p>
  <ul>
  <li>issues with the state of the agent work folder based repo prior to a push; but that should be reconcilable with the appropriate Git commands. If the target remotes (i.e. backups) are never being committed to by anything other than the pipeline, you hopefully won't run into conflicts</li>
  <li>arbitrary branches: I'm not a git expert, but I think there's a way to push all branches to the remote</li>
  <li>authentication: you'll obviously need to provide appropriate authentication to the target remote(s). Credentials shouldn't be stored in the scripts in plain text. Use secured pipeline (or group based) variables</li>
  <li>repo size: a huge repo will need to be cloned into the ADO agent workspace. Not a problem as long as you have the disk to support it.</li>
  </ul>
  <p>Given the needs you listed, it seems like you should consider something like AzureDevOps services in the cloud, or private GitHub repos (recently became free), etc. Why manage your own backups if the cloud can do it for you?</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-06-20T13:41:08.330Z
Answers: 2020-06-20T13:41:08.330Z
Answers: Peter
Body: <p>Inspired by <a href="https://devops.stackexchange.com/questions/11092/necessity-of-mirroring-git-repos-for-small-team-considering-switching-to-azure">Necessity of mirroring git repos for small team considering switching to Azure</a>:</p>
  
  <p>How does one use Azure Pipelines to push changes to a secondary/backup origin on push?</p>
  
  <p>Possible use cases:</p>
  
  <ul>
  <li>Need of a backup, like GitLab as backup for Azure Repos.</li>
  <li>LAN-only Azure DevOps Server makes backups to the cloud.</li>
  <li>Global teams wants lower latency and code hosted everywhere.</li>
  </ul>
  
Tags: <git><azure-devops><backup>
Title: How to push to other origins using Azure Pipelines?
UserDisplayName: Mikael Dúi Bolinder
ThreadText: # How to push to other origins using Azure Pipelines?
  
  (Asked by: username_0 on 2020-03-18)
  
  Inspired by [Necessity of mirroring git repos for small team considering switching to Azure](https://devops.stackexchange.com/questions/11092/necessity-of-mirroring-git-repos-for-small-team-considering-switching-to-azure):
  
  How does one use Azure Pipelines to push changes to a secondary/backup origin on push?
  
  Possible use cases:
  
  * Need of a backup, like GitLab as backup for Azure Repos.
  * LAN-only Azure DevOps Server makes backups to the cloud.
  * Global teams wants lower latency and code hosted everywhere.
  
  **Tags:** git, azure-devops, backup
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-06-20. Score: 1
  
  While I haven't tried this, I suppose a solution would be to have a regular pipeline (this should work in either build or release pipelines) that would check out your repo (as it's default first step) then some scripted command that adds the desired remote and pushes to it.
  
  Some pitfalls I could see you running into:
  
  * issues with the state of the agent work folder based repo prior to a push; but that should be reconcilable with the appropriate Git commands. If the target remotes (i.e. backups) are never being committed to by anything other than the pipeline, you hopefully won't run into conflicts
  * arbitrary branches: I'm not a git expert, but I think there's a way to push all branches to the remote
  * authentication: you'll obviously need to provide appropriate authentication to the target remote(s). Credentials shouldn't be stored in the scripts in plain text. Use secured pipeline (or group based) variables
  * repo size: a huge repo will need to be cloned into the ADO agent workspace. Not a problem as long as you have the disk to support it.
  
  Given the needs you listed, it seems like you should consider something like AzureDevOps services in the cloud, or private GitHub repos (recently became free), etc. Why manage your own backups if the cloud can do it for you?
  
  
  ---
  
  