Continuous integration and continuous deployment changed how I think about delivering software more than anything else. With a good CI/CD pipeline, pushing code becomes a small, repeatable step that happens dozens of times a day. This is the setup I use on Azure with GitHub Actions and Kubernetes.
Start with a short, honest pipeline
You do not need a complicated pipeline to start. A useful first pipeline has three jobs: build, test, and deploy. Each runs automatically every time code lands on the main branch. If you are new to pipelines, the Azure Pipelines key concepts guide is a solid starting point.
Build. Restore dependencies, compile, and package the artifact. Keep it fast because it runs constantly.
Test. Run unit tests, linting, and a few integration checks. A pipeline that never fails on bad input is not protecting anything.
Deploy. Push the artifact to the target environment. In my case that usually means building a container image, pushing it to a registry, and updating a Kubernetes deployment. GitHub Actions’ getting-started docs cover the ecosystem that makes this straightforward.
Treat the environment as code
Deploying to infrastructure that nobody can recreate is fragile. I write my Azure infrastructure in Terraform or Bicep and keep it in the same repository as the application. The staging environment is a commit, not a mystery.
When the pipeline deploys, it applies the infrastructure change, deploys the application, and waits for a health check. Kubernetes readiness signals decide when traffic reaches the new version. If the health check fails, the old version is rolled back.
Make observability part of the pipeline
A pipeline is only useful if you can tell whether the new version is actually healthy. I wire a monitoring alert into the deploy step so a newly deployed release that starts throwing errors triggers a notification almost immediately.
Prometheus handles metrics, and Grafana the dashboards. The first dashboard does not need to be impressive. A few charts for request rate, error rate, latency, and resource usage catch most regressions quickly.
What I would do first if I were starting over
If I were setting this up from scratch today, I would do three things before adding more tooling: commit to trunk-based development, keep every environment reproducible from code, and make deploys fast enough that nobody dreads them.
Key takeaways
- A short, honest pipeline has three jobs: build, test, deploy.
- Keep infrastructure as code so any environment can be recreated.
- Wire observability in from day one so failures surface fast.
- Make deploys fast and reversible; that is what builds trust.
Reliable delivery comes from boring, repeatable steps that fail loudly and roll back safely. The portfolio shows projects where this pattern is in use, and the FAQ answers common questions about how I work.