DevOps services and CI/CD pipelines
DevOps is a way of working that brings software development closer to operations, and the aim is simple. Release more often, get things wrong less. To get there, our DevOps services set up a CI/CD pipeline (continuous integration and continuous deployment). Every time the code changes, a set of tests and checks starts on its own. The approved version then goes live without anyone having to touch the server. We work with SMEs, startups or public bodies, from Bastia or remotely.
DevOps and CI/CD in plain terms
In many organisations, putting a new version of a website or application online is still done by hand. Someone copies files to the server, types a few commands, checks the page loads. That works fine. Until the day a step gets missed. DevOps replaces those manual steps with automated procedures, written once, tested, then replayed identically.
- 01
Continuous integration (CI)
As soon as a developer pushes a change, the code is built and put through a series of tests with no human involved, and if one fails, the change is blocked before it reaches your users.
- 02
Continuous deployment (CD)
Once approved, the new version deploys automatically, or with one click. It goes through a test environment first, then reaches production, meaning the website or application your customers actually use.
- 03
Containers
A container (Docker, for example) is a standardised box holding the application and everything it needs to run. It behaves the same way on the developer's laptop as on the test server or in production.
- 04
Monitoring
After each deployment, automated monitoring checks that the application responds normally. At the slightest anomaly, it sends an alert.
Signs it is time to automate your deployments
- 01
Releases are dreaded
They get postponed, bundled together, run late at night. And each one brings its share of surprises.
- 02
Fixed bugs come back
Without automated tests, one fix can break another. Quite often your customers are the first to notice.
- 03
Only one person knows how to deploy
The procedure isn't written down anywhere. If that person goes on holiday or leaves the company, nobody dares touch the server any more.
- 04
Several developers or suppliers are involved
Each one brings their own habits and tools. A shared pipeline applies the same checks to everyone.
- 05
You need to be accountable
A public body, or a company handling sensitive data, has to be able to say who put what live, and when.
DevOps sized for an SME, a startup or a public body
DevOps isn't reserved for big tech companies. The pipeline follows the size of the project. For a company website, a few tests and an automated deployment are enough; a business platform will need several environments, plus security checks and manual approvals.
We work with startups that release often and want to keep that pace as they grow. Also with SMEs evolving a business application or an online shop, and with public bodies that need traceability. In Corsica, where a lot of businesses live by the rhythm of the season, being able to fix a bug at the busiest time without risking breaking everything has very real value.
Setting up a continuous integration pipeline, step by step
- 01
Review
We look at your code and the tests that already exist, your hosting, how releases happen today. We spot the manual steps and the risks, plus whatever can be improved quickly.
- 02
Pipeline design
We decide with you which checks to automate and which environments are needed. Then there's the question of secrets (passwords, access keys). They are stored separately, never in the code.
- 03
Gradual roll-out
Continuous integration first. Then automated deployment to a test environment, then production, with a rollback procedure that returns to the previous version if something goes wrong.
- 04
Handover
We document the pipeline and explain how it works to your developers or your supplier. If it needs adjusting later, we're still around.
What you get, from the CI/CD pipeline to the documentation
At the end of the engagement, you have a CI/CD pipeline. That is the series of automated steps between a code change and its release, configured in whichever continuous integration tool suits your project best. You also get the Docker images of your applications. Then the environments for testing and for production, the rollback procedure, the failure notifications. Documentation ties it all together, so any competent person can take the pipeline over.
We apply these principles to our own projects. One of them, La Forge, is a software factory run by autonomous agents. It turns a requirement into code that has been tested and reviewed, and its checks run on Docker and a continuous integration pipeline. There, automated deployment is no optional extra. Everything rests on it.
Risks to check before you automate
- 01
Tests that are too thin
An automated pipeline is only as good as the checks it runs. With thin tests, you think you're protected when you aren't. So we start with the most critical user paths.
- 02
Exposed secrets
A password left in the code is an open door. We isolate secrets, and the pipeline only gets the rights it strictly needs.
- 03
Database changes
Changing a database's structure during a deployment calls for care, because a rollback isn't always possible unless it has been prepared.
- 04
Tool lock-in
We prefer portable steps, built on Docker and standard scripts, so that switching platforms later won't force you to rewrite everything.
- 05
An over-engineered pipeline
Automation nobody understands ends up as a black box. We calibrate it for the team that will have to live with it.
What affects the cost of a DevOps project, and what comes next
The cost depends on how many applications are involved and the state of the code, the tests already in place, the number of environments to create. The complexity of the hosting counts as well, as do security requirements or the time needed to train your teams. Writing tests where there are none is priced separately, so you can plan it.
Once in place, the pipeline needs little attention. It still has to keep up with the project, with tools to update, new tests, sometimes a new environment. We can look after it on its own, or as part of managing your servers.
Technologies and methods
- Docker
- Linux
- GitHub Actions
- CI/CD
- Automated testing
- Rollback
- Monitoring
Frequently asked questions
Do the tests use our customers' data?
No. Tests run on fictitious or anonymised data. Your real data stays in production, which cuts the risk of a leak and makes GDPR compliance simpler.
Do we need to rewrite our software to set up a CI/CD pipeline?
Rarely. Most applications fit into a continuous integration pipeline as they are. Sometimes they need adapting to run in a container, or the configuration has to be taken out of the code. We then move in small steps, without interrupting your business.
Which tools do you use?
Docker and Linux day to day, along with the most widely used continuous integration tools. But we start from what you already use. If your code lives on another platform or your team has its habits, we adapt the pipeline rather than force a change on you.
What happens if an automated deployment fails?
The version doesn't go live if a test fails, and the team is notified; when a problem only shows up after release to production, the rollback procedure puts the previous version back while it is fixed.
Will our team be able to run the pipeline without you?
Yes, that's the point. The pipeline is documented, stored alongside your code and explained to your developers. After that, you evolve it yourselves or call on us now and then.