rapid rollback

[#1]

I would like functionality that would facilitate rapid rollback of a published library. Such a feature would facilitate returning the previously published library to being in use in the case that a severe issue cropped up with the most recently published library. This could take the form of rebuilding a library in the publish history / column, and should probably cause the rolled back library to return to development status, or possibly adding the option to rollback the currently published library sending it back to development and allowing the previous library build to resume its place in production.

Currently performing a rollback requires determining all of the changes between what was most recently released and the previously released library, and then creating new revisions of all the changes that remove the previous change (note that this is made more difficult without the apparent ability to select an earlier revision).

Ultimately what I'd like to see is the ability to return the current library in production to development status and allow the previous library to resume its role in production with a minimal number of actions required; i.e. open a menu and select rollback.

[#2]

I voted for this idea.  Currently it's a painful process. Is there no other way to do this today?

[#3]

Hi Ellen,

I don't know of a good way to do this currently. What I've done to reduce my likelihood of needing to do a rollback is to put any scripting in external files named with a hash value that I load with custom html. That way if a script has negative, unanticipated consequences I can update the custom html to point to the previous script. That keeps my coding out of Launch and in a repository where I can handle change management better. This obviously doesn't take care of everything, but it helps since most of what I'm working on is scripting. From what I've seen trying to rebuild a previous library would be very difficult, especially if there were very many changes. Each Launch library is released with a minimum number of changes, so that should help reduce the pain.

[#4]

Great idea! This is definitely something we would like to do at some point. Unfortunately, we don't have any timeline to share about when this might be implemented.

[#5]

Thank you.  What about using something like Github?  How are other customers solving for this?

[#6]

In the original post, it was suggested to push the current Prod Library back to dev and have the previously published library take it's place as the current Prod library.  This makes a lot of sense to me.  I have a couple follow-up questions:

1. As an MVP, it seems like the most recent library would be great.  Longer-term is that enough, or do you commonly have use cases where you'd need to rollback a couple versions to one that was published 3 publishes ago (as an example)?
2. This would not modify the rules that would show in any of your list views, just rebuild libraries based on whatever revisions were in them at the time.  Even the Prod library you pushed back to dev.  Does that seem reasonable or would you expect something different?

[#7]

The impetus behind the original idea was simply to be able to return to a known good state. That said, if the solution were to rebuild the "recipe" of the past library, that solution could potentially be applied to any library where the recipe is still known.

Hopefully I'm not publishing test libraries to production, limiting my use case to the previous library, but rebuilding any past library might be useful, and conceivably wouldn't be more difficult to architect. However, if the ability to rebuild more than the previously published library were introduce that would increase the need to easily compare the differences in detail between libraries since it would open the potential to rebuild a library that the user is no longer familiar with.

[#8]

We have a pretty good idea of how this would work and expect to begin work on it within the next few weeks.

[#9]

thebenrobb​ Great, will watch for future updates - this is a crucial, pain-reducing feature. Not having it tends to make one reluctant to use Launch until rollback is available. Do you think it would be available before the July DTM sunset on new property add capability?

[#10]

DTM is not sunsetting in July, the only thing happening in DTM in July is that the Add Property button will be removed.  That said, July currently seems like an achievable time frame.

[#11]

puh. now I am really irritated. this would really be a MUST-Function....

Exactly as described above....

so now quick rollback????

well then. Let me get back to work.