What is the best way to remove/add/modify node structure in a live production environment? | Community
Skip to main content
A
Anonymous
April 28, 2020
Solved

What is the best way to remove/add/modify node structure in a live production environment?

  • April 28, 2020
  • 4 replies
  • 12786 views

My AEM platform contains 3 websites of which contains lots of content. I need to remove/add/modify content nodes in production without affecting content authors and their daily tasks. What is the best practice and best way to remove/add/modify content nodes without affecting production content authors? How should I test this and go live?

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 Theo_Pendle

Hi @17378453 ,

I am going through this right now actually as we are doing an upgrade from 6.3 -> 6.5 and EVERYTHING is changing (using Core Components, upgrading to Editable templates, changing all our front-en, etc). This means that almost every node under /content is going to be transformed one way or another.

We have several environments of which PROD and UAT (one below PROD, also known as "staging"). The way we are performing the modifications is that we've developed a separate project called JCR Patcher which (as the name suggests) will traverse the JCR and patch every node that needs it 🙂 At the moment it is triggered via servlet, but it could also be done via command-line.

The plan is this: 

  1. Copy all content from PROD to UAT
  2. Run JCR Patcher in UAT, test, get validation that all is okay.
  3. Content freeze (authors stop working)
  4. Copy all content from PROD to UAT (again, to get the delta, as step 2 will take weeks to validate)
  5. Patch PROD
  6. Validate
  7. Publish
  8. Un-freeze, authors can continue working on their new, patched content 🙂 

The idea it to do as much testing in UAT as possible so that we can patch in PROD with high confidence. This way, step 6 (validation in PROD) is really just a "sanity check" that can be done in one or two days.

 

In your case, if you're only patching 30 pages (which is a matter of seconds), you wouldn't need a content freeze. You could do all your tests in your UAT environment and the schedule the patching at night. 

4 replies

V
Adobe Employee
vish.dhaliwalAdobe Employee
Adobe Employee
April 28, 2020

I believe you can update the content on Stage/dev and then install the packages on production. That way, you can also test the pages before going live.

    A
    Anonymous
    April 29, 2020
    Say what happens if I only want to add a mixinType for 30 pages. How would we achieve this?
    VeenaVikraman
    Community Advisor
    VeenaVikramanCommunity Advisor
    Community Advisor
    April 29, 2020

    @17378453 I don't think and won't recommend content editing or any node manipulation directly in PROD. I don't think it is a best practice to start with. As @vish.dhaliwal mentioned , it would be better to do the same in lower region , test and install the package back to PROD. 

     

    From your question I am not clear how are you planning to remove/add/modify the content. Even if it is manually or programmatically, always do it in lower regions.

      A
      Anonymous
      April 29, 2020

      for example, a simple task to add the "mixinType" property for 30 pages for each live website (3 websites). The website cannot be idle for too long.

       

      What is the best way to achieve this?

      Is it best to stop content authoring, download content, make changes, install new content package?

      OR, should I run a servlet to add mixinType, then re-publish all the pages?

       

      Please advise. By the time we download 30 pages (from each site, so 90 pages), moments later during development, some pages may be updated. Re-uploading a content package into AEM will show old content.

      VeenaVikraman
      Community Advisor
      VeenaVikramanCommunity Advisor
      Community Advisor
      April 29, 2020

      Okay. Got your point. Like you want to add a particular property to say 100 pages. Something we used to do in one of our project is to write a script using Fiddle ( btw it is a utility provided by ACS Commons check here) and run it in the author directly. We never used to do this directly in PROD for sure. As usual local-> DEV->QA-> STAGE (mostly stage is our pre prod content). And content used to be backed up from STAGE to PROD for scenarios like this. But if you want to run it in PROD , make sure the script is 100% error free and won't crash anything with proper testing in lower regions. ⚠️ Do keep a copy of your content before doing any change directly in PROD. 

        A
        Anonymous
        April 29, 2020

        Thank you for replying. Is there another way for me to do this that is not that risky? Is this the best less risky to add mixinType to nodes?

        1. 1. Alert content authors to stop authoring.
        2. 2. Create new content package in production-live, as mixinType-to-add.1.0.0.zip
        3. 3. Download mixinType-to-add.1.0.0.zip.
        4. 4. on desktop, mixinType-to-add.1.0.0.zip to unzip.
        5. 5. add all changes to node in Local AEM using ACS Commons Tool.
        6. 6. Export ZIP with version mixinType-to-add.1.0.1.zip ffrom Local AEM.
        7. 7. ZIP the package.
        8. 8. upload &install mixinType-to-add.1.0.1.zip to QA for testing.
        9. 9. upload &install mixinType-to-add.1.0.1.zip to Stage for testing.
        10. 10. upload & install mixinType-to-add.1.0.1.zip to Production & Replicate.
        11. 11. Total 2 hours.
        Theo_Pendle
        Theo_PendleAccepted solution
        Level 8
        April 30, 2020

        Hi @17378453 ,

        I am going through this right now actually as we are doing an upgrade from 6.3 -> 6.5 and EVERYTHING is changing (using Core Components, upgrading to Editable templates, changing all our front-en, etc). This means that almost every node under /content is going to be transformed one way or another.

        We have several environments of which PROD and UAT (one below PROD, also known as "staging"). The way we are performing the modifications is that we've developed a separate project called JCR Patcher which (as the name suggests) will traverse the JCR and patch every node that needs it 🙂 At the moment it is triggered via servlet, but it could also be done via command-line.

        The plan is this: 

        1. Copy all content from PROD to UAT
        2. Run JCR Patcher in UAT, test, get validation that all is okay.
        3. Content freeze (authors stop working)
        4. Copy all content from PROD to UAT (again, to get the delta, as step 2 will take weeks to validate)
        5. Patch PROD
        6. Validate
        7. Publish
        8. Un-freeze, authors can continue working on their new, patched content 🙂 

        The idea it to do as much testing in UAT as possible so that we can patch in PROD with high confidence. This way, step 6 (validation in PROD) is really just a "sanity check" that can be done in one or two days.

         

        In your case, if you're only patching 30 pages (which is a matter of seconds), you wouldn't need a content freeze. You could do all your tests in your UAT environment and the schedule the patching at night. 

          A
          Anonymous
          May 5, 2020
          Patch PROD, are you calling the patch servlet from PROD?
          Terms & ConditionsAccessibility statement

          Loading footer...