I've got a large, old application with a clunky, extremely manual deployment process (essentially, tribal knowledge combined with random scripts / build jobs scattered across servers). The application is largely written in C# with a little C here and there and is source controlled in one monolithic Accurev repo about 5 GB in size. The deployment artifacts are about 100 .dll and .exe files and easily over 1000 config files with environment-specific modifications (we have several dev and testing environments). Finally, we have a large Oracle database that needs to be deployed alongside.
As I'm sure you all can appreciate, wrangling this beast has been a massive issue for years, and I've finally got funding to modernize the deployment part of it. I can't do any rewriting of the code itself, but I can do things like move over to git using gitlab for hosting, implement some manner of continuous integration on gitlab runners, etc. I'm looking for any advice or whitepapers on the following:
- Splitting a large repo into multiple smaller ones - Accurev's performance has been abysmal as the repository grew and I assume git would have similar issues. I also assume that gitlab runners would not appreciate having to pull the whole thing down on each build. I'm looking for any advice about choosing the right spots to break off chunks into their own repo
- Coordinating versions between repos - The one advantage of the monorepo has been keeping everything in lockstep. Now that I'm breaking chunks off, what are the gotchas and things to watch out for when it comes to version bumps in upstream dependencies?
- Build planning - My thinking was each repo would just build itself and not worry about kicking off child repos. Child repos would version bump their dependencies which would kick off their own builds and pull the updated versions. Any advice on setting up a reliable build pipeline?