> 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.md). # Migrating to codev If your team already runs sfp in your own CI — a community or [sfp-pro](https://docs.flxbl.io/flxbl/sfp) workflow — codev runs those same commands. Today your pipeline — GitHub Actions, Buildkite, or another CI system — invokes `sfp build`, `sfp install`, `sfp release`, prepares pools, and leases review environments itself. From v51, sfp runs against [sfp server](https://docs.flxbl.io/sfp-server); it is no longer a standalone CLI, so every sfp workflow needs a server. codev is the platform UI over that server: the sfp CLI runs under the hood, and codev connects to your repository, listens for push and pull-request events, and runs build-on-merge, validation, and pooling for you. The commands don't change; what changes is that you stop wiring them into CI, and the server runs the sfp CLI. You do not switch everything at once. The move is **gradual and side-by-side**: hand one capability — or one domain — to the server, watch it, then hand over the next, while the rest of your pipeline keeps running. During the move, builds the server produces and builds your own CI still produces can appear together on the same [Builds](/flxbl/codev/ci-cd/overview.md) page — provided your pipeline runs sfp-pro on the same release as the server (see [While you still run some builds yourself](#while-you-still-run-some-builds-yourself)). ## Start from your CI system The steps below are the same whatever CI you run today. For a walkthrough mapped to a real pipeline — the exact jobs and commands you have now, and what replaces each one — start with the guide for your CI: {% content-ref url="/pages/ngssqwXFjYh1e4u95VqH" %} [From GitHub Actions](/flxbl/codev/migrating/migrating-to-codev/from-github-actions.md) {% endcontent-ref %} {% content-ref url="/pages/meRaxjlgUGUkBjqqJObO" %} [From Azure DevOps](/flxbl/codev/migrating/migrating-to-codev/from-azure-devops.md) {% endcontent-ref %} {% content-ref url="/pages/bu6SRiIeMKkWudjVfDLi" %} [From Buildkite](/flxbl/codev/migrating/migrating-to-codev/from-buildkite.md) {% endcontent-ref %} ## How codev replaces your pipeline In a self-run pipeline, your CI holds the whole flow: a webhook or push trigger starts a job, the job pulls the sfp image, and each sfp command runs on your runner. With codev, that orchestration moves to the server: * **Onboarding registers webhooks on your repository.** Instead of your CI reacting to a push, the push notifies codev directly. * **The server runs the workflow.** codev detects which [domains](/flxbl/codev/ci-cd/overview-1.md#domains) a change touches, builds only those, and produces a release candidate — on its own image, so there is no sfp image for you to install, pin, or upgrade. * **Your CI keeps whatever you haven't moved.** Anything you still run yourself continues exactly as before, and its results still show up in codev. ## Step 1 — Connect the repository to sfp server codev runs on an [sfp server](https://docs.flxbl.io/sfp-server) instance connected to your source host. Connecting a repository is what creates the webhooks the server listens on. Set up the source-control integration for your host, then add the project: {% content-ref url="/pages/25rvgIGQsDaJouzhnFbE" %} [Source Control](/flxbl/codev/integrations/source-control.md) {% endcontent-ref %} * On **GitHub**, codev is backed by a GitHub App; onboarding installs it on your repositories and registers the webhooks. See [GitHub](/flxbl/codev/integrations/source-control/github.md). * On **Azure DevOps**, codev authenticates as a service principal and subscribes to your repository's events. See [Azure DevOps](/flxbl/codev/integrations/source-control/azure-devops.md). Once the integration is in place, add the repository under **Settings > Projects**. This is a one-time setup; from here on, the server is notified of pushes and pull requests directly.
The Settings > Projects page listing connected repositories from GitHub and Azure DevOps, each with its URL and active status

Settings > Projects — every repository connected to the server, whichever host it lives on. Adding a project here is what registers the webhooks.

## Step 2 — Turn on server-managed builds, gradually With the repository connected, you decide what the server runs. This is controlled per project from the **Builds** page under **Workflow Settings**, and it is incremental: nothing you do not switch on changes.
Build Workflow Settings dialog with the Enable server builds toggle, branch exclusions, and domain build scope

Build Workflow Settings. Turn server builds on when you are ready; builds from your existing CI keep appearing on the same page, so the two run side by side during the move.

Three independent controls determine what the server runs: * **Enable server builds** — the master switch. Off, and the server ignores pushes and your CI stays fully in charge. On, and the server runs [build-on-merge](/flxbl/codev/ci-cd/overview.md). * **Exclude specific branches** — keep the server off certain branches (for example `release/*`) while it runs on others. Supports wildcards. * **Domain build scope** — the per-domain control: hand over one domain at a time. ### Move one domain at a time A [domain](/flxbl/codev/ci-cd/overview-1.md#domains) is a group of packages defined by a release config in your repository. **Domain build scope** lets one team hand a single domain to codev while every other domain in the same repository stays on the existing pipeline.
Domain build scope rule limiting the release/* branch to the core and sales domains

A branch-scoped allow-list: on release/*, codev builds only the listed domains and skips the rest. Leave the list empty and every impacted domain builds — the default.

Each rule pairs a **branch pattern** (wildcards allowed, e.g. `main`, `release/*`) with an **allow-list of domains**. When a merge matches a rule, the server builds only those domains; the first matching rule wins. An empty list — or no matching rule — means every impacted domain builds, which is the behaviour before you add any rule. So you can move one domain on one branch, verify it, and grow the list over time without touching the domains your own pipeline still owns. ## Step 3 — Let codev run validation and environments Build-on-merge is usually the first workflow teams move, but the same handover applies to the rest of the pipeline your CI runs today: * **Pull-request validation and review environments.** In a self-run pipeline you lease a review org, hold a lock, and return it with explicit CLI calls. codev manages the lease and the exclusive access for you. {% content-ref url="/pages/yU7u82dhuU3VcZt9vJCB" %} [Review Environments](/flxbl/codev/inspect/review-environments.md) {% endcontent-ref %} * **Sandbox and scratch-org pools.** Pool preparation and assignment move from scheduled CI jobs to the server. {% content-ref url="/pages/M0bhpsm41RKEnY2bfOZc" %} [Pools](/flxbl/codev/pools/overview.md) {% endcontent-ref %} Move these when you are ready; each is independent, and each one you hand over removes a step from your own pipeline. ## While you still run some builds yourself During the move you will usually keep some builds in your own pipeline. Running the sfp CLI in your pipeline against sfp server — so its builds report to the server and appear on the [Builds](/flxbl/codev/ci-cd/overview.md) page alongside codev's — requires **sfp-pro**, the [premium addon for Build Your Own workflows](https://docs.flxbl.io/flxbl/sfp). The community edition does not report to sfp server: a community pipeline adopts sfp-pro to run side by side during the move, or cuts over to codev directly. With sfp-pro, coexistence holds **as long as the sfp CLI in your pipeline is on the same release as the server.** The CLI reports build and package metadata through a contract that moves with the server, so a current CLI and the server understand each other and their builds show up side by side. Running an **outdated** CLI against a current server is not supported. Coexistence lasts for the duration of the migration. Before you connect a repository, bring your pipeline's sfp-pro CLI up to the server's release; from there, hand each capability over and retire the corresponding CLI step. Confirm the CLI version against the current command reference: * [Upgrading the CLI from v50 to v51](https://docs.flxbl.io/sfp/getting-started/docker-images/sfp-pro/upgrading-v50-to-v51) — the image bump and the handful of moved commands, if your pipeline is still on v50 * [sfp CLI reference](https://docs.flxbl.io/sfp) Work through it in that order: bring the CLI current, connect the repository, hand over build-on-merge, then validation and pools. Each self-run step is retired as the server takes it over. --- # 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.md?ask=&goal= ``` `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.