Deploying Configuration

Why the separation exists#

It looks like an extra step, and it is doing real work.

Large changes go live atomically. A month of modelling work on a running plant can be built, reviewed, and turned on in one action, rather than each half-finished measure starting to collect as it is saved.

You can review before activating. The deployment view shows exactly what differs from what is running, which is a genuine change review.

Mistakes stay contained. A measure with a wrong tag or an unguarded division sits harmlessly until deployed.

You can turn things off without deleting them. Undeploying stops a connection or engine while keeping its configuration intact.

The deployment states#

Every deployable object carries a state, shown in the Deployment view.

What gets deployed#

Deployment applies to the objects in the Deployment view — Platforms and the service objects on them:

• Connections — until deployed, no data is read through them
• Engines — the Data Engine that retrieves, aggregates, and calculates
• Servers — Flow Server, serving the web client
• Integration Engines — running data consumers
• Message Engines and Notification Servers — limits and alerting
• Consumers — outbound publishing

Model content — measures, metrics, charts — becomes active through the engine and connection that serve it. In practice a new measure on an already-deployed connection and engine begins calculating once the deployment is refreshed; a new connection must itself be deployed first.

The order that works#

When bringing up something new, deploy from the outside in:

1. Platform — confirm its host name matches the machine running Flow Bootstrap
2. Connection — so data can be read
3. Engine — so it can be retrieved, aggregated, and calculated
4. Server — so it can be seen
5. Consumers and message engines — so it can be published and alerted on

Deploying an engine before its connection generally works, since the engine will start using the connection once it appears, but the order above gives cleaner logs and fewer transient faults.

The Platform host check#

Worth stating on its own because it accounts for so many wasted afternoons.

Flow Bootstrap claims the Platform whose host name matches the machine it is running on. A Platform naming a different machine will never start, no matter how many times you deploy it.

This bites in three situations:

• A production database restored onto a test or DR server
• A server renamed, or replaced with a differently named one
• A model built on one machine and moved to another

The fix is to correct the Platform's host, or create a Platform for the new machine and place the service objects on it.

Deploying from the CLI#

Deployment is scriptable, which matters for repeatable environment builds:

# deploy an object
"Flow Config.exe" --host <server> --database <db> --deploy --<entity>-id <id>

# stop it without losing configuration
"Flow Config.exe" ... --undeploy --<entity>-id <id>

# see what is running and what differs
"Flow Config.exe" ... --deployment-status

--deployment-status is the useful one for automation. Combined with --deployed-only and --undeployed-only filters, it lets a script assert that an environment is in the expected state — a good final step in a build pipeline, and a good health check afterwards.

Undeploying deliberately#

Undeploy rather than delete when you want something to stop:

• Taking equipment out of service for a long outage — undeploy its connection and stop pointless failing queries
• Suspending a consumer while a downstream system is being upgraded
• Isolating a faulting object while you investigate

The configuration is preserved, so redeploying restores it exactly. Deleting and rebuilding loses history, identity, and anything referencing it.

After deploying#

Confirm it worked rather than assuming:

1. The state shows Deployed, not Different or Faulted.
2. Values are appearing for the measures you expected — check the newest interval, not today's total.
3. The Flow event log has no new errors.
4. Dependent measures further up the chain are also producing values.

If values do not appear, work through Diagnosing Missing Data rather than redeploying repeatedly.

Working practices#

Deploy in maintenance windows for anything substantial. Deployment restarts service objects, so there is a brief gap in collection.

Coordinate with other modellers. One person deploying while another is mid-change will activate half-finished configuration. Agree who deploys.

Check for Different before you finish. Leaving objects in the Different state means the model in the database is not the model that is running, and the next person will not know which is intended.

Keep a note of what you deployed and when. When a number changes shape on a chart, the first question is always "what changed", and a deployment log answers it in seconds.

Common problems#

See also#

• A Tour of Flow Config
• Infohub Architecture at a Glance
• Running the Data Engine
• Diagnosing Missing Data