After availability of GitLab CI/CD components, a major shift in the release process development is happening.

Some history

Release Process started in 2016 as a collection of GitLab CI/CD job and pipeline templates to automate the release process of my personal software projects. The goal was to provide a set of best practices and tools to make the release process as easy and reliable as possible without much code in the “calling” project. It had simplicity in mind with a focus on easy of use, speed and best practices. The main idea was to have opinionated defaults that could be easily customized to fit the needs of a project (also known as “convention over configuration”).

Everything was build around a monolithic repository with multiple pipeline and job templates. Over the years, this project was used as a starting point for commerial projects that extended it’s functionality and established it as a standard pipeline framework for one of my clients. As always, although easy to start with, this monotlithic approach had it’s challenges regarding testability and maintainability. Additionally, every project using the Release Process might get new dependency updates, although the referenced jobs/pipelines might not have been changed at all.

Moving on

With the advent of GitLab CI/CD components in GitLab 16.x, the development of the Release Process project is taking a major architectural shift, however. The focus will be on providing a set of components that can be used to build a complete CI/CD pipeline with GitLab and embrace the new features provided by components (i.e. inputs, validation and discoverability). This will include components for building, testing, and deploying applications of different coding languages, as well as components for managing the infrastructure and the release process itself.

The new approach will allow for a more modular and maintainable codebase, and will make it easier to test and extend the functionality of the components. The input parameters of CI/CD components will also allow to provide easier to use default values and documentation.

The goal is to provide reusable jobs, as well as opionionated pipelines for specific coding languages. Pipelines will reuse the jobs and add little functionality by themself, besides the orchestration of the jobs. A user can either use the existing pipeline, modify it or write their own pipeline from scratch using the provided jobs. Only the jobs that belong to a similar category will be grouped into a single component.

The Roadmap

In the coming months, the focus is to migrate the existing jobs and pipelines for

• Docker / Container images
• Ansible Roles
• Earthly Builds
• Go Binaries

After that, the focus will be on providing components for

• Helm Charts
• Java applications (Maven, Gradle)
• Rust binaries
• Python packages
• NPM / Node.js packages
• Terraform modules