Standardising CI/CD across projects

Starting a new project often meant writing another Jenkins pipeline. Its structure depended on who built it, so similar tasks were implemented differently across projects.

Over time, more than a hundred projects and pipelines had accumulated their own scripts. Common changes required finding and updating those separate implementations, while new projects repeated work already done elsewhere.

These pipelines supported a larger software integration system, with builds and tests across hundreds of repositories. Each project needed to participate in that system: respond to repository activity, report execution through Eiffel events and return useful feedback to developers.

A shared structure for project pipelines

The common requirements provided the basis for a shared Jenkins template and library. Triggers, retry handling, message bus integration, logging, reports and commit feedback became reusable parts of the pipeline framework.

This gave projects a common structure around their build and test steps. A new pipeline could use the existing implementation for execution and reporting, with the project-specific work defined within that structure.

The distinction mattered because projects still had different software and integration requirements. Their build and test logic needed to remain specific, while the surrounding behaviour could be maintained together.

Consistent execution and developer feedback

Repository actions triggered pipeline execution. The shared framework provided retry handling, logs and email reports, along with comments and automated positive or negative votes on commits.

Developers received feedback through the source review workflow, with reports available for further investigation. Projects could use the same feedback mechanisms without each maintaining a separate implementation.

The framework also included integration with the Eiffel message flow used by the wider system. Pipeline activities remained connected to their event history and associated reports, using common integration code across projects.

Keeping common changes manageable

A change to shared infrastructure could affect many pipelines at once. Updating a Git URL or a message bus integration had previously meant editing separate scripts across a large number of files.

Consolidating that code into a small number of shared implementations reduced the places where the same change needed to be made. Project-specific build and test steps remained separate from those common functions.

This made the boundary between shared behaviour and project configuration clearer. Common execution and reporting logic had a defined place, while individual pipelines retained the steps needed for their software.

A foundation for new and existing projects

New projects could start from the common pipeline structure and concentrate on their own build and integration requirements. Existing projects could use the same triggers, reporting and feedback functions.

The result was a smaller set of implementations to maintain across a much larger set of pipelines. Shared changes no longer depended on finding every independently written version of the same function.

Within the wider integration system, this gave projects a consistent way to execute work, publish events and report back to developers while preserving the build and test logic specific to each project.