Azure Data Factory · FedRAMP Moderate engineering

Deploy Azure Data Factory to Azure Government with reviewed CI/CD

Build one reviewed artifact, parameterize cloud-specific resources, and release it with least-privilege deployment credentials and a trigger plan. Keep pipeline deployment separate from publishing this website.

By Flat Spell Technologies · Technical review: October 7, 2026

1. Separate development authoring from release deployment

Microsoft recommends Git integration on the development factory, with test and production changed through CI/CD. Put ADF JSON resources in a dedicated authoring root; unrelated files can cause resource-loading or validation failures. Protect the collaboration branch, require review, and record the commit, environment, dependency versions, and artifact digest for each release.

This guide describes a separate Data Factory delivery pipeline. The Flat Spell website’s GitHub Action uploads static public content to S3 and does not provision Azure resources. The snippets below are reference components for your approved delivery environment; they are not added as an executable Azure deployment workflow in this repository.

Keep factory identity permissions distinct from deployment permissions. Use an approved federated workload identity or service connection where supported by your CI provider and Government environment. Scope the deployer to the required resource group or resources, and make role-assignment administration a separately reviewed operation.

2. Validate resources and export a reproducible ARM artifact

Microsoft’s automated-publishing flow uses @microsoft/azure-data-factory-utilities. Its current guidance specifies Node.js 20.x and compatible dependencies. Confirm your approved supported runtime and package compatibility at release time, pin the utility version and transitive dependency lockfile, and build with npm ci rather than resolving new versions on each release.

The following package excerpt defines the build command. It is not a complete package manifest; add the reviewed utility dependency and lockfile in the dedicated delivery project, not the website upload:

{
  "scripts": {
    "build": "node node_modules/@microsoft/azure-data-factory-utilities/lib/index"
  }
}

# Run in the dedicated ADF delivery project.
npm ci
npm run build validate "$ADF_RESOURCE_ROOT" "$DEV_FACTORY_RESOURCE_ID"
npm run build export "$ADF_RESOURCE_ROOT" "$DEV_FACTORY_RESOURCE_ID" ArmTemplateOutput

Archive generated templates and parameter schemas with the commit and digest. Promote the same reviewed artifact through environments; rebuilding from a moving branch during production release defeats artifact provenance. ADF utility validation checks resource structure, not live identity, Private Link approvals, data fidelity, or the provider authorization boundary.

3. Parameterize Government endpoints and environment dependencies

Use environment-specific factory names, resource IDs, regions, identities, Key Vault URLs, SQL hosts, ADLS URLs, runtime references, and managed private endpoint targets. Do not switch only the subscription ID while leaving commercial database.windows.net, dfs.core.windows.net, or public-cloud identity assumptions in the artifact.

The factory CLI environment is AzureUSGovernment; connector-specific cloud properties can use different spellings. For example, the ADLS connector’s service-principal property documents AzureUsGovernment. These are different APIs, so verify the accepted value for each field rather than normalizing them by intuition.

Keep secrets in the environment’s Key Vault and preserve intended secret names or version references. Keep IR names and types aligned across environments as required by the ADF release model. Use separate production runtime hosts and permissions where separation is required; sharing a self-hosted IR also shares an execution and credential boundary.

4. Review the deployment in the selected cloud

After approved authentication, the following commands validate and inspect a resource-group deployment. They do not create the deployment. Review template and parameter paths, target resource group, and identity permissions before running them in your environment.

az cloud set --name AzureUSGovernment
az account set --subscription "$APPROVED_SUBSCRIPTION_ID"
az deployment group validate --resource-group "$TARGET_RESOURCE_GROUP"   --template-file ArmTemplateOutput/ARMTemplateForFactory.json   --parameters @approved-government.parameters.json
az deployment group what-if --resource-group "$TARGET_RESOURCE_GROUP"   --template-file ArmTemplateOutput/ARMTemplateForFactory.json   --parameters @approved-government.parameters.json

Inspect changes to linked-service hosts, runtime type, source queries, trigger definitions, identity assignments, network exposure, and destination paths. Ensure deployment output and build logs do not disclose secure parameter values. Review any resource deletion deliberately; an incremental ARM deployment does not automatically implement the exact cleanup policy you need.

Managed private endpoint deployment has restrictions when an existing endpoint’s properties change. Parameterize target resource IDs and verify the endpoint lifecycle for each environment. Creating the endpoint is not approval: wait for the target owner’s approval and perform a real connection test before a production trigger is enabled.

5. Capture trigger state and gate reactivation on acceptance tests

Before deployment, snapshot which triggers are active and which are intentionally disabled. Stop the affected triggers under the release plan and wait for in-flight runs or apply a documented cancellation/drain policy. Microsoft provides pre/post-deployment scripts; its Version 2 script can focus on changed triggers. Review its cleanup and restart behavior, use supported PowerShell Core/Az module versions, and pin the reviewed script version.

After template deployment, verify linked services, private endpoint approvals, runtime health, scoped data permissions, and a synthetic pipeline run. Re-enable only the previously intended triggers after those checks pass. Unconditionally restarting every trigger can run a pipeline that was disabled for an operational reason.

Storage-event triggers add Event Grid and storage dependencies. Verify feature availability, subscription ownership, permissions, and filters in the target cloud. Treat events as inputs that can be retried or duplicated; use a durable batch/event key and the same idempotent publication contract described in the incremental-load guide.

6. Rehearse rollback and preserve evidence

Retain the previous artifact, parameter set, trigger snapshot, identity configuration, and compatible control-table schema. Redeploying older pipeline JSON does not undo external data writes, restore deleted files, or rewind a committed cursor. Plan data-state recovery and schema compatibility separately from configuration rollback.

Reject missing or invalid resource definitions before artifact publication.
Reject a Government release that targets a commercial store unintentionally.
Keep triggers stopped while endpoint approval or a synthetic acceptance run fails.
Verify a previously disabled trigger remains disabled after deployment.
Replay a retained synthetic batch after rollback and reconcile publication and checkpoint state.

Package the commit, dependency versions, artifact digest, review result, endpoint approvals, acceptance run IDs, and final trigger state. Continue with stateful ingestion recovery and operational evidence.

Sources and technical review

Technical review: October 7, 2026. Recheck cloud, regional, connector, and authorization scope before implementation.

Public offering and service-scope checks are documented in the Data Factory hub. The protected provider authorization package and live Azure behavior have not been reviewed or tested by these guides.