Data & Cloud
CI/CD, monitoring and on-call for teams that release often
Brihat Infotech sets up the pipeline that takes code from a developer's laptop to production, and the monitoring that shows what happened next. Releases become routine, and a failed one can be reversed.
What we set up
- CI/CD
every change is built, tested and deployed by a pipeline, not by hand.
- Infrastructure as code
servers, networks and permissions are written in files, reviewed like software and rebuilt on demand.
- Observability
logs, metrics and traces that show where a request slowed or failed.
- SRE practice
service level objectives (SLOs), error budgets and an on-call rota, in the style described in the Google SRE book.
- Release engineering
feature flags, canary releases to a small share of users, and a tested rollback.
- Environments and secrets
separate test and live environments, with passwords and keys kept out of the code.
- Incident response
a written process and a blameless postmortem after each incident.
Tools we use
GitHub Actions or GitLab CI for pipelines. Terraform and Ansible for infrastructure. Prometheus and Grafana for metrics, with OpenTelemetry for traces. PM2 or Kubernetes to run services.
How an engagement runs
- 01Pipeline review, at your offices or ours in Noida. We read your current pipeline, release history and last few incidents.
- 02Pipeline and environments. We build or repair them first, because everything else depends on them.
- 03Monitoring and alerts. Alerts point to a named person and a runbook.
- 04On-call and SLOs. We agree the service level objectives and set up the rota with your engineers.
The work typically takes 6 to 12 weeks with a platform engineer and a pair of SREs. See How we engage for staging and reports.
How we ship our own code
The pipeline we set up follows the engineering standard we use on every project. A second engineer reviews every change. Changes are small and merge often. Releases are automated and can be reversed. A change counts as done only when it is deployed to a live environment and can be monitored.
Handed over at the end
- Pipeline definitions and infrastructure code, in your repository
- Dashboards and alert rules
- Runbooks for the incidents you are most likely to see
- Your SLOs, with the error budget each one allows
Reliability on a sale day
Growth-stage D2C brand. Flash sales had crashed the old storefront. The rebuild added autoscaling and a waiting line ahead of checkout, so buyers hold their place instead of seeing an error. See the D2C commerce case study
Also see: managed cloud support if you want us to carry the pager. Need an engineer on your own team instead? See hiring a DevOps engineer.
Tell us how your last bad release went.
Tell us what you want to build.
The first call is 45 minutes with an architect, usually the founder. It is free, and we will sign an NDA first if you ask.