Client / Server dependencies with Continuous Integration

Question

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.

Answer 1

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.

Update

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.

Answer 2

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.