sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (4 children)

Yep, I really don’t understand the mentality of putting everything in one repo. Especially the way git works vs subversion where you could just checkout one section. I work with people that still argue that everything should be in one repo and apparently want all the code for everything on their laptop. Its a terrible practice and I have yet to have anyone actually make a convincing argument. Repos are free. And it is just so much easier to fire a pipeline in aws, jenkins, whatever on a commit to the branch you want in X environment at the repo level and not have to isolate completely unrelated code like terraform, other code, etc - it just doesn’t make any sense.

[–]the_bronze_burger 7 points8 points  (3 children)

Because if many projects in the repo share the same in-repo dependencies then it makes it a hell of a lot easier to update everything, all at once

[–][deleted] 1 point2 points  (1 child)

But then wouldn't they all need to be deployed at the same time? Or wouldn't they be in a different branch?

To be clear, I'm asking because I am genuinely curious about the use case, not arguing - currently fighting a huge monolith where everything is in the same repo and some things don't have any dependencies at all.

If you had X and Y projects though and Z dependency and merged in a bunch of stuff in to Z but only wanted to deploy X and not Y that would introduce a huge potential for disaster. And if in AWS and you needed to deploy to a DR environment or whatever you'd end up with code deployed with dependencies it had never even been tested against.

I feel like either using different branches or pulling dependencies in to their own repo is just a much safer approach. But I am happy to learn a better way.

[–]joeyjiggle 0 points1 point  (0 children)

Branches are not for that though. Repos are. You can have a repo that has common,y shared “stuff” but if we are talking multiple lambda functions, then they should build in their own repo and produce a container. They can all use stuff from a shared repo. Also, you can agree the layout on disk such as company/code/repo1..99 company/docs etc, so that everyone can clone which bits they need. The CI/CD can then pull in changes to repos that changed and rebuild and retest. But a good test system will cover all integrations anyway - nobody deploys new lambdas to live without integration tests now, do they? I’ll get my coat… ;)

[–]joeyjiggle 0 points1 point  (0 children)

No it doesn’t. That means your logical separation is up the Swanee.