How to revert the published production library back to dev environment if the library de-active? | Community
Skip to main content
V
Vijayakumar_Raju_CBE
Level 2
May 6, 2022
Solved

How to revert the published production library back to dev environment if the library de-active?

  • May 6, 2022
  • 2 replies
  • 2761 views

Hi everyone,

From Adobe launch we have pushed library to production, due to some issue/reason we need to revert back by republish the previous library. Now we want to make some changes to the library which was de-active. Here, how come we can use the de-active library back to dev (or) stage position to make some changes with the existing items mapped on the de-active library.

Lets assume, I have created fresh/new 1 rule, mapped with 1 new data element and core extension (upgraded) added to a library called "Library A" build in dev, moved to stage and make it production publish.

Case A
How to revert/retain the published "Library A" library from production and de-active and then back to dev environment?

Case B

Please note since I revert and re-published the previous library. In that case from this "Library A" I have also added the upgrade "Core" extension will that be affect (or) interpret on the future rules (or) data elements while create with fresh library? OR do we need to add again the upgrade "Core" extension to along with the future rules?

Hope you understand my concern.

Thanks,
Vijay

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 Reyhan_Sadaka

Hi @vijayakumar_raju_cbe - I think I see the questions you're asking, but please correct me if there's anything I miss.

 

When a library is published to Production, that library and all of its revisions are - as far as I can tell - there forever. The best analogy I can think of is that "Republish" will tell Launch to build from a prior tag in your repo, but it won't actually change where the "Head" of your repo is.

 

So to address Case A: there's no way to bring "Library A" back down to the Dev environment. You're stuck with those commits - republishing the older library allows you to quickly revert changes, but to actually address the problem you need to create a new library.

 

To address Case B: No, you shouldn't need to redo the upgrade to the Core extension. Since your "repo head" is still in the same place with Library A, all of your Dev and your Staging environments should still be incorporating the new Core extension. I imagine Adobe does this on purpose to ensure you can't accidentally revert an extension upgrade and/or get yourself trapped in a weird or bad state with dependencies.

 

This also means that in order to address/fix any issues, you need to create new revisions of any rules that had issues and caused your reversion. I am often in a situation where I have multiple revisions of a rule in different lower environments - but once Library A is published with Revision 10 of a rule, Staging and any Dev environments will only allow you to incorporate Revision 11 or above into a library (because again: Library A is still technically "in Production" even if you've republished an older library).

 

Does that all make sense?

2 replies

Reyhan_Sadaka
Reyhan_SadakaAccepted solution
Level 2
May 6, 2022

Hi @vijayakumar_raju_cbe - I think I see the questions you're asking, but please correct me if there's anything I miss.

 

When a library is published to Production, that library and all of its revisions are - as far as I can tell - there forever. The best analogy I can think of is that "Republish" will tell Launch to build from a prior tag in your repo, but it won't actually change where the "Head" of your repo is.

 

So to address Case A: there's no way to bring "Library A" back down to the Dev environment. You're stuck with those commits - republishing the older library allows you to quickly revert changes, but to actually address the problem you need to create a new library.

 

To address Case B: No, you shouldn't need to redo the upgrade to the Core extension. Since your "repo head" is still in the same place with Library A, all of your Dev and your Staging environments should still be incorporating the new Core extension. I imagine Adobe does this on purpose to ensure you can't accidentally revert an extension upgrade and/or get yourself trapped in a weird or bad state with dependencies.

 

This also means that in order to address/fix any issues, you need to create new revisions of any rules that had issues and caused your reversion. I am often in a situation where I have multiple revisions of a rule in different lower environments - but once Library A is published with Revision 10 of a rule, Staging and any Dev environments will only allow you to incorporate Revision 11 or above into a library (because again: Library A is still technically "in Production" even if you've republished an older library).

 

Does that all make sense?

    Gokul_Agiwal
    Community Advisor
    Gokul_AgiwalCommunity Advisor
    Community Advisor
    May 6, 2022

    Hi @vijayakumar_raju_cbe 

    The five most recent libraries only allows by adobe launch that have been published to your production environment for later retrieval / re-publish. 

    So once the library published into production or republish any library (from recent most five), you can't get that library back to dev or staging environment. in your case Library A. 

     

    if you think the particular rule / data element has some issues with your de-active library then fix those issues and save into new dev library with latest revision test it and proceed further. 

     

    About extension upgrades - This upgrades are permanent.  

    Once you upgrade the extension it must be included in all libraries along with other items if any.

    Any library that does not include the upgraded extension will fail at build time. 

    There is currently no capability to downgrade your extension to a previous version. Once you’ve upgraded (whether you publish or not), the new extension version is on your property to stay. 

    So before upgrading the extension, you must test it thoroughly. 

     

    Hope this helps. 

     

     

     

     

      Terms & ConditionsAccessibility statement

      Loading footer...