Setting up DevOps from nothing, for a .NET and Angular team
The situation
The team writes good code and ships it badly. The API gets published from Visual Studio by whoever is around, the Angular build runs on one developer's machine, and the person who knows the deployment steps is the constraint on every release. Connection strings sit in appsettings.json in the repository. Nobody can say with certainty which commit is currently in production, and rollback means restoring a backup and hoping.
How I'd approach it
Start with the parts that unblock everything else. A branching model the team will actually follow — for a small team that's usually short-lived branches off trunk, because Gitflow's ceremony costs more than it returns below a certain headcount. Then the build: restore, test, publish artifacts for the API and the SPA in one pipeline. The Angular app gets built once and configured at runtime, so the identical artifact promotes from staging to production rather than being rebuilt per environment — rebuilding per environment means the thing you tested is not the thing you shipped. Infrastructure moves to Bicep, secrets to Key Vault accessed through managed identity, and database migrations become a deliberate gated step in the release rather than something that happens on app startup.
What usually bites
Two things, reliably. The first is EF Core migrations running automatically at startup — fine on one instance, a race the moment you scale out, and impossible to roll back cleanly under pressure. The second is that the test suite you want to gate the pipeline on frequently does not exist yet, and a quality gate that everybody learns to override is worse than no gate at all. That needs to be said in the first week, because it changes what the engagement can honestly promise.
What I'd cut first
Full infrastructure-as-code coverage on day one. Get the application pipeline working against the infrastructure that already exists, then bring environments under Bicep one at a time. Blue-green deployments, multi-region and automated performance gates all come later, if ever.
When I'd tell you not to
A two-person team releasing once a month to a single environment can get most of the benefit from a documented script and a checklist. Pipelines earn their keep when release frequency or team size makes coordination the bottleneck — I'd rather say that than build ceremony nobody needs.