Home > Nuxeo Core Developer Guide > Development Tools and Process > Continuous Integration (CI) For a Nuxeo Project
Nuxeo Core Developer Guide

Continuous Integration (CI) For a Nuxeo Project

Updated: December 16, 2024

Setting up continuous integration on your project is a good practice to prevent regressions and potential bugs. The earlier you detect a problem, the easier it is to fix it.

This page intends to give guidelines on bootstrapping CI chain for your project. It won't explain how to do it step by step: too many factors may vary to explain this in a generic way.

Hyland University

Define Expectations

The architecture to set up depends on:

  • what you want to automate (build, test, verify)
  • when (on commit, by night, on demand, on release)
  • how

Matters the size of the code base, the number of developers, the build frequency, the development flow etc.

Once you know your expectations, you can get a better idea of the tooling it will require.

Doing CI consists of automating manual tasks, and implicitly involves leveraging the ability to add more and more automated tasks such as

  • Quality Assurance tooling
  • Continuous Delivery (e.g. deploying artifacts to a Nexus / artifactory)

Base setup is an environment satisfying the "what you want to automate" requirement, i.e. "build" or "test" requirements. Such an environment is provided to the CI system as a Docker image (or composition), and leveraged using a Jenkins like automation tool.

Below are some of the tools Nuxeo usually uses and is familiar with.

Unit Tests

  • JDK 8: run-time container
  • Maven 3: Jenkins slave that runs the build

Functional Testing

  • Selenium WebDriver, Cucumber: automated testing tools that integrate with Maven

Performance Testing

  • Gatling: benchmark testing tools that integrate with Maven

Additional tools can possibly be added for code coverage, code quality testing, continuous delivery and so on. Feel free to take a look at how Nuxeo leverages CI for inspiration.

Infrastructure Sizing

To get a size estimation, we suggest to build a first job and measure impacts/footprint on:

  • Network bandwidth
  • Disk usage: space, IO, speed
  • Memory
  • Build duration

From there, ask yourself the following questions:

  • How many branches do you want to put CI under?
  • How many commits happen per day?
  • How many developers will you have?

With these numbers, you can get a rough estimate of your needs/ costs induced and estimate this against the developers' expectations and your quality control requirements. Setting up a scalable infrastructure helps to start small, then adapt the sizing as needs evolve.

Q/A

Can I Put Studio Configuration Under CI?

Yes you can:

Studio configuration is exposed as a build resource (Maven artifact or Nuxeo Package).

Can I Automate Studio Releases?

Yes you can: once your tests pass, it is easy to automate the creation of a new Studio release thanks to Studio's releases REST API.