6

I'm working on a project that consists of several different services in different languages (a React webapp, a Scala backend, some Python stuff etc). I currently have each of these services in separate repositories on Github, and build them separately using CircleCI.

Some people seem to promote mono repos. As I'm planning to migrate the code over to Gitlab I wanted to take the opportunity to understand how this could be made into a monorepo. I have three questions:

  1. Assume I put all the services in the same Project (Gitlab repos are called Projects right?), can I then get the CI/CD system to build each component independently?

  2. Can I have Gitlab emit several images into my container registry?

  3. Assume I commit a change to one service, and want to make sure it works with my other services before I deploy, how do I best setup integration tests that condition the success of my commit on the interaction with my other services?

langkilde
  • 335
  • 3
  • 9

1 Answers1

4

Monorepos are nice because it eliminates the technical constraints between multiple projects. This does however open the door to other complications within your repository (naming conventions, cross-team dependencies, merge conflict increases, etc.). I do not have any experience with CircleCI, but I will provide some input based on other CI tools I have used.

  1. I don't see any reason why you wouldn't be able to. In your CI/CD system, instead of referencing your individual source repositories, you will use your main monorepo as the source repository and then reference the specific project directory within it.
  2. It looks like as of GitLab version 9.1 this is supported.

  3. In my opinion, this wouldn't be something that would happen on commit. You could do this, but I think it would slow down your development speed significantly and use up a lot of resources if you have many commits. The two key points to consider are:

    1. Before every production release, you should run a full suite test on all projects in your infrastructure. This is the only way to be certain that all project dependencies are non-breaking.
    2. Tests/provisionings must run in parallel. By doing this, your full repository testing speed will be the length of the longest test/provisioning in your repository. (As a side effect, this puts an emphasis on speeding up your slowest test)
Preston Martin
  • 3,278
  • 4
  • 17
  • 39
  • Do you really want to find out about breaking dependencies (or any other such problem) by running tests right before the production release? How do you reliably meet the release schedule if you don't like what you find out in such tests? ;) – Dan Cornilescu Nov 13 '17 at 15:45
  • Right that is true. My answer was tailored to imply that at the very least, you should be running these tests right before production release. But do you think it is appropriate to provision and test your entire infrastructure on every commit? That has potential to be a very costly and time consuming decision. I think either decision needs to be evaluated on a case by case basis. A compromise would be to run nightly full infrastructure tests I suppose :) – Preston Martin Nov 13 '17 at 15:54
  • The potential high cost (often raised, I know) should also be compared with the cost of not shipping a release because of the issues found or shipping a faulty release. Your compromise may be acceptable, but that depends on the project, its scale, the quality of the team, etc. I agree with case-by-case evaluation. Reliability can be achieved even without running a test for each and every change, but only with commit conditioning by pre-commit testing (rather than post-commit, traditional CI). – Dan Cornilescu Nov 13 '17 at 16:21
  • 1
    @PrestonM I really want to do full integration testing for every commit. That way I know I can always deploy a change as soon as it has been tested. I agree this gives longer turnaround time for each commit, but that's a price I'm willing to pay. – langkilde Nov 13 '17 at 18:33