3 ms·

Relying solely on one platform for your organization's code repository needs is a bad thing in general. I have a workflow where I host my own Gogs instance on a

by udia 9y ago

Relying solely on one platform for your organization's code repository needs is a bad thing in general. I have a workflow where I host my own Gogs instance on a raspberry pi, as well as on Github. Maybe this would be useful to you? I've configured my push such that it will deploy to both Github and on my Gogs meaning that I always have an up to date repository in two places. https://github.com/gogits/gogs https://github.com/gogits/gogs (if you're interested in setting up your own) https://stackoverflow.com/questions/14290113/git-pushing-code-to-two-remotes https://stackoverflow.com/questions/14290113/git-pushing-cod... (push to two remotes) You don't have to use just BitBucket, or rely entirely on your self hosted git service.

simlevesque 9y ago
That's what I wanted to do. Thank you for the guide !
foxylion 9y ago
I think hosting the repository is one thing. But integrating those two repositories with all the automated workflows is quite a headache. Jenkins won't automatically switch over to another git backend if one fails. Other automated tools like code review are mostly relying on a centralized repostiory. I don't see any simple solution to solve these issues. Bitbucket, GitHub, GitLab don't have any easy fallback solutions when you relying core workflows on their services. Self hosting is maybe one solution (we do this with bitbucket), but this requires major administrative effort to keep it running reliably (always available, no data losses on hardware/software failures).
- udia 9y ago
  I agree. Having CI with multiple git repositories is still a painful thing. (I continue to rely primarily on GitHub here. My backup repos don't have CI enabled.) I think if your primary repo that's hooked into CI goes down, you're still SOL. Having your own repo just enables you to continue local development among your team. I don't see any great solution, other than making your app distributed to begin with and doing your build/deploy manually. As a complete aside, I've fantasized about deploying to all cloud vendors (Azure/GCE/AWS/Heroku/DigitalOcean/misc.) each with their own specific build/deploy and having persistent state shared with something like CockroachDB. Having some load balancer managing state between all instances. Taking advantage of the free/basic tiers provided by all of the vendors.

by udia 9y ago

simlevesque 9y ago

That's what I wanted to do. Thank you for the guide !

foxylion 9y ago

I think hosting the repository is one thing. But integrating those two repositories with all the automated workflows is quite a headache. Jenkins won't automatically switch over to another git backend if one fails. Other automated tools like code review are mostly relying on a centralized repostiory. I don't see any simple solution to solve these issues. Bitbucket, GitHub, GitLab don't have any easy fallback solutions when you relying core workflows on their services. Self hosting is maybe one solution (we do this with bitbucket), but this requires major administrative effort to keep it running reliably (always available, no data losses on hardware/software failures).

udia 9y ago
I agree. Having CI with multiple git repositories is still a painful thing. (I continue to rely primarily on GitHub here. My backup repos don't have CI enabled.) I think if your primary repo that's hooked into CI goes down, you're still SOL. Having your own repo just enables you to continue local development among your team. I don't see any great solution, other than making your app distributed to begin with and doing your build/deploy manually. As a complete aside, I've fantasized about deploying to all cloud vendors (Azure/GCE/AWS/Heroku/DigitalOcean/misc.) each with their own specific build/deploy and having persistent state shared with something like CockroachDB. Having some load balancer managing state between all instances. Taking advantage of the free/basic tiers provided by all of the vendors.