Updating Gallery-Linked Data Connections from Dev to Prod Sources when Migrating Workflows

[Scott_Snowman]

I am looking into the feasibility of a CI/CD pipeline that includes Alteryx workflows in its scope. My organization has two Alteryx server environments (dev and prod) and I see that the Migratable endpoint page contains a process for identifying and publishing workflows marked as eligible for deployment to production. 

In our organization, the workflow functionality would be identically once in the production environment, but it should target production databases instead of development ones.

I imagine that when using the Server API, workflows are deployed to the target environment studios exactly as they are in the source environment, which means they're referencing connections to the dev databases provided by the dev Server environment. Is there any way to facilitate updating those connections to corresponding prod database connections, provided by the prod Server environment?

[fmvizcaino]

Hey @Scott_Snowman ,

Workflows are XML files, so we usually automate a process to change the XML accordingly before sending the workflow package to the new environment.

While there are limitations to migrating the data connections, there are 2 possible solutions that I`m talking about in this post. 

https://community.alteryx.com/t5/Alteryx-Server-Discussions/Migrating-Workflow-handling-Alias-Betwee...

Best regards,

Fernando Vizcaino

[Scott_Snowman]

Thanks @fmvizcaino - if I'm understanding correctly, then there's four steps (in general) to promoting a workflow previously published on server A to server B:

1. (Prerequisite) Build a mapping of Gallery connection alias on A to Gallery connection alias on B
2. Execute a process to adjust all instances in XML from alias A to alias B
3. Use API to publish to server B
4. Aliasing error: use Designer to open workflow from Server B, and resave back to Server B as version 2 to package the true aliases.

Looks like in the post you've linked, you've identified two alternative solutions to step 4 -- but one could simply execute the "version 2" process on each migration as well.

Is this summary correct?

[fmvizcaino · Accepted solution]

Hey @Scott_Snowman ,

All correct.

For step 4, you are adding a manual way of updating the data connections in each workflow, which is totally fine.

One option is to use the workaround here: https://community.alteryx.com/t5/Alteryx-Server-Knowledge-Base/quot-Unable-to-Translate-Alias-quot-W...

The idea is to have the user responsible for running all workflows with access to all data connections. You would need just to open this user`s designer on the server to update the data connections from time to time to generate the galleryalias.xml which is a replacement for the temporaryalias.xml file.

Best,

Fernando Vizcaino

[Scott_Snowman]

Thanks a ton @fmvizcaino ! The manual update is doable from the client side (if somewhat cumbersome) while the server-side solution looks like something we might recommend for a second phase solution.

Appreciate the confirmation on the process, and we'll keep an eye out for the aliasing errors as we start to test deployment out.