DevOps and CI/CD

DevOps that makes releases boring

When a release needs a checklist, a specific person, and a quiet Friday, it happens less often than it should. We build pipelines that make builds, tests, and deployments run the same way every time. We have worked with hundreds of YAML pipelines and templates in Azure DevOps for a large platform, and with GitHub Actions, Vercel, and Fly.io in smaller projects.

We have also built an internal bot that posts pull request, deployment, and release notifications to Microsoft Teams, so the team can see what is happening without watching several tools.

Choices we make when designing CI/CD pipelines

A pipeline is code the whole team depends on, and it deserves the same care as the application. These are the choices we make most often:

• Build once, deploy many times. The same artefact or container image is promoted from test to production, rather than rebuilt for each environment.
• Shared templates over copying. Common build, test, and deployment steps live in versioned templates in Azure DevOps or reusable workflows in GitHub Actions, so an improvement reaches every pipeline at once.
• Federated identity instead of stored secrets. Workload identity federation with OIDC lets the pipeline sign in to Azure without keys that need rotating.
• Fast feedback on pull requests. Linting, unit tests, and security scanning run on every change, while heavier integration and load tests run before production.
• Versions from Git. GitVersion derives the version number from history, so nobody has to remember to bump it.

The goal is that a new service gets a working pipeline by adopting existing templates, not by writing everything from scratch.

CI/CD for apps, services, and your own servers

Mobile apps have their own needs. We automate signing in Xcode and Gradle and distribution to TestFlight, Google Play tracks, and Firebase App Distribution, so testers and users get new versions without manual uploads.

Not everything needs a large cloud platform. For smaller services we run containers on a VPS with Caddy, systemd, backups, and deploy webhooks, or on Fly.io. We also ship our own open source as a Docker image and a StartOS package, so others can run it themselves.