I'm starting to use continuous integration for one of my projects and had some questions about structure and architecture.

It's basically a multi-device webservice that is split into one server repository and multiple device-specific client repositories.

My question is the following:

  • Since clients are dependant on the server to run their tests, does it make sense to split them into another repository ?

I did some builds with Travis CI as examples and it worked great but now that I want to add tests, it's raises the issue of being dependent on the server project.

Server that itself also has it's own build and tests.

From a project architecture side it makes sense to split server and client repositories but I have troubles looking at the big picture and the CI server integration.

2 Answers 2


TL;DR: It depends, but not because of continuous integration. You can version everything together which will simplify dependency management, or you can split the code and make dependency management explicit between the different code bases.

This isn't really a question about continuous integration. The driving concern when splitting code bases is if you want to version and manage different parts of the codebase separately. For example if the server code didn't change often, but the client code did then it would make sense to split the repository. You wouldn't want to do a server deploy and release when the only thing changing is the client code.


Once the code has been split you must make sure you have captured explicit dependency and represented it appropriately. For example if you were creating RPMs then each package should be dependent on both the package and version that the build system is validating.

Deciding when to update the dependencies in the build system can either be a case of updating all dependents to:

  • the latest commit
  • the latest successful build
  • the latest release candidate
  • etc

This can often be handled by the build system, or some shell scripts that get triggered as pre/post build operations with each build.

  • Yes but once the choice of splitting the code base is taken, how do you make the CI server test one part of the code when it actually is dependent on another part ?
    – m_vdbeek
    Aug 31, 2014 at 21:43
  • @m_vdbeek see update
    – snakehiss
    Sep 2, 2014 at 8:27

CI server are only co-ordinators, they schedule and run builds, they schedule and run tests, and some schedule and run deployments. Its the latter you are worrying about and that's ultimately a task for whatever tool you use to deploy your build project onto whatever hardware or VM is going to be used for testing.

I have a project that consists of a client and server, each time I schedule a major build that will be released to test, it builds everything regardless of whether it needs rebuilding or not. then the guaranteed re-built-with-latest code and stamped with latest version number gets deployed.

  • So basically everything is build (server and client together) and then the result is tested ? In this scenario wouldn't it be a better idea to have the client and server in the same repository ?
    – m_vdbeek
    Aug 31, 2014 at 20:30
  • Up to you - I usually prefer everything in the same repo, as you can reuse common library code easier, but YMMV. It depends on the size and shape of your processes and codebase.
    – gbjbaanb
    Aug 31, 2014 at 22:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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