-1

As mentioned here:

The main aim of CI is to prevent integration problems, referred to as "integration hell"

Our project is a 3-tier web application, with frontend(Angular 6), backend(Springboot) & Database layer

For front end code(Angular 6), we have one source code repository(.git)

For back end(SpringBoot), we have two source code repositories(.git)

For database layer(Java & MySQL), we have three source code repositories(.git)

Currently code has unit test cases.

As per the CI work flow mentioned in wiki,

When embarking on a change, a developer takes a copy of the current code base on which to work. As other developers submit changed code to the source code repository, this copy gradually ceases to reflect the repository code. Not only can the existing code base change, but new code can be added as well as new libraries, and other resources that create dependencies, and potential conflicts.

The longer a branch of code remains checked out, the greater the risk of multiple integration conflicts and failures when the developer branch is reintegrated into the main line. When developers submit code to the repository they must first update their code to reflect the changes in the repository since they took their copy. The more changes the repository contains, the more work developers must do before submitting their own changes.

Eventually, the repository may become so different from the developers' baselines that they enter what is sometimes referred to as "merge hell", or "integration hell",[4] where the time it takes to integrate exceeds the time it took to make their original changes.

Continuous integration involves integrating early and often, so as to avoid the pitfalls of "integration hell". The practice aims to reduce rework and thus reduce cost and time.

1) To perform integration tests, s it recommended to have source code(angular_frontend/java_back_end/database) in a single repo(.git)?

2) Is it a good practice to maintain single source code repository for complete code(fullstack)? for running CI/CD pipeline...

overexchange
  • 2,245
  • 2
  • 17
  • 47
  • 3
    Possible duplicate of [Choosing between Single or multiple projects in a git repository?](https://softwareengineering.stackexchange.com/questions/161293/choosing-between-single-or-multiple-projects-in-a-git-repository) – Doc Brown Feb 17 '19 at 07:56
  • 2
    CI can work with multiple repositories, but everything is going to be simpler with a single repository. – JacquesB Feb 17 '19 at 11:24

1 Answers1

0

Your quotes are relevant to the very original CI systems which were build on top of older VCS-es which did not support merges reliably and did nto provide a way to store and share changes before they are committed to mainline. They were tracking in realtime the latest state of the mainline. So the developers were also requires do provide their changes to the mainline as fast as possible. If you are using that approach, it does not matter much how many repositories there are. You just take heads of all of them and integrate.

Nowadays, it is customary that the changes are tracked in feature branches before being merged to a development mainline, and CI builds and tests run for those feature branches. This ensures that by the merge moment there is high confidence that the changes are correct. Also it reliably stores the changes before the merging, so they don't get lost due to an accident.

With the newer approach having multiple repositories becomes a burden, because a developer has to synchronize unmerged branches between different repositories. But having several unrelated programs in same repository also has downsides - (1) it's just more data to fetch, (2) it would make their history cluttered with other project changes, (3) it prevents outsorcing some project without exposing others to the developers.

My opinion is that the optimal granularity is a repository for a each distribution unit, or for reused component. For example, if you have a service and mobile applications for platform A and B, there would be 3 repositories. If they share some library L, there would be 4 - 1 additional for library. Combining them in bigger repostiories would not provide any additional benefit - you anyway would have to consider compatbility concerns when changing interfaces between them.

max630
  • 2,543
  • 1
  • 11
  • 15
  • How do you maintain release cuts? if you have code in multiple repos? Assuming a workflow on single repo, `master` branch can easily tell that, which release went at what point in master branch? – overexchange Feb 18 '19 at 13:15
  • @overexchange most recent approach is the top-most project refers to exact versions of dependencies, either by git hash or binary package version. So there is no synchronisation issues. However this makes us to perform some dance when there is a need to simultaneously change the dependency's API and client – max630 Feb 18 '19 at 21:21