Forge and CI · in regular use
GitLab agency in Nice
Where the code lives, and the chain that tests then deploys it automatically.
What we do with it
GitLab at our clients, concretely
Used on public research projects and on a patent portfolio management solution, with continuous integration and production monitoring.
The limits
When we recommend something else
If your organisation already uses GitHub, migrating costs more than it returns.
Our work
Projects we delivered with GitLab
Paradigm
Platform for a Nice business centre: registered address, digitised mail, messaging and assistant.
GitLab: Continuous integration: tests, end-to-end tests, build and deployment.
Read the Paradigm case studyHelioneo
Collective self-consumption platform: agreements, allocation keys, Enedis data and billing.
GitLab: Automated tests, build and deployment.
Read the Helioneo case studySilversun — prospection
B2B prospecting tool for renewable energy: geocoded projects and enriched prospects.
GitLab: Continuous integration and deployment.
Silversun — suivi de chantier
Solar project progress timeline for the end customer, fed by the CRM.
GitLab: Automated deployment.
Ordelya
Restaurant management platform: back office, tablets, kiosks, screens and website.
GitLab: Continuous integration for each service.
Mejid & Co
Installable web app for tracking disbursements for Mejid & Co's clients.
GitLab: Automated build and deployment.
Read the Mejid & Co case studyJeu-concours Snake
Six-level retro contest game, with quiz and sign-up, for a laptop marketing campaign.
GitLab: Automated deployment.
Read the Jeu-concours Snake case studyAngeles Immobilier
Multilingual website for a Côte d'Azur estate agency: listings, search and blog.
GitLab: Continuous integration and deployment.
Read the Angeles Immobilier case study
Method
How we bring GitLab into a project
We create a GitLab group for the organisation, with one project per application and roles assigned by need: developers, reviewers, people who only follow the issues. The main branch is protected: nothing gets in without a merge request reviewed by a second developer and a passing pipeline.
The pipeline usually runs in four stages: style checks and static analysis, automated tests, building the image into the built-in registry, then deployment. Deployment to the staging environment runs on its own; deployment to production remains an action a person triggers. Deployment credentials are stored as masked, protected variables, readable only by pipelines on the main branch. For sensitive projects, jobs run on a runner installed on your own infrastructure rather than on shared machines.
GitLab keeps a history for each environment: which version is running, since when, and who deployed it. We link issues to it so every release points back to the requests it addresses. At handover, the repository contains a getting-started guide, a description of the expected variables and the procedure for adding or removing a group member.
For your business
What it changes in practice
For a small business, GitLab makes what happens to the software visible. You know which version is live, which requests it dealt with and who approved it, without having to ask a developer. An error that slips past the tests is fixed by redeploying the previous version from the environment history: a short, documented step rather than an improvised repair on the server.
Security benefits too. Server credentials are no longer copied onto developers' laptops: they stay in the forge and are used only by authorised deployments, so a departing team member takes no production password with them. For public bodies or work involving intellectual property, keeping code, issues and deployments on an instance whose location you control meets confidentiality requirements without piling up tools. And whoever takes the project on next reads the pipeline, issues and history in one place, so they understand how the software evolved before changing it.
Our reading of it
What we take away from GitLab
GitLab is what we propose first to organisations that want their code hosted on their own premises. A self-hosted instance covers the repository, the issues, continuous integration and the image registry on a single machine you control — a decisive argument where sources must not leave the perimeter.
Pipelines are described in a file inside the repository, so they are versioned with the code. They build a Docker image, run the tests against it, and deploy exactly the image that passed. For a public project, or a team already settled on GitHub, we try to convert nobody: the benefit would not cover the cost of moving, and self-hosting assumes someone keeps the instance updated.
Decision guide
Should you choose GitLab?
GitLab or GitHub to host our code?
If your organisation already uses GitHub, stay there: migrating costs more than it returns. GitLab pulls ahead on a new project when you want repositories, issues, CI, a container registry and deployment tracking in one place, or when the code has to stay on your own servers. GitLab can be self-hosted with its full feature set, which matters for public bodies and sensitive work. For a project open to a community, GitHub remains more visible.
Self-hosted GitLab or GitLab.com?
GitLab.com, unless something requires the code to stay in-house: no server to maintain, no upgrades to apply, no backups to watch. Self-hosting is justified when internal policy, a contract or the nature of the work rules out third-party hosting, as happens in public research or intellectual property. Someone must then own the instance: a GitLab server that stops being updated becomes an entry point for attackers in its own right.
GitLab's built-in CI or a separate tool such as Jenkins?
GitLab CI in most cases. The pipeline is defined in a file inside the repository, versioned with the code, and its results appear directly on each merge request. A separate tool adds a server, plugins and credentials to maintain. Jenkins still makes sense if your organisation already runs one with many established pipelines. For a small team getting started, GitLab CI is sufficient and another developer can pick it up without special training.
Client questions
What clients ask us about GitLab
Who owns the code hosted on GitLab?
You do, provided the project sits in a space you own, which we recommend from the outset. Your organisation holds the GitLab group and our developers are invited in with permissions you can revoke at any time. On a self-hosted instance, the code also physically lives on your own servers. Changing provider then comes down to updating access, with no repository transfer or archive to chase.
What does GitLab CI bring to an application already in production?
It stops a change from quietly breaking something that used to work. Every time code is pushed, GitLab runs the automated tests and flags a failure before anything reaches production. Deployment follows a procedure written down in the repository rather than relying on one developer's memory. That is how we use GitLab, with CI and production monitoring, on a patent portfolio management solution.
Does a self-hosted GitLab need a lot of maintenance?
More than an online service, and it should not be underestimated. GitLab ships frequent releases, including security fixes that need applying promptly, because a forge holds your code and often credentials for your servers. Repositories and the instance database need backing up, disk space needs watching and restores need testing. If nobody can take that on, GitLab.com is the more sensible option.
What is the difference between GitLab's free edition and its paid plans?
The free edition covers what a small team needs: repositories, issues, merge requests, continuous integration and a container registry. The paid plans mainly add control and compliance features, such as finer approval rules, advanced security scanning or detailed audit logs. We only recommend a subscription if one of those features meets an identified requirement, and in that case we justify it in the costed action plan.
Can we run our project tracking directly in GitLab?
Yes, and for a software project it is often simpler than a separate tool. GitLab offers issues, labels, milestones and boards, and every code change can link to the issue it addresses. A non-technical colleague can report a problem or follow progress with a limited role and no access to the code. If your company already manages all its projects in another tool, we connect GitLab to it rather than forcing a change.
Going further
GitLab sits within our Software development
A technology does not make a project. The method around it decides the outcome: scoping, prototypes, short cycles, and a clean way out.
Neighbouring technologies
A GitLab project in mind?
The first conversation is free. We will tell you plainly whether this technology is the right one, and if not, which is.
Updated on