How Teal Partners delivers robust software with Azure DevOps. Read the developer expert blog by Bert.
Speed and reliability can reinforce each other, given a development approach that is set up for it. Our developer Bert explains how the Flex Income Plan team does that.
For eight years now, five of us have been working on Flex Income Plan (FIP) for SD Worx. FIP is Belgium's largest flexible benefits platform, with more than 200,000 users. A user base of that size, doing business-critical things, needs infrastructure that holds up and a development cycle that can move.
We manage our own fleet of 40 Docker-based build agents, and it builds our entire application stack in three minutes.
That speed feeds quality directly. We get feedback immediately, we run thousands of tests at the same time, and we can ship a fix or a feature when it is ready instead of when the pipeline frees up.
A three-minute build is only useful if what comes out of it is safe to ship. On a platform as complex as FIP, that takes a strict Software Development Lifecycle (SDLC), and we have mapped its five stages onto the Azure toolset.
The difference is in how far we have taken the automation. A change does not simply "go through the pipeline". It passes peer review, automated testing, security and licence checks and quality gates, and it comes out as a versioned artefact before it moves towards production.
Before any code reaches Azure DevOps, a developer has to be able to build, test and debug a feature on their own machine. FIP is a distributed system with several APIs, front ends, databases and dependencies, and systems like that tend to end up with a long setup manual and the familiar "it works on my machine" conversation.
We use .NET Aspire to orchestrate our local development environments, for three reasons.
A developer starts the whole stack, external dependencies included, with one command or a press of F5, instead of juggling terminal windows, scripts and hand-rolled Docker Compose setups.
The local architecture is modelled centrally in a C# AppHost project, so everyone runs exactly the same topology. Aspire assigns ports, injects the right connection strings and handles service discovery, which leaves no local configuration to get wrong.
Aspire ships a local developer dashboard with real-time distributed traces, structured logs and metrics for every running service. Reading that beats searching through fragmented console output, so we debug interactions between microservices quickly and get the code in good shape before our build agents take over.
Alongside the infrastructure automation, we have put Claude deep into the daily engineering workflow.
Our developers use Claude Code to work directly against our repositories, which speeds up both feature development and complex refactoring. We treat the AI context as code: Markdown files with instructions for Claude live in the Git repositories themselves, holding our architectural guidelines, coding standards and business context, so its support fits FIP instead of a generic .NET project. We also use Claude to analyse long technical documents and to run broad automated reviews of the codebase, which surfaces subtle edge cases, security considerations and architectural improvements early.
Why put AI that deep into a structured SDLC? It works as a tireless pair programmer and as an extra critical layer in peer review. Using it to enforce standards and catch nuance early means the code that reaches our build agents is already better, which cuts rework and keeps our overall development speed up.
Once local development has been pushed, our build infrastructure does the gatekeeping. Every submission triggers a full set of checks that finishes within minutes:
- SonarCloud runs static analysis for vulnerabilities and code smells. If the predefined quality gate is not met, the build fails there.
- FOSSA scans dependencies for licence compliance and security risks.
- Thousands of unit and integration tests run concurrently, which is what makes refactoring safe and catches bugs early.
- Certified builds are stored as immutable artefacts, so the exact version we tested is the version that goes live.
Several developers in the same codebase at the same time needs clear agreements. We use Git within Azure DevOps to manage parallel work: isolated feature branches and a strict pull-request process, so every change gets a peer review before it even wakes up a build agent.
After the build, each update passes through four environments:
1. Feature, for testing new functionality in isolation.
2. Staging, for extensive internal functional and regression testing.
3. Acceptance (UAT), specifically for testing integrations with external third parties.
4. Production, the live environment for more than 200,000 users.
A three-minute build is worth little if the step to production is unreliable, so our release process is built around control, scalability and visibility as much as speed.
We define our infrastructure as code. Environments are provisioned through ARM templates within SD Worx's secure Enterprise-Scale Landing Zone (ESLZ), and that infrastructure goes through the same version control and peer reviews as our software. It keeps manual configuration errors and environment drift out. Database updates run predictably as part of the same automated release cycle.
After a deployment we want to know how the system is running, not only whether it is running. Serilog, Application Insights and OpenTelemetry let us trace a request across microservices, read structured logs, and follow user events and audit logs. For a platform processing sensitive employee financial data, that traceability matters: it shows performance bottlenecks early, shortens debugging, and records precisely who did what and when.
We design scalability deliberately too. Components differ in load and in how directly they affect the user, so our applications are spread across different App Service Plans, each with its own scaling rules.
Availability is monitored continuously. Every component has a health probe that actively checks the status of its underlying dependencies, and UptimeRobot watches the whole ecosystem 24/7. That keeps downtime to a minimum when thousands of users are running transactions at once.
Our pipelines and observability catch vulnerabilities and bugs early. Protecting the data of 200,000 users takes ongoing validation by human experts.
Every year we commission independent, specialist security firms to run comprehensive penetration tests against our defences, architecture and code, assessed on current attack vectors. On top of that we run a bug bounty programme on Intigriti, where a global community of vetted ethical hackers tests our systems continuously. That is where specific logic flaws turn up, and it lets us patch them long before anyone can abuse them.
If a security incident or data breach does happen, the protocol is immediate. We report it without delay and escalate to SD Worx's specialist security task force for containment, mitigation and regulatory reporting.
For business-critical software like Flex Income Plan, speed and stability are not something we trade off against each other. The process is designed so that one strengthens the other, and every tool in it has a specific job.
.NET Aspire and Claude let our developers write and validate well-optimised code locally. Azure DevOps and our fleet of 40 Docker agents test, verify and build that code in three minutes. Infrastructure as code, targeted autoscaling, observability and continuous security testing keep the platform secure, cost-efficient and available after deployment for more than 200,000 users.
Owning that full cycle, and getting the most out of the Microsoft ecosystem, is what lets us keep releasing at this pace on a platform people depend on.
