Services / DevOps and platform engineering
Software deliveryA release that is routine, not an event
GitLab or GitHub Actions builds and tests. Argo CD deploys what is in Git. Kubernetes runs the workload. Grafana shows whether the change held the SLO. A platform teams use on their own, without losing control.
How it fits together
Four layers, one way of delivering
Without GitOps the pipeline ends at the artifact. Without observability, deploy is guesswork. We put CI, Argo CD, Kubernetes, and Grafana into one rhythm: change, verification, insight.
- Preview environment and production use the same manifests, with different configuration.
- A manual change in the cluster is drift. We return to Git or we record it as code.
A pipeline with a quality policy, not a manual button
We build CI in GitLab or GitHub Actions: test, scan, artifact, and a gate to the environment. Merge does not skip controls. A preview environment comes up on the merge request and disappears after close.
Gates
Tests, lint, SAST, image, and artifact policy. A broken main is an exception, not the working mode.
Environments
Dev, staging, and production with the same pipeline. The difference is approval and secrets, not a different script.
Identity
Runner, registry, and cloud on service accounts with a short-lived token.
Audit trail
Who ran the job, which commit, which artifact went further. Material for a change audit.
Cluster state comes from the repository
Argo CD compares the cluster with Git and syncs drift. Rollback is a return to a known commit. Cluster permissions stay in the tool, not on a developer laptop.
Source of truth
Manifests, Helm, or Kustomize in the repo. A change without a merge does not stay in production.
Visibility
Health, sync, and diff on the application. OutOfSync has an owner, not silent drift.
Boundaries
A project per team or per client. RBAC in Argo, not cluster-admin for everyone.
Failure
When sync fails, you see the resource and the event. A playbook for rollback and escalation.
A cluster you can repeat and account for
Kubernetes in the cloud or on-prem, with the same network, limit, and backup policy. Node, storage, and ingress are in code. The dashboard is for diagnosis, not for manual production changes.
Repeatability
Terraform or other IaC for the cluster, add-ons, and network. A second environment comes up from the same description.
Limits
Request, limit, quota, and NetworkPolicy. One unruly workload does not take CPU from neighbors.
Day two
Upgrade, certificates, storage class, PDB. The change window and rollback plan are part of the retainer.
Access
kubectl through corporate identity. An audit log of every API request.
You see the SLO before the user reports an outage
Metrics, logs, and traces in one place. A dashboard per service, an alert with a runbook, not a raw CPU threshold. After deploy, you see whether p95 and error stayed in budget.
Signal
RED or USE per service. Logs with pod and commit context. Tracing where the path is distributed.
Alert
Priority, silence during maintenance, escalation. Noise drops in the first month, it does not stay forever.
Cost
Retention and sampling set deliberately. Observability must not eat product margin.
People
The same picture for engineering and on-call. Less guessing who looks at which panel.
Operations
From platform map to release rhythm
First an inventory of repos, clusters, and secrets. Then pipeline and GitOps. Finally SLO, on-call, and a service catalog.
- Map Repositories, environments, secrets, who deploys, which cluster.
- Baseline CI with gates, Argo CD, limits, and a first set of dashboards.
- Self-service Application template, documentation, permissions per team.
- Rhythm Review of pipeline failures, GitOps drift, and SLO budget.
Talk
We will discuss pipeline, cluster, and observability
On that basis we will prepare a scope: CI, GitOps, limits, and dashboards.
Contact us