Docker and CI/CD pipelines

The environment is part of the product

A Drupal site that only runs on one machine is not handed over. It is borrowed. Docker is how we make the application, its services, and the versions they need into something a new developer can start, and something a pipeline can build without a checklist taped to a laptop.

GeoNovation uses that container as the unit CI understands. GitLab runs the pipeline: install, test, build, and a deployment a reviewer can see. The same image that passed the pipeline is the image that reaches the environment. Configuration and secrets stay out of the image, where they can be changed without a rebuild of the code.

Releases you can explain

Public-sector delivery is often asked who shipped a change and how it could be repeated. A pipeline is a better answer than a shared server and a remembered command. We keep the definition of the build next to the code, so the next person can read the stages and change them.

This sits with the rest of the platform. A Drupal configuration export, a backend service, and a frontend build can be stages in one path, or separate paths with a clear promotion between environments. We choose the smaller arrangement that still lets you redeploy.

• Docker images for the application and the services it needs in development.
• GitLab CI pipelines that build, test, and publish from the repository.
• Environment-specific configuration kept outside the image.
• A release process a new engineer can follow from the repository alone.

Where it starts

If you already have a deploy that lives in one person's head, the first piece of work is writing that down as a pipeline, not adding more environments. Tell us how a change reaches production today. We will come back with the smallest pipeline that makes the next change repeatable.

This work sits inside Cloud & AI Development. Request information — tell us the organisation, the platform, and the constraint.