3

Question:

Are there any benefits to mirroring our git repos outside of Azure devops for a small (~7) team of developers who all work in the same office?

Background Information

I'm a developer who also wears the "DevOps" hat when he has time to do so (all the time right now). We're looking at potentially moving from our self hosted and maintained instance of Gitlab to MS Azure DevOps. My manager has stated he's interested in keeping a "forest of git nodes" for a couple different reasons.

  • One was access control (don't allow certain people to access node 'A')

  • One was that we don't want all of our code in Azure for some reason

  • One is so that we have extra backups of our code base

  • One is because "that's what git was made for, several distributed remotes. That's how Linux does it"

  • If Azure goes down we can still commit to the Gitlab repo and push that up later.

I think it's easy to tell what MY opinion of us doing this is, but I'd like others input on pros vs cons of going about structuring our git repo's in a way like stated above. From what I can tell he's thinking about the repo structure in one of the two ways shown below:

possibility #1

possibility #2

My reasoning for wanting to not bother with the mirrored repo's are the following:

  • The entire teams works in the same office, so there's no distribution of associates over multiple geographic regions. I'm also not aware that it would be changing anytime soon.

  • Adds complexity to the development environment.

  • Increases the possibility of code being out of date on one (or both) remotes. (For some background, in times before I was hired source code was getting lost.)

  • Access Control is built into both Azure DevOps AND Gitlab, so we're not getting anything new by doing that.

  • MS Backup and data retention are MUCH MORE comprehensive than what we have going on currently. Moving to them would INCREASE our probability of recovering data in case of emergency.

  • Relatedly, MS SLA is much higher than anything that I can guarantee (99.9%). Switching to Azure gets us that SLA for "free".

  • Since we're using Git as VCS, we're already working in a "distributed" manner. We don't need a mirror / second remote to push code to when we have the code locally on our machines anyway. We would simply push when connectivity was restored.

  • Admittedly selfish but, I don't want to have to worry about keeping all these tools (Nexus, Gitlab, OpenProject, all of those in containers on an unsupported Linux server that I don't have direct access to) up to date and patched. I'd rather be doing what I was hired to do, which is program.

With all of the above being said, I'm still open to having my mind changed. I'm new-ish to the development field and am very aware that I could be missing something crucial on why we would need a mirror or multiple remotes.

Improve this question
3
  • Have you considered the extra aspects of having to migrate Gitlab pipelines? Git is only a small part of what Gitlab provides and even though I haven't evaluated Azure DevOps myself I did do an extensive review of Github Actions and other solutions that didn't cut it. If all you end up using Azure for is a git repo backup then a mirror is the simple choice.
    – DavidGamba
    Jul 1, 2020 at 5:21
  • Those are actually one of the big reasons I'd want to switch. Our current pipelines (maintained by yours truly) are pretty rudimentary. We still manually deploy applications, the pipelines simply build, test, and then upload jar/wars to Nexus. We've actually moved over to AZDO for web based projects from this point forward since we don't have runners that would work with javascript on Gitlab. Moving to AZ gets us more useful runners that we (I) don't have to maintain. That's net positive for the whole group too, because I'm the only one who knows how it's all wired together currently.
    – Scrambo
    Jul 2, 2020 at 12:56
  • The runner aspect is the crucial part in my opinion. If you don't have any security constrains that limit you to using private runners and making sure that developers can't deploy to production from a branch (with GitHub actions anyone can deploy from a branch because they don't have the concept of protected branches or protected runners) then don't bother maintaining a repo. In my opinion GitHub's SOC compliance and SLA is assurance enough. And your devs still have local copies of the repo. It is when you get really serious about malicious/accidental developer activity that things get hard.
    – DavidGamba
    Oct 2, 2020 at 22:32

1 Answer 1

Reset to default
1

As you have realised Git is decentralised by design.

Using LAN repos

If Azure DevOps goes down, or your office internet connection, you can still use LAN repos. These could be simple file shares. You can also use emails to share commits; nothing I've tried but Git has native support for it). I have however pushed and pulled commits directly from and to my colleagues computers using file shares (because our online Git provider back then was extremely bad and slow (and the repos were many GB).

If you don't have automatic sync (which you can setup using pipelines/CI) between Azure DevOps and GitLab then the most up-to-date repos will reside on the developers computers which makes it easy to push the repo to a new location when needed (simply add the new remote and click push). However, if some repo hasn't been used in a long time it'll probably not exist on any developers computer and you'll therefor not be able to access it.

If you want to be disaster-ready I'd suggest hosting an Azure DevOps Server instance on your LAN that's synced with the cloud. Azure DevOps Server is capable of processing the very same yaml pipelines as the online version. You'd be protected against much more than just Azure DevOps Services outages.

The maintenance costs of having Azure DevOps Server as a backup for a small team shouldn't be much different than having GitLab as backup.

I'm not recommending these solutions, rather I'm just discussing them.

You might want to have a look at the Azure DevOps Proxy Server.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.