We have one GitHub repo where we're maintaining Sitecore code for 2 websites and the solution is set up on the Helix principle. We have a few Sitecore migration projects in the queue so considering those, the client wants to maintain individual GitHub repo for each website. Another reason is if in one project code coverage is not up to standard, that shouldn't effect another project so if we have a project in the individual repo, this conflict will not occur. The final destination for all files, DLLs will be the same web root directory since it's a multisite Sitecore solution.

We can have individual repo as mentioned below but what will be the deployment flow?

github-commmon-repo: This will contain common code which will be shared across projects

github-project-1-repo: This will contain project 1 specific codebase

github-project-2-repo: This will contain project 2 specific codebase

Please suggest.

  • 2
    this question is probably going to generate a lot of opinions, but the key point here is, you have 1 deployment target, use 1 repo. Splitting it as you have suggested is going to cause you a lot of effort, a lot of pain and you'll end up with an overly complex solution. Just don't do it.
    – Richard Seal
    Jun 9 '21 at 18:34
  • @RichardSeal Can you please check my comment in answer
    – Sukhjeevan
    Jun 9 '21 at 21:30

You don't need different repositories for you to separate the different projects or workstreams. Furthermore, you are creating unnecessary additional workflows when it comes to deployments for example.

In my view, you can still achieve your workflow with a single repository. What you need is a code branching strategy, such as Git Flow

Which makes sense since you will need you CI/CD pipelines to be triggered from this single repository.

To manage your code coverage and any other quality checks, set up your CI pipeline to run this automatically as part of the Pull Requests. Only merge PRs which have met your criteria.

  • Is it possible to run code coverage, Veracode scans on particular project related code only because it's common repo so in case project-1 code coverage is not up to standard , this will become blocker for project-2 PROD deployment. Also other request is that if we deploy project-1 , project-2 related files shouldn't be modified on CD server
    – Sukhjeevan
    Jun 9 '21 at 18:58
  • If you use separate code branches to isolate them, then yes, you can target code coverage per branch. Actually this is how it works
    – Julius A
    Jun 10 '21 at 9:18
  • 1
    "Also other request is that if we deploy project-1 , project-2 related files shouldn't be modified on CD server " - your client needs to learn about how single instances work. You do you, but I guarantee this will end with a hugely complicated process when it doesn't need to be.
    – Richard Seal
    Jun 10 '21 at 16:24
  • @RichardSeal Most probably we'll go with single repo only but challenge is how to take care of project specific code quality, Veracode scan etc. to avoid blocker for other projects
    – Sukhjeevan
    Jun 10 '21 at 19:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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