Hi All. I'm new to Flyte and do apologize if my question is out of context for this particular channel.... I have three domains in my Flyte cluster (dev/stage/prod). For the release management, I've been registering workflows in Dev, and once smoke tests are complete, was registering same workflow in Stage and, then, once regression is complete, registering it third time in Prod. That seemed odd.... as the workflow is just a code, and all the environment-specific configs are within env vars on each of my domains. Today, I did a little experiment. Instead of registering the same workflow on Staging, i created a launch plan, which points to the workflow version I registered on dev. I then created new execution off the launch plan and it seemed to work. So my questions is: "What are the best practices for workflow release management? And is using launch plans across the domains - a bad practice?"

I like full Copies to each domain, that way it’s easy to not break prod from dev

copies to each domain add too much overhead when you need to execute a roll back.

Rollback is just a deactivate on the launchplan right?

yes, sort of point the launchplan I have in staging to previous "good" version of the workflow i have registered and tested in staging

@freezing-airport-6809 @loud-dentist-4938 I am working on something similar for our workflows. Is there a set of best practices to follow especially when it comes to testing, version management and promotions with Flyte workflow. 1. Do you have automation testing other than smoketest? 2. How do yo do promotion, is it someone manually doing registrations/launch plan updates or do you use some type of Devops piepline e.g. ADO pipeline, AWS Pipeline etc 3. How do you do version management? Do you use semantic versioning, github hash etc. How does your CI/CD process use the versions for rollback? Sorry if the questions are all over the place. I am simply trying to figure out best practices. Thanks!

1. For us Flyte acts as middle-tier layer between a suite of our applications (primary web apps) and our data. The apps trigger workflows and setup certain UX on the data the workflows produce. 2. Data science and ML teams use the Flyte to setup workflows which run various ML pipelines 3. Our workflows are Python based 4. Our tasks are parametrized through env vars and Flyte Secrets 5. Once we push to staging successfully we add tag to our repo 6. Smoke/Integration tests run on Staging 7. Applications launch the workflows through Launch Plans which always points to a workflow version 8. Once the tests are complete, we register Launch Plan on prod but it points to a workflow version we have in Staging (this is where we are debating if we should just re-register workflows on Prod too instead of just having Launch Plans) 9. We use github self-hosted agents and gitbub actions to run the CI jobs which register workflows via pyflyte register and create launchplans via SynchronousFlyteClient I hope this gives you a high level view on the concepts we have cc: @brief-family-9488