How do you connect model registry events to deployment pipelines?

Connect the model registry to CI/CD using an event-driven or reconciliation workflow, but treat the event as a signal to verify—not as authorization to deploy. A production release should resolve an immutable model version, confirm its approval, execute deployment safely, and verify which version actually serves traffic.

Question 87 explained approval gates. This question explains how an approved registry change reaches a deployment pipeline, reliably and safely.

Beginner-friendly example

A food-delivery team has delivery_eta version 12 serving production. Engineers have registered version 13 and approved it after quality and latency checks.

A release job updates the registry's champion alias to version 13. An integration detects that change and starts CI/CD to deploy the fixed version delivery_eta/13.

MLflow Model Registry
  champion → version 13
        │ alias event / polling observation
        ▼
Authenticated receiver or scheduled reconciler
        │ validates event, deduplicates, queues
        ▼
CI/CD workflow
        │ fetches exact version and verifies approval
        ▼
Build/prepare deployment → rollout → health checks
        │
        ▼
Record observed serving version + outcome

The event does not guarantee successful deployment. Version 13 is only live when the serving platform confirms it is loaded and healthy.

1. Choose the trigger carefully

• Model version created: Useful to start validation, scanning, or packaging. It should not normally cause immediate production deployment.
• Approval event: A trusted release-control system can signal that a fixed model version has completed required review.
• Alias change: A champion alias creation/update can trigger *deployment reconciliation*, but the pipeline still checks current intent and authorization.
• Periodic polling: An alternative when native webhooks are unavailable or unsupported.

OSS MLflow has experimental Model Registry webhooks for version/tag/alias events. They require a SQL backend rather than a file-based backend; support differs from managed MLflow products. Verify the exact event types in your installed version.

For example, an MLflow alias event may carry a model name, alias, and version. Treat it as untrusted input until authenticated and checked against the registry's current state.

2. Webhook receiver versus polling

Webhook design

• Register a webhook for relevant registry events, ideally alias updates or dedicated release signals.
• Verify the webhook's HMAC signature using the configured shared secret; reject invalid signatures and limit message size.
• Persist an event in a queue/database and return a quick response.
• Have an authenticated worker re-read the current version and release approval.
• Dispatch a CI/CD workflow using a protected service identity.

Polling/reconciliation design

• Every few minutes, query the registry for the desired approved version.
• Compare it with the last successfully deployed version.
• Queue deployment only when desired and actual versions differ and release conditions hold.
• Keep retrying failed reconciliation with bounded backoff and alerting.

Polling avoids dependence on webhook delivery; webhook triggering usually reduces latency. A robust platform may use both: webhooks for low latency, periodic reconciliation for missed events.

3. Example webhook handler logic

PYTHON
def process_event(event):
    # Authentication/HMAC verification already completed
    if event["event_type"] not in {
        "model_version_alias.created",
        "model_version_alias.updated",
    }:
        return "ignored"

    payload = event["payload"]
    if payload["name"] != "delivery_eta":
        return "ignored"
    if payload["alias"] != "champion":
        return "ignored"

    # Re-read the live registry instead of trusting the payload.
    current = registry_get_alias("delivery_eta", "champion")
    desired_version = str(current.version)

    # A trusted approval system validates the exact version/artifact.
    if not approval_service_allows("delivery_eta", desired_version):
        return "blocked"

    key = f"production:delivery_eta:{desired_version}"
    queue_deployment_once(key, "delivery_eta", desired_version)
    return "queued"

This is architecture pseudocode, not a fully implemented webhook server: registry_get_alias, approval_service_allows, and queue_deployment_once represent services you must implement. A secure receiver must also verify signatures, authorize ingress, handle malformed payloads and store event processing state.

4. Connect to CI/CD

CI/CD options include GitHub Actions, GitLab CI, Jenkins or a cloud deployment service. For GitHub Actions, an authorized integration can trigger a preconfigured workflow through workflow_dispatch or a suitable repository event.

Pass a fixed model name/version and deployment environment as inputs. Do not pass latest and assume it still resolves to the originally approved candidate.

An illustrative workflow fragment:

YAML
name: Deploy approved model
on:
  workflow_dispatch:
    inputs:
      model_version:
        description: Approved immutable model version
        required: true
        type: string

jobs:
  deploy:
    environment: production
    runs-on: ubuntu-latest
    concurrency:
      group: delivery-eta-production
      cancel-in-progress: false
    steps:
      - name: Resolve and validate release
        run: ./scripts/check-model-approval.sh
      - name: Deploy immutable model
        run: ./scripts/deploy-model.sh
      - name: Verify actual serving version
        run: ./scripts/check-serving-version.sh

The shell scripts are placeholders. The real workflow should obtain model version from inputs through validated environment variables, confirm provenance and approval, and use a protected identity for deployment. An event trigger must not bypass the human and automated review from Question 87.

5. Why idempotency matters

Webhook deliveries may be retried, and polling may observe the same version repeatedly. Without idempotency, one approved model could trigger multiple deployments.

Example: the alias change to version 13 is observed 3 times.

• Without deduplication: Potentially 3 pipeline executions and 3 competing deployments.
• With a durable key production:delivery_eta:13: One intended release is tracked; repeated events are ignored or attached to its existing status.

A practical idempotency ledger has a unique key, a state such as PENDING, RUNNING, SUCCEEDED, or FAILED, timestamps and the orchestrator execution ID. Use atomic creation or database uniqueness constraints; a simple in-memory set will not survive service restarts.

A FAILED release must be eligible for controlled retry rather than permanently ignored because its key already exists. Distinguish event deduplication from deployment attempt IDs.

6. Handle out-of-order events and alias races

Imagine the registry first points champion to version 13, then to version 14 before the version-13 event is processed. The older event must not silently downgrade production.

At dispatch time:

1. Query the current desired registry reference.
2. Verify the candidate's immutable ID, approval and artifact integrity.
3. Check the deployment coordinator's latest intended release.
4. Serialize conflicting deployments per service/environment.
5. Before cutover, ensure the target version is still authorized and desired.

The platform must define what happens when desired state changes during a rollout: cancel a safe pre-cutover attempt, complete and then reconcile, or require explicit operator review.

7. Verification and failure handling

After dispatch, verify at least:

• Pipeline status: Did the workflow finish successfully?
• Model identity: Does the serving endpoint report the expected registered model version and artifact digest?
• Application health: Are startup checks, schema contracts and readiness probes passing?
• Canary/traffic: If applicable, is observed error rate and latency within thresholds?
• Audit trail: What event, approval and deployment execution produced this release?

Failure cases and actions:

• Invalid webhook signature: Reject and alert if suspicious.
• CI/CD API unavailable: Retain the queued intent and retry within policy.
• Model artifact missing: Block deployment and retain the previous serving version.
• Approval revoked: Stop an unsafe pending release.
• Deployment succeeds but health checks fail: Restore or retain the last known good serving version through a controlled rollback.
• Event lost: Reconciliation discovers the mismatch later.

Do not declare completion merely because a registry alias changed or a CI/CD job started.

8. Example event-volume calculation

Suppose the platform receives 20 model registry events daily, of which 5 represent desired approved production changes. If each delivery event is retried twice on average, a naïve integration could schedule up to 15 production workflows, instead of 5 intended releases. Durable idempotency and a desired-state check keep unnecessary deployments from multiplying.

Common mistakes

• Automatically deploying every newly created model version.
• Trusting an unverified webhook body or long-lived public trigger URL.
• Passing mutable @champion into CI/CD without pinning the resolved version.
• Acknowledging an event before persisting it somewhere durable.
• Launching duplicate or out-of-order production rollouts.
• Assuming updating an alias reloads all existing serving processes.
• Treating a green pipeline status as sufficient proof that the correct version is live.

In short: Use registry webhooks or polling to detect changes, authenticate and persist the signal, verify fixed-version approval, enqueue idempotent CI/CD execution, then confirm the actual deployed model and health. The next question covers safe rollback of registry promotions.