One or multiple Git repos for project code, DB, etc?

[jamesbrown]

Yes, I was thinking of a dedicated artifact repo/tool. There's a bunch of them out there, nexus, artifactory, cloudrepo etc. They are designed to handle diverse content, unlike source control repos/tools. There are LFS implementations of these things, so you could configure LFS to use one of them.

[d000hg]

I hadn't realised that Git LFS integrates so tightly, that you pretend it's the same repo.

Were you talking about using a dedicated artefact store JB, or LFS? If the former, what sort of thing?

[jamesbrown]

Seems a bit of a judgement call what goes in and what doesn't. I'm going to look into Git LFS but MS themselves say:What we call 'small' and 'frequently' updated is of course somewhat subjective.

True, if it's a small number of tiny things like icons or whatever, not a big deal, but it's bad practice to pollute a source code repo with a lot of binary artifacts. In any case, you should probably have an artifact repo for your software artifacts (things that you actually deploy).

Otherwise, I agree with BDP that the nature of the architecture or separation of concerns should provide a big clue about how many repos you need. If you can deploy it independently, you probably want a separate repo for it.

There is a degree of YMMV in all of this, though.

[d000hg]

You don't want binary artifacts in a source code repo, you want an artifact repo for those.

Seems a bit of a judgement call what goes in and what doesn't. I'm going to look into Git LFS but MS themselves say:

Store small, infrequently updated binary sources in Git


Binary source files that are infrequently updated will have relatively few versions committed, and will not take up very much space provided that their file size is small. Images for the web, icons, and other smaller art assets can fall into this category. It's better to store these files in Git with the rest of your source so your team can use consistent workflow.

What we call 'small' and 'frequently' updated is of course somewhat subjective.

[BigDataPro]

If the target architecture is Microservices then probably worth having multiple repos, otherwise one would do.

[jamesbrown]

You don't want binary artifacts in a source code repo, you want an artifact repo for those.

[cannon999]

Depends on the size of the team and the size of the project. If it's a small team and a small project - monorepo makes sense. If you have several development teams and the code base is massive then you should have separate repos.

[woohoo]

Will be interesting to see what other people do.

But I tend to put most things in the same repo only projects that are actually shared between other solutions do I separate out and go to the trouble of making them nuget packages.

So, the UI, db repository, database project (db scripts, that automatically update the db when doing a release) are all in separate projects under one solution and all in same git repo. But say I have a solution for integrating with 3rd party api's etc I will put that into its own repo and reference it via nuget. That gives me the ability to version it and reference the correct version in other solutions.

Scheduled jobs or azure functions etc all go in their own repos even though they are related to the same project or client.

When source code is pushed I automatically deploy to the dev environment and the dev database is automatically updated. UAT deployment is a one click job. Live deployment is the same though it goes to staging first and I swap between staging and production manually. This is a great timesaver especially when a client has a number of whitelabel sites to update.

Not saying this is the best way to do it and open to learning but it seems to be a good balance between getting things down and reusing code etc.

[d000hg]

I've worked on projects where the entire project is in a single repository and others where source code is in one repo, database in another, and docs in a third.

Trying to rationalise things on a current project as we migrate toolsets and I wondered is there a best practice these days for how to organise things. You probably have:

• source code
• DB scripts
• Other textual things like HTML/CSS/registry scripts/JSON config
• Maybe some system data - could be XML, XLS, who knows
• Resources like icons, images, etc
• Documentation

A single git repo is conceptually nice in that you can snapshot your entire project, docs and everything, in a single commit. Great for doing a release. But I've heard the industry is tending towards repos per-component or whatever and I wondered how that's typically organised.

Not been on a greenfield project for ages to see how people do things in an ideal world?