0

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:

  1. 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
  2. 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?
  3. 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?
3
  • "I can't do any rewriting of the code itself" Sorry, but you have set yourself for failure. Efforts like this often rely on simplifying and modularizing codebase. Just moving files around and splitting things up without proper changes in architecture will make your pains bigger.
    – Euphoric
    Commented Jun 9, 2021 at 12:10
  • I should say: there is an additional effort to rewrite / update the codebase that will happen after this deployment change
    – redsoxfantom
    Commented Jun 9, 2021 at 12:12
  • When you have one application and one team for developing it, consider to stay with one repo. Multiple repos are better suited for individual products or components with their own life cycle their own test cycle, maybe their own team. 5GB is not that huge, and instead of making most probably wrong assumptions about Git performance, you should do somd performance tests.
    – Doc Brown
    Commented Jun 11, 2021 at 13:14

1 Answer 1

Reset to default
1

Here's the rune that I would use to guide my next steps:

"What do I want the Future State to look like, and why?"

Start by making a list of every deficiency or problem that you might need to address – and write down exactly why you think that it's a problem. Next, also write down exactly what you think that a solution to that problem must achieve in order for it to be considered "a solution."

Now, look at that list and try your best to tear it apart. Look for business risks. If "absolutely everything went wrong," just how "wrong" might it be?

Finally – engage every single one of your co-workers in the same task. Gather input from absolutely anybody and everybody.

Your Answer

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

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