Should you have one repo that has all the code needed to run your entire platform or should you break it up into smaller modules? It is a commonly debated topic among my peers. Let’s break it down:
With a single repo codebase a new developer just has to pull down one repo to have access to the full codebase. If you have a complex platform this makes it really simple to pull down everything they need to get a local environment up and running. It is very possible to do this with multiple repositories as well, it just requires a bit more setup.
If someone only needs one part of the project running locally, let's say they are just working on your mobile app, they still have to pull down a ton of code that they may never need.
Do you want every developer that touches your system to have full access to every line of code you have?
Is there something proprietary in there you wouldn’t want getting out for you competitors to see? If so you may not want that in the main codebase that new developers get access to on their first day.
Are there parts of the code that nefarious hackers might be able to engineer an attack against your system? I doubt any of your devs would intentionally leak your code but more times then I care to remember I have seen developers accidentally leak code.
Another note on security: Whichever option you choose, single repo or multiple, DO NOT CHECK CREDENTIALS,API KEYS, ETC INTO THE CODEBASE.
Let's say you have a single repo with both the mobile code and the backend code stored in it. When a developer pushes a small aesthetic change to the mobile app, depending on your setup, it will kick off the build pipeline for all the other parts of your app. That can get expensive and time consuming real quick. Yes, you can design around this but oftentimes when I come on to a single repo project focusing the build pipeline on the actual change is an afterthought if at all.
Single codebase repos are great for starting out but at a certain point as the business/project grows you most likely will need to bifurcate your codebase. Keep that in mind when structuring your codebase.
Let me know if I missed anything. I am sure there are plenty of ways of looking at this.
If you are interested in engaging my services as a Web Application Architect check out my Group Coaching Program or 1 on 1 Consulting at schematical.com and check out my FREE eBook 20 Things You Can DoTo Save Money On Your Amazon Web Services Bill Today ~Cheers
Signup for the mailing list