DevOps
We automate the path from development to production and make your servers observable and backed up.
DevOps and infrastructure
GitOps for infrastructure and deployment
We manage infrastructure and deployments through Git. Every change is reviewed, recorded and can be rolled back in one step.
With GitOps, the desired state of the infrastructure and the application is defined in a Git repository, and nobody changes the server by hand. Every change is opened as a pull request or merge request, reviewed, recorded and, if needed, rolled back in one step. We run our own website this way: every merge into the main branch is a release, and no file on the server is edited by hand.
The problem we solve
Changes made by hand on a server leave no trace. A configuration file is edited, a setting is changed, and a few months later nobody remembers why. Test and production drift apart over time, and a change that works in test behaves differently in production. When a problem appears, finding out what was changed, when and by whom takes hours. Everyone with access to the server is a possible source of change, and none of these changes is reviewed. GitOps brings the review, history and rollback that Git offers for code to infrastructure and deployment as well.
How we work
-
Collecting the current configuration
We gather the configuration scattered across servers, environment settings and deployment scripts. Secrets are separated so they stay outside the repository, and everything else moves into the Git repository. For the first time, the current state of the servers is written down in one place.
-
Branch and approval rules
We define which branch maps to which environment, who approves changes and which automated checks they must pass. The branch that leads to production is protected.
-
Deploying from the repository
We set up a pipeline that applies every approved change to its environment automatically. Because environments are built from the same definitions, the differences between test and production are visible. The pipeline logs also show when a change went live in which environment.
-
Rollback and audit
Rolling back a change becomes as easy as a merge that reverts it, or releasing the previous version again. The change history remains a record of who did what and why.
What we deliver
- A Git repository with the infrastructure and deployment definitions
- Protected branches and approval rules
- A pipeline that applies approved changes
- Rollback steps and a working guide for the team
Frequently asked questions
What is the difference between GitOps and DevOps?
DevOps is a general way of working that brings development and operations closer together. GitOps is one way to put it into practice: the Git repository is the single source of truth for infrastructure and deployment, and every change goes through review and merge. You can take the two services together or separately.
Do we need Kubernetes?
No. GitOps is often mentioned together with Kubernetes, but the principle applies to any environment. This website runs on a cPanel server, and releases still come only from the Git repository, through a protected branch.
Will secrets such as passwords be stored in the repository?
No. Passwords, keys and other secrets never enter the repository. They are kept on the server or in the secret variables of the deployment tool, and the repository only defines which setting is required. An automated check that catches secrets committed by mistake is also part of the pipeline.
Can we not change the server directly in an emergency?
You can, but the change stays an exception and goes into the repository right after. Otherwise the next release quietly reverts the manual change. For emergencies we prepare a branch with a short approval path and a step by step guide, so a quick fix and a complete record do not get in each other's way.
Let us plan your move to GitOps
Describe in a few sentences what you want to build. We review your needs and write back with how we can move forward.