> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/codev/migrating/migrating-to-codev/from-azure-devops.md).

# From Azure DevOps

An Azure Pipelines setup that builds Salesforce with sfp follows the same shape as any self-run CI: a branch trigger starts a pipeline, the job runs in the sfp container, authenticates a Dev Hub, and calls `sfp build`, `sfp install`, `sfp publish`, or `sfp release`. This is a Build Your Own (BYO) workflow, so it runs [sfp-pro](https://docs.flxbl.io/flxbl/sfp). This page maps that shape onto codev: what the server takes over, and what Azure DevOps-specific pieces — Service Principal, webhook subscriptions, pull-request threads, Boards work items — replace the ones you operate today.

Read [Migrating to codev](/flxbl/codev/migrating/migrating-to-codev.md) first for the overall approach — connect the repository, then hand over one capability at a time. This page is the Azure DevOps-specific detail.

## What your pipeline looks like today

A typical build-and-publish pipeline triggers on branch pushes, runs in a container pinned to the sfp image, authenticates on every stage, and calls sfp directly:

```yaml
# azure-pipelines.yml (self-run)
trigger:
  branches:
    include: [main]

pool:
  vmImage: ubuntu-latest

container:
  image: source.flxbl.io/flxbl/sfp-pro:51.x   # you pin and upgrade this
  endpoint: flxbl-registry                     # a service connection you maintain

steps:
  - checkout: self
    fetchDepth: 0
  - script: sf org login sfdx-url -f $(DEVHUB_AUTH_FILE) -a devhub -d
    displayName: Authenticate Dev Hub
  - script: sfp build -v devhub --diffcheck --buildnumber $(Build.BuildId) --branch $(Build.SourceBranchName)
    displayName: Create packages
  - script: sfp publish -d artifacts --npm --scope my-org --gittag --pushgittag
    displayName: Publish artifacts
```

Alongside it, teams usually have per-environment release pipelines (or stages) each running `sfp release -o <env>`, a pull-request pipeline that leases a review org and runs `sfp validate`, and scheduled pipelines running pool preparation. Everything in this model is yours to operate: the image tag, the registry service connection, the Dev Hub auth on every run, and the PR validation plumbing.

## What codev runs instead

Connecting the repository to sfp server (see [Step 1](/flxbl/codev/migrating/migrating-to-codev.md#step-1-connect-the-repository-to-sfp-server)) is what retires the branch triggers. On Azure DevOps, codev authenticates as a **Service Principal** you register once, and onboarding **subscribes to your repository's push and pull-request events** — so a merge notifies the server directly, with no pipeline trigger. Setting up the Service Principal and its permissions is covered end to end in [Azure DevOps](/flxbl/codev/integrations/source-control/azure-devops.md); note that registering the webhook subscriptions requires the Service Principal to have **Project Administrator** access on the project.

| Your pipeline today                                                              | On codev                                                                                                                                                 |
| -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `trigger:` + `container: image: …/sfp-pro:…` and its registry service connection | Webhook subscriptions from onboarding; the server runs on its own image — no tag or service connection to maintain                                       |
| `sf org login` on every run                                                      | The server holds the org connections; no per-run auth                                                                                                    |
| `sfp build --diffcheck`                                                          | [Build on merge](/flxbl/codev/ci-cd/overview.md) — the server detects impacted [domains](/flxbl/codev/ci-cd/overview-1.md#domains) and builds only those |
| `sfp publish`                                                                    | The server publishes package metadata; builds appear on the [Builds](/flxbl/codev/ci-cd/overview.md) page                                                |
| `sfp release -o <env>` per-environment pipelines                                 | [Release candidates and releases](/flxbl/codev/ci-cd/overview-1.md) — target environments chosen at release time                                         |
| PR pipeline leasing a review org + `sfp validate`                                | The server validates pull requests and posts the results back to the PR                                                                                  |
| Scheduled pool-preparation pipelines                                             | [Server-managed pools](/flxbl/codev/pools/overview.md)                                                                                                   |

### Validation results land on the pull request

On Azure DevOps, codev posts validation and analysis results as **commit statuses** and **pull-request comment threads** — the reviewer sees pass/fail state and the detailed result without leaving the PR:

<figure><img src="/files/rPkRAXp2YQHkt2MHFAk2" alt="An Azure DevOps pull request with codev validation threads showing PR Validation passed for the impacted domain, with links to the detailed results"><figcaption><p>What replaces your PR validation pipeline: codev posts the validation outcome per domain as comment threads on the pull request, each linking to the detailed results.</p></figcaption></figure>

Commands (for example requesting a review environment) are issued as PR comments, and codev replies in the same thread. Work item keys referenced in commit messages are detected and surfaced on builds, release candidates, and releases, and codev's release flow can create and update **Azure Boards work items** — so a release request raises a work item your approvers action in Boards. The [Azure DevOps](/flxbl/codev/integrations/source-control/azure-devops.md) integration page lists the full capability matrix.

The work your build stage did per merge shows up on the Builds page, grouped by domain, with no agent or image in your pipeline:

<figure><img src="/files/U0CRrbfw0GNWBqqHI4rH" alt="Builds page listing server-produced builds grouped by domain, with per-domain filtering"><figcaption><p>What replaces the build stage: each merge's impacted domains are built by the server and listed here. Builds your own pipelines still produce appear on the same page, so you can compare during the move.</p></figcaption></figure>

## Move one pipeline at a time

A safe order for a live repository:

1. **Register the Service Principal and connect the repository** — [Azure DevOps](/flxbl/codev/integrations/source-control/azure-devops.md) walks the Entra registration, the integration form, and onboarding. Nothing changes yet: the webhook subscriptions are registered but server builds are off.
2. **Enable server builds for one domain** using **Domain build scope** ([Step 2](/flxbl/codev/migrating/migrating-to-codev.md#step-2-turn-on-server-managed-builds-gradually)). Your `azure-pipelines.yml` still runs for everything else.
3. **Compare.** The server's build for that domain appears on the Builds page beside your pipeline's. When you trust it, remove that domain from your pipeline — or, once every domain is on the server, retire the build stages.
4. **Hand over releases.** Replace the per-environment release pipelines with [release candidates](/flxbl/codev/ci-cd/overview-1.md); release requests flow through Azure Boards work items for approval.
5. **Hand over pools and validation.** Move pool-preparation pipelines to [server-managed pools](/flxbl/codev/pools/overview.md) and the PR validation pipeline to server-run validation with [review environments](/flxbl/codev/inspect/review-environments.md) — results post back to the PR as statuses and threads.

At each step the pipelines you have not moved keep running exactly as before, and their builds still show on the Builds page — provided the sfp-pro CLI in those pipelines is on the same release as the server (see [While you still run some builds yourself](/flxbl/codev/migrating/migrating-to-codev.md#while-you-still-run-some-builds-yourself)). If your pipeline pins an old sfp image, bring it current before you connect, so the builds it still produces report correctly to the server.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.flxbl.io/flxbl/codev/migrating/migrating-to-codev/from-azure-devops.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.