Version control for custom flows¶
Openflow supports Registry Clients, including the GitHub Registry Client, which allows you to use a Git repository to store and version your custom flow definitions. This enables standard software development lifecycle (SDLC) practices, such as branching, pull requests, code review, and environment promotion.
A common workflow is:
Maintain a
mainbranch representing your production flow definitions.Create feature branches for new development.
Develop and commit changes on the Openflow canvas.
Open pull requests, review with Flow Diff, and merge.
Prerequisites¶
A GitHub repository for storing flow definitions.
A GitHub Personal Access Token with
repositoryaccess.An Openflow Runtime with access to the Openflow canvas.
Appropriate Snowflake role privileges on the Runtime Integration object.
Step 1: Create a GitHub Registry Client¶
Create a repository in GitHub to store your flow definitions.
Generate a Personal Access Token (PAT) in GitHub with repository access permissions.
On the Openflow canvas, navigate to Controller Settings and create a new Registry Client.
Select GitHub Registry Client as the type.
Configure the Registry Client with:
Your GitHub repository URL.
The GitHub repository owner.
Your Personal Access Token for authentication.
Step 2: Create and version a new flow¶
On the Openflow canvas, create a new Process Group for your flow.
Build your flow: add processors, configure connections, and set up your data pipeline.
Right-click the Process Group and select Start Version Control.
Choose the GitHub Registry Client you configured in Step 1.
Provide a flow name and an initial commit message.
After you save, the flow definition is committed to your GitHub repository. You can verify by checking the repository in GitHub.
Step 3: Use branches to manage changes¶
Create a development branch¶
In your GitHub repository, create a new branch (for example, dev or a feature branch
like feature/add-new-table).
Import and develop on the branch¶
On the Openflow canvas, import the flow from the GitHub Registry into a new Process Group by dragging the Import from Registry icon from the toolbar to the canvas.
When importing, select the target branch (for example,
dev) to work against.Make your changes to the flow inside the Process Group.
Commit your changes in Openflow. This pushes the updated flow definition to the selected branch in GitHub.
Review and merge via pull request¶
In GitHub, open a pull request from your development branch to
main.Review the changes. Use the Snowflake Flow Diff GitHub Action (see Step 4) for human-readable diffs.
Merge the pull request after it’s approved.
Back on the Openflow canvas, update the
mainProcess Group to pull the latest version from themainbranch.
Step 4: Set up Snowflake Flow Diff (GitHub Action)¶
Snowflake Flow Diff is a GitHub Action that makes flow changes human-readable by rendering a visual diff of your pipeline changes directly in pull request conversations.
Set up the workflow file¶
In your GitHub repository, create the file
.github/workflows/flowdiff.yml.Copy the workflow configuration from the Snowflake Flow Diff repository (https://github.com/Snowflake-Labs/snowflake-flow-diff) (see the Usage section in the README).
Commit and push the workflow file.
Review flow changes¶
When a pull request is opened, the Flow Diff action runs automatically.
Navigate to the Conversations tab on the pull request and wait for the Flow Diff analysis to appear.
The analysis shows a visual, human-readable comparison of flow changes instead of raw JSON diffs.
Manage parameters across environments¶
Openflow uses Parameters to manage environment-specific values (for example, connection strings, credentials, table names) across different Runtimes.
Keep the following concepts in mind:
Parameters are grouped into a Parameter Context, which has a one-to-one mapping with a Process Group.
Parameter Context inheritance allows you to define shared parameters in a parent context and override specific values in child contexts. This is useful for promoting flows across dev, staging, and production environments.
Parameter Contexts can integrate with Secrets Managers to securely handle sensitive credentials without storing them in the flow definition.
Recommended SDLC workflow¶
Development environment: Developers create feature branches, build or modify flows, and commit changes on the Openflow canvas against their feature branch.
Code review: Open a pull request in GitHub. Use Snowflake Flow Diff for readable reviews.
Merge to main: After approval, merge the pull request into the
mainbranch.Promote to production: In your production Runtime, update the Process Group to pull the latest version from
main.Parameterize: Use Parameter Contexts to handle environment-specific configuration without modifying the flow definition itself.