When running a project, you probably run into plenty of problems: technical debt, rocky releases and so on. Learning DevOps, hiring a DevOps engineer or simply sharing the philosophy can be a very good idea.
What is DevOps?
Who are the developers?
No surprises here: they’re the people who write code, build new features and fix bugs.
Who are the ops (operations)?
Every company defines operations in its own way, but they’re generally the people who look after the information system: the sysadmins, as they’re commonly called.
Benefits of DevOps
- faster project deployment (a website, an application, etc.)
- shorter time to market
- greater reliability
And, as a logical consequence of all the above, it saves money.
Drawbacks of DevOps
I haven’t found any so far, apart from the difficulty of convincing teams or management, which isn’t strictly speaking a drawback of the philosophy itself.
The fundamentals of the DevOps philosophy
The DevOps philosophy can be summed up by the acronym CALMS, which stands for its five pillars: Culture, Automation, Lean, Measurement and Sharing.
Culture
For the philosophy to take hold, you need to build a culture. Developers and operations must share a common vision and therefore the same objectives. The idea is to stop one team blaming the other: responsibilities must be shared. They need to work together and develop shared values. Ideally, this becomes part of the company culture.
Automation
Every repetitive task where humans add little value should be automated, which brings many benefits.
You’ll be able to make deployments more reliable and faster, for example through automated tests. If your project allows it, write unit tests (function by function), integration tests (checking how a function fits in) and end-to-end tests (acting like a user).
Gone are the days of “you’d have to be mad to deploy on a Friday”. You’ll feel much more confident.
Lean
The idea is simple: keep things simple and focus on what creates value. This avoids adding cyclomatic complexity, for example. You cut waste: there’s no need to oversize the test environment, especially on pay-as-you-go pricing.
Measurement
You’ve all heard this at least once:
“You can only improve what you measure.”
One way to measure is to use KPIs (Key Performance Indicators). Taking stock of where you are matters, if only to know later whether you’re improving or slipping back.
In IT, we like to measure a site’s latency, load time and saturation, as well as a server’s CPU and RAM usage, database performance and so on.
Sharing
To bring developers and operations together, they need to share time together. As mentioned above, they must share responsibilities. When the two teams work closely together, things get simpler and innovation follows.
Teams can share all sorts of things: knowledge, successes and advice, but also failures. If admitting or discussing failures feels difficult where you work, the company culture probably needs rethinking.
Reminder: every team and every company has different needs. These examples are here to inspire you, not to be followed as rules.
DevOps & CI/CD
CI/CD stands for Continuous Integration and Continuous Deployment (some say Delivery).
Both stages run in a pipeline, which is why you’ll sometimes hear the term CI/CD pipeline.
These stages build the project, run the tests and, for example, code analysis (many open-source and paid services offer this), then deploy. Since every action is defined in the pipeline, the margin for error is very small. If the pipeline fails, the developer is notified and can see which stage of the CI/CD chain broke.
Automation also means more and more tools act on their own, including AI coding agents. Running them in an isolated environment is a DevSecOps reflex worth adopting, as I explain in my article on sandboxing Claude Code with Docker sbx.
DevOps: common mistakes
Adopting a DevOps philosophy is always a good idea, as long as it’s done properly. Here is a non-exhaustive list of situations where one of the five pillars is neglected:
- building lots of features while piling up technical debt (poor code quality, for example)
- shipping that technical debt, especially deliberately
- having code or a CI/CD pipeline that constantly breaks and slows developers down
- having slow deployments.
Conclusion
DevOps improves cohesion within and between teams, and lets you ship more, with greater peace of mind! Here’s an image that sums up the idea:
Leave a Reply