Launch Publishing Workflow: Developing within a release cycle ? | Community
Skip to main content
Level 3
October 17, 2019
Solved

Launch Publishing Workflow: Developing within a release cycle ?

  • October 17, 2019
  • 1 reply
  • 2768 views

While Launch allows for the publication of libraries continuously, some of us must adhere to strict release windows

In our scheme, only one person has the ability to publish to production and that can only be done during particular hours on a particular day (every two weeks)

My question is, how can I not be blocked from development while QA and UAT are in progress?

For example. When I complete my dev work within the sprint and submit to Staging (where QA/UAT happens), I want to create a new library in Development to start on my next round of work

However, if the library is rejected and sent back to Development, only ONE library can exist within that environment

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by AnalyticsAlice

Alandy_Iceboats​  Multiple libraries can exist in Dev status but they cannot share the same embed codes, so in this case you'd need to create a new environment. You can do this by going to the Environments tab and selecting "Add Environment".The new environment will have its own unique embed code, allowing you to test only your newest changes and keep them separate from the rejected library.

It sounds like your team's workflow would not permit merging your newest changes into the rejected library, but technically speaking that would be one option as well.

1 reply

AnalyticsAlice
AnalyticsAliceAccepted solution
Level 2
October 25, 2019

Alandy_Iceboats​  Multiple libraries can exist in Dev status but they cannot share the same embed codes, so in this case you'd need to create a new environment. You can do this by going to the Environments tab and selecting "Add Environment".The new environment will have its own unique embed code, allowing you to test only your newest changes and keep them separate from the rejected library.

It sounds like your team's workflow would not permit merging your newest changes into the rejected library, but technically speaking that would be one option as well.