Development, test and production for integration flows
Integrations change more often than the systems they connect. How to separate test from production, promote changes safely, keep secrets out of copies, and keep a history you can review.
Many city integrations have one copy: the one in production. Every change, from a new field to a fix for a failing record, is made live. It works until the day a quick change at 4 pm on a Friday stops the payment file.
Separate environments are standard practice for application code. Integration flows deserve the same treatment, scaled to a small team.
Why integrations need environments
- They write to real systems. A mistake can post payments, close requests or file documents in the wrong place.
- They change often. New fields, new codes, new destinations.
- The people who change them aren't always developers. Analysts and IT generalists need a safe place to try things.
Three environments, or two
| Environment | Connects to | Used for |
|---|---|---|
| Development | Sandboxes or test copies | Building and trying ideas |
| Test | Test systems, close to production | Checking changes before release |
| Production | The real systems | The flows the city depends on |
Small teams often merge development and test into one. That's fine. The essential line is between "where we try things" and "where it's real".
Connections differ, flows don't
The flow itself should be identical in test and production. What changes is the connection: the test Accela environment versus production, the test database versus the real one, the test SFTP folder versus the bank's.
That means each environment needs its own connections, with their own credentials. Secrets should never be copied from one environment to another. When a flow moves to production, each connection it uses should be matched to its production twin.
Promoting a change
Promotion is the step where a tested flow is copied into production. A good promotion process:
- Shows what changed compared with the current production version.
- Maps connections from test to production, so nothing points at the wrong system.
- Runs the flow's tests first, and stops if they fail.
- Arrives turned off, so someone chooses when it starts.
- Is recorded: who promoted what, and when.
If a change has to skip a step in an emergency, that override should be logged too.
Keep a history outside the platform
Version history inside the integration tool is useful. A copy in your own source control is better for some teams:
- Flows saved as readable text, such as YAML, without secrets.
- Every change visible in the repository's history.
- Reviews by a second person before changes merge, if you want them.
- A copy you own, if you ever change platforms.
Test data
Test environments need data. Use made-up records wherever possible. If you must use copies of real data, treat the test environment with the same care as production, and remove the copies when you're done. A test database full of real residents is still full of real residents.
A simple release routine
- Make the change in development or test.
- Preview it on test records and run the flow's tests.
- Run it once for real against test systems.
- Promote it, review the differences and the connection mapping.
- Turn it on at a quiet time and watch the first run.
- Note what changed and why in the version history.
When environments are overkill
Not every flow needs this. A weekly summary email that only reads data can reasonably be changed in place, with preview and tests. Save the full routine for flows that write to systems of record, move money, or publish to the public.
In SentraBridge
SentraBridge links Development, Test and Production workspaces. "Promote to Production" shows the differences, maps each connection to its production twin, never copies secrets, and delivers the flow turned off. Promotion can require passing flow tests, with any admin override logged, and flows can be saved to GitHub or GitLab as YAML. See hosting and environments.