Forge and CI · in regular use
GitHub agency in Nice
The most widespread forge, and its automated test and deployment actions.
What we do with it
GitHub at our clients, concretely
Used with its automated actions on a sentiment-tracking tool for AI models. On our projects, the repository is created in your name from day one.
The limits
When we recommend something else
If the code must not leave your premises, a self-hosted forge is required.
Our work
Projects we delivered with GitHub
LLM Monitor
SaaS that measures how visible brands are in AI answers.
GitHub: Repositories, continuous integration and image publishing.
Read the LLM Monitor case study
Method
How we bring GitHub into a project
Once the organisation exists, we set rules on the main branch: no direct pushes, mandatory review of every pull request, test workflows passing before merge. A code owners file sets out who reviews which parts of the application, and issue and pull request templates give structure to discussions from day one.
GitHub Actions workflows are split by purpose: one runs tests and code analysis on every pull request, another builds the application for each tagged release, a third deploys. Production deployment goes through a protected GitHub environment that requires approval and holds its own secrets, out of reach of the other workflows. GitHub's dependency alerts open pull requests when a fix is released, and those go through the same test pipeline before being accepted.
Every production release corresponds to a version published in the repository, with the list of changes it brings. On delivery, the repository includes a local setup guide, the list of secrets to fill in for each environment and a description of each workflow: what triggers it, what it checks and what it deploys.
For your business
What it changes in practice
For a small business, GitHub's value lies mostly in how many people can work on it without training. A new hire, a freelancer brought in to help or an incoming provider finds screens and practices they already know, and can focus on your application rather than the tool. Taking over a project becomes easier, and your choice of technical partners stays open.
Day to day, the automated workflows act as quality control that never lets up: a change that breaks a calculation or a screen is stopped before it reaches your users, and a production release needs explicit approval. Vulnerable dependencies are flagged as soon as a fix exists, so you do not discover years later a library that was never updated. Finally, every published release leaves a readable trail: after an incident, you can see what changed and when, and the earlier version can be redeployed through the same workflow.
Our reading of it
What we take away from GitHub
GitHub is where we open your repositories by default, in your name and with your administration rights from day one. That is a point of method more than a choice of tool: the code must stay reachable without us, including the day the engagement ends.
Automation runs on GitHub Actions, described inside the repository: type checking, linter, tests, then building a Docker image that is deployed only if everything is green. We protect the main branch so nothing lands on it unreviewed. The reservation is well known and we state it: the code is hosted by a third party. When that is not acceptable, a GitLab instance under your own control answers the same need.
Decision guide
Should you choose GitHub?
GitHub or GitLab for a business starting a software project?
GitHub, if your code can be hosted by a third party: it is the forge most developers already know. You can hire or change provider without a settling-in period, and its range of integrations is the widest. GitLab becomes the better fit if the code must not leave your premises, since a self-hosted forge is then required. Between the two online services, for a small team, feature differences matter less than the habits of the people who will use it daily.
GitHub Actions or a separate CI service?
GitHub Actions, if your code already lives on GitHub. Test and deployment workflows are defined in the repository, run on every pull request and draw on a large library of public actions. We use them this way on a sentiment-tracking tool for AI models. A separate service is justified for very heavy builds or specialist hardware. One caution: a public action is third-party code, so we pin it to an exact version.
Should the GitHub repository belong to the provider or to the business?
To the business, without exception. On our projects the repository is created in your name from day one, inside a GitHub organisation you own, and our developers are added as members. A repository held by the provider leaves you asking for your own code if you fall out or they cease trading. With an organisation in your name, you keep the full history, issues and automation whichever provider you work with.
Client questions
What clients ask us about GitHub
Is our code publicly visible on GitHub?
No, provided the repository is private, which is our default for business software. Only people invited into your organisation can see it, with permissions you control. We require two-factor authentication for members and check that no passwords or access keys have been committed to the code. If the code must not leave your premises at all, GitHub is the wrong choice.
What happens on GitHub if we change provider?
You remove the outgoing provider's access in your GitHub organisation and invite the new one. The repository stays exactly where it is: commit history, issues and automation all remain intact. That is precisely why we create the repository in your name from day one. The incoming provider also finds, in the workflow files, exactly how the application is tested and deployed.
Is GitHub a durable choice for hosting a company's code?
It is the most widely used forge, relied on by a very large number of companies and open-source projects, and Git is an open format: any repository can be copied elsewhere in full, history included. The real dependency lies in GitHub-specific features such as Actions and issues rather than in the code. For a business-critical application, we recommend keeping a copy of the repositories outside GitHub.
Can colleagues who are not developers be given access to GitHub?
Yes. A project manager or business lead can join your organisation with a limited role that lets them open issues, comment on pull requests and follow progress, without being able to change the main branch or see deployment secrets. That helps when reporting a problem with its context or checking what a release will change. On paid plans, however, each member counts as a billed user.
What happens to our application if GitHub goes down?
Your production application keeps running: it does not depend on GitHub to serve your users. It is the tests and deployments that wait for the service to return. So that an urgent fix is not held up, we document in the repository a manual deployment procedure mirroring the workflow's steps. It is rarely needed, but it stops an outside outage from preventing a repair.
Going further
GitHub 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 GitHub 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