Azure DevOps engineering
Azure DevOps is usually inherited rather than chosen. Classic release pipelines nobody wants to touch. A build slow enough that people batch their merges. And one person who knows why the build machines are set up like that.
01Capabilities
The delivery estate inside a Microsoft shop
This page is about the toolchain, not the cloud. Which cloud to run on is a separate decision and it lives on Azure and AWS; Azure DevOps deploys happily to either one and to your own data centre. Four shapes of work, inside DevOps consulting.
- Release
Pipelines that release, not only build
Definitions in version control, with named environments, gates and approvals, so shipping is a routine event rather than a coordinated effort. A build that produces something nobody can deploy safely has done half the job.
- Migration
Classic definitions and old history, moved without a freeze
Classic build and release definitions become checked-in pipelines, and legacy version-control history moves into Git. The migration itself is mechanical. Sequencing it so the team keeps shipping through it is the part worth paying for.
- Governance
Branch policies and permissions that match how you work
Required reviewers, build validation, work item linking and access that reflects your real organization. Governance people route around is worse than none, because it leaves behind an audit trail that lies to whoever reads it next.
- Traceability
Work item to commit to build to approval
An unbroken line from the request to the person who let it into production, which is a compliance artifact in fintech and regulated healthcare work rather than a nice-to-have. This is where the toolchain is genuinely strong, and where an outside read is a quality audit.
02Fit
Follow your identity, your code and your work items
Azure DevOps is a strong toolchain and a poor reason to change anything that already works. The decision is about where your identity, your code and your work items already live, not about a feature comparison, and we hold no reseller incentive in either direction. Five of the six rows below send you somewhere other than an Azure DevOps project with us, and three of them name no unicrew page at all.
| Your situation | What we recommend |
|---|---|
| A Microsoft-centric organization, Entra ID for identity, work items already in Boards | Use Azure DevOpsIdentity, permissions and traceability across Boards, Repos and Pipelines are the real advantage here, and they compound over years. |
| Your code already lives on GitHub and the team works there every day | GitHub ActionsKeeping review, automation and packages in one place beats adding a second tool, and pipeline syntax is not the differentiator anyone hopes it is. |
| A working Jenkins or GitLab setup that people actually trust | Do not migrateA pipeline migration consumes real delivery capacity and produces nothing a user can see. Tidiness on an architecture diagram is not a strong enough reason. |
| Boards suits how you plan, but your code belongs on GitHub | Split it on purposeBoards plus GitHub is a supported and common arrangement. It beats forcing either half to move so a diagram looks neater. |
| The build is slow and everybody waits on it | Not the vendorCache dependencies, split the tests across machines, right-size the pool and remove the stages that run one after another for no reason. |
| The pipeline is fine and the tests are what nobody trusts | Different serviceThat is QA and test automation. We would rather say so than rebuild delivery machinery that already works. |
Scope
We own whether releasing gets safer and duller. That covers the parts nobody enjoys. Where secrets live, who can approve their own change, and whether the thing that was tested is the thing that shipped. It also covers whether your team can change the pipeline without asking us. unicrew has run delivery for clients since 2012. We have 100+ senior in-house engineers across six countries. We work under an ISO 27001:2022 certified information-security management system. Where the toolchain turns out to be fine and something else is wrong, that is the answer you get.
Ask a Microsoft shop where its pipeline is actually defined and you rarely get one answer. Some of it is checked into the repository, where anyone can review it. The rest is service connections, variable groups and permissions somebody set through a web interface years ago, with no record of why. Until that second part is written down, every change to delivery is a small act of archaeology and the engineer doing it is guessing. I would rather describe what exists before touching it than explain an outage afterwards.
Oleksandr TrofimovChief Technology Officer, unicrew03Delivery
Taking on pipelines somebody else wrote
Almost every engagement here starts with something already running, so the first job is understanding it rather than replacing it.
- Map what triggers whatEvery pipeline, what fires it, where the artifacts go, which machines run it, and which steps exist because of an incident years ago. Undocumented triggers and manually queued releases are the two usual surprises.
- Build one reference pipelineA single service gets the pipeline we would defend: checked in beside its code, dependencies cached, tests that gate rather than decorate, and one artifact promoted through environments. It becomes the pattern the rest copy.
- Add environments, approvals and promotionNamed environments with the right approvals, secrets read from a vault rather than typed into a variable by hand, and the same artifact moving forward instead of a rebuild per stage. Rebuilding per environment is how a tested build stops being the shipped build.
- Hand over the ownership questionsSelf-hosted against managed machines and what each costs you in maintenance, who administers permissions, how a new service gets a pipeline, and where the shared templates live. If adding a service needs us, the handover failed.
04Stack
What a pipeline here builds and deploys to
The four neighbours of a delivery decision, each with its own page if that is the call you are really making.
05Questions
Questions about Boards, Repos and Pipelines
The six that come up before anyone opens a pipeline definition. If yours is not here, it is a good first message.
Yes, and on delivery work it usually fits well, because the constraints are yours: your permissions model, your release calendar, your auditors. What we will not do is supply hands and treat the delivery outcome as your problem. An architect outside the delivery team reviews the pipeline and branching design. Capacity is managed teams; the outcome is DevOps consulting.
Follow your code and your identity. If your repositories are on GitHub and your engineers live there, keeping review, automation and packages together beats adding a second tool. If your organization runs on Entra ID and your work items are already in Boards, you get a line from request to deployment that is genuinely hard to reconstruct across two products. This is an organizational question dressed as a technical one.
Yes, and we do it one service at a time rather than as a single cutover. The classic definitions keep working while we build checked-in equivalents, verify them against the same artifacts, then retire the old one. The awkward parts are service connections, variable groups and steps whose purpose nobody remembers, so each gets documented before we decide whether it survives the move.
No. The two get bundled in conversation because of the name, and they are separate products. Pipelines here deploy to AWS, to Google Cloud, to your own data centre and to a Kubernetes cluster anywhere, through standard connections and tooling. If you are actually weighing clouds, read Azure against AWS and keep this decision out of that one.
A scoping call with an engineer. For an existing setup we ask for read access to the project and the pipeline definitions, plus one honest account of how the last release went, because that reveals the manual steps no diagram shows. What comes back is written: what to change first and what to leave alone. Most engagements start within two to four weeks.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we offer it once the first read is done, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Inherited a pipeline nobody wants to touch?
Send us a pipeline definition and how a release happens today, including the manual steps. You get an engineer's read on what to fix first, what to delete, and whether the tool is even the problem.