2

I've started with a company as head of the web team. The previous person build custom EVERYTHING including a "CMS" that has multiple variations. Along with this hodgepodge of "systems" (with no documentation) I've also become in charge of over 200 domains. I'm currently working with the team to moderize the the processes such as adding Slack, allowing the team to use javascript libraries, moving SASS, etc.

They used SVN for version control but the last head didn't like branching because "it gets messy". SVN is such a nightmare with how it's setup I'm moving the team to GitHub.

Now, I have over 200 domains and probably about half of these if not more have a repo. The ones that don't are either hardcoded or the cms was hacked to allow multiple sites to use the same repo.

I don't really want to have 200+ private repos to maintain. I've worked the past couple of days cataloging every domain, their host, their repos, etc. Plus I've categorized them.

My original plan was to have the master branch reflect the production server and the dev branch reflect staging. The team would branch off the dev branch to do daily work. That seems daunting.

My new idea is to create repos based on my 6 categories, have a master that holds data for all sites, create site branches, and create a dev branch off each of those. Trying to wrap my head around that though.

Am I on the right track? Should I just make the 200+ repos since I can make unlimited repos? First time I've had this problem, need some advice here.

bahrep
  • 29,961
  • 12
  • 103
  • 150
dcp3450
  • 10,959
  • 23
  • 58
  • 110
  • So you have a legacy system that you don't understand (yet) and you have a new technology (git) that you don't fully understand (yet)? And you decide to switch 200 production sites before fully understanding the old system and the new technology? You have a very high chance to become "the previous person ... that left behind a hodgepodge of systems". Step back, breathe, do a good requirements analysis. – Andreas Jun 03 '16 at 10:41
  • I spent over a month with the person that left going over the legacy system, utilized my team to dig deeper into the code to get high level documentation, and worked hands on with the system. It's not that I don't understand it. It's just terrible. This guy built it by himself because he doesn't like third party or frameworks because if he didn't build it then he can't fix it (his words). Git isn't new to me, I've just never had to use with such a high capacity of projects all being worked on at the same time. – dcp3450 Jun 03 '16 at 15:33

1 Answers1

1

Should I just make the 200+ repos

That would be the natural (git) approach, allowing each repo/domain to evolve independently one from another.

That doesn't prevent you to group them into larger repos, with git submodules.

But the way you deploy those repos should be independent of the way of organize those repos (be it 200 different ones or group into 6 large ones)

Ie. Having 200 repos should not impact your deployment process, and (benefit) should allow:

  • each one to evolve, branch and tag independently one from another.
  • developers to work only one the repos they need to modify (as oppose to try and checkout only a part of the repo, which is not easy to do (sparse checkout).
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250