Expand my Community achievements bar.

rapid rollback

Avatar

Level 5

6/1/18

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.

19 Comments

Avatar

Employee

8/27/19

This is nearing completion.  As usual, we'll do an API release which introduces the functionality and a subsequent UI release to make it easier to use.

This will work only for libraries published to environments which use the Managed by Adobe host.  If you're doing SFTP delivery, you're on your own for a backup strategy.

If you are using Managed by Adobe, we'll allow you to retrieve any of the 5 most recently published libraries.  If the build was an Archive build, then your retrieval is a download.  If the build was not an Archive, then your retrieval is a Republish. The embed code that Launch gives you is really a shortcut that points to your actual library file (symlink for the technical folks).  Republishing a library will rewrite that shortcut to point to the older file.  Pushing a new library through the publishing process to Production will write a new file, write the shortcut to point to that latest file, and push the oldest build off the stack.

Republishing does not have any affect on any of Data Elements, Rules, or Extension configuration that you have.  It will not change any of your upstream resources.  It is simpy a change of the shortcut the embed code is pointing to.

We will always tell you which library is currently live, and if you are in a republished state, we'll let you know with a banner on the publishing page and a toast message when you enter the property.

Avatar

Employee

8/29/19

I read the other thread, and I think they are different things.  I've responded on the other thread to get some clarifying details, but I think that Launch may already provide a way for you to do that.

Avatar

Employee

11/6/19

We released this capability in the API on 10/15 (see API release notes​​ and API docs​).  UI work is in the final stages now.  We have limited release windows during the holiday season, but we hope to release it next week.  If we miss that window, the next release window is in early December.

Avatar

Level 4

12/8/19

Just wondering, the implemented republish process looks cumbersome. ("Self-hosted? Good luck." "Republished or Archived? Pick one.")

Here's how the "other guys" do it:

  1. Pick a previously published version.
  2. Publish it.
  3. There is no step 3.

In my mind, that process is essentially this:

download.jpeg

Which is basically just the "Republish" option.

Avatar

Employee

12/9/19

If you have specific enhancements you'd like to see to the feature, suggestions are always welcome.  You can to submit them in the ideas exchange and lobby your fellow users to vote for them or hit us up in one of many Slack channels.

Launch enables publish libraries in a bunch of different ways. This feature allows you to retrieve old libraries in the best way depending on what you're doing with yours.

  1. For those who are using the Managed by Adobe Host to publish Javascript files, we republish the old ones to your embed code
  2. For those who are using the Managed by Adobe Host to publish Archived files, we let you download them again
  3. Self-hosting is typically done if you have more sophisticated security requirements and in these scenarios, we assume you have your own backup options in place

Launch prevents you from mixing and matching these to avoid undesirable consequences.  For example, if you had published a an archived library to your Managed by Adobe Host, then subsequently switched to a regular JS library and published to that host, clicking "Republish" on the archived library would republish the old archived file, but would not change anything that was being referenced by your embed code, which is probably not what you wanted when you hit Republish.  So we make it clear that you're not "Republishing", you are "Downloading".

So again, if you want to describe what about the process you find cumbersome or would like to offer suggestions for improvement, we're listening.