Bulk Conversion Outline OLD

← back to Arches Conversion

Bulk Conversion

Bulk Conversion Planning 

Sprint A (Define the Bulk Scope)

  1. Identify a batch of pages as the upcoming candidate batch for conversion. Considerations: 

    1. Can we target a good number of pages with the same component composition (they use the same components exclusively)? This lets us control variables. 
    2. Provide a list of the components to UI for conversion. 
    3. Confirm the batch with any interested parties if relevant (editorial, BL, users, etc etc) 

  2. UI analyzes component list conversion and provides LOE. 

    1. How complex will the conversions be/How long will it take? Generally, this will hopefully be doable in one sprint assuming there is not any major rebuilding needed. Most importantly we need to determine how many will need to be rebuilt completely. 
    2. Creating A New ACC.org Component
    3. Create tickets for each component up for conversion (we may be able to lump some lighter ones together, we can decide that after analysis). 

  3. Groom, add to schedule, etc. 

Sprint B (Mostly UI, the length of this stage will depend on what components we need to convert) 

  1. UI team completes component conversion tickets. 

  2. QA tests converted components on sample pages in test environments. 

  3. Push conversions to production, including deployments steps to make sure the components are available for use on all environments. 

  4. UI provides list of bulk changes, including 

    1. Components that need to be switched to an Arches version in presentation layout. 
    2. If applicable, a list of changes to rich text content where the change can realistically be done with a bulk script (i.e., search and replace) 
    3. A list of issues from conversion that will need manual intervention. 
    4. New Component

Sprint C (Remediation Steps for Editor Created UI)

  1. Audit All Content Areas, and Custom Scripts for uses of In Page and Inline Script and Style Tags
    1. Output to and excel. Audit of Editorial UI
    2. Internal Review of Audit
    1. List All Inbound Links and Evaluate Remediation of Links:
    1. Font Awesome 4.x - Delete, find all class names that start with fa- and end in -o and remove -o
    2. Font Awesome 5 or 6 - Delete
    3. Bootstrap JS & CSS - Delete
    4. Remediation | Remediation Document of all editorially created UI and Inclusions
    ]]
    2. Review and In Page Script and Styles
    1. Dedupe and Style and Script Tag Blocks and save them outside of Sitecore
    1. Add Items to the Editorial Bulk Change Notice Excel
    3. Run Clean Up scripts across Richtext and CustomScript Sitecore components

Sprint D (applies to Batch #1 ONLY, revisit for subsequent batches) 

  1. Development creates scripts to process changes provided by UI in Sprint B. 

    1. Precondition: Components that need to be switched to Arches has already been developed, tested,  and pushed to ALL environments (DEV, SPR, STG, RLS, PRD) 

  2. Run script in development environment for specific pages that apply to this batch (i.e., #1) and verify. 

    1. Review affected pages for discrepancies/bugs for resolution (e.g., code, components, etc.) 

      1. If code changes are required, create JIRA tickets for upcoming sprint.  Sprint C will be paused until these code changes are made in ALL environment 

    2. Review and identify any content issues (rich text, custom scripts) and work w/ BL on resolution 

  3. Run clean up script to identify problematic scripts that need to be remediated (https://support.acc.org/browse/AWC-3942) and push to environments accordingly. 

  4. Promote to other lower environments (SPR, STG, RLS) and validate in each environment accordingly. 

    1. Perform demo for BL to review results of bulk conversion for batch in scope (STG or RLS) and obtain sign-off 

  5. Create a PRD back-up to support a rollback, if needed (requires further discussion around specific rollback tasks/steps) 

    1. Take back-ups of both Author and Web DBs 
    2. Need to enforce a content freeze (BL), specifically for a subset of pages/content 

  6. Promote to PRD and run bulk conversion script in Author ONLY, do NOT publish to Delivery. 

    1. IMPORTANT NOTE: To ensure content is NOT auto-published, there is a need to explore options. 

      1. Option 1: Set content items to a DRAFT status when converting content in Author.  See Sitecore DRAFT workflow doc here.  Possible risk is the Original Posted Date may be updated as a result (need confirmation) 
      2. Option 2: -- TBD 

    2. IT to perform spot checks in Author to ensure the conversion script was completed successfully. 

    3. BL reviews converted pages in Author and as pages are validated, publish in increments (as appropriate) 

      1. UI, DEV, & QA teams on standby to field any questions or address any concerns 

  7. Post Conversion/Clean Up Tasks (once all batches are complete, one-time task) 

    1. Once conversion is complete, we will take the Arches presentations and merge them into the current legacy template presentation configurations, and delete the Arches versions, as clean up. 

QA Approach (DRAFT) 

NOTE: This approach should be visited as we progress w/ the batches.  Also, scheduled sprint content syncs should not adversely affect the Arches QA pages since they will already exist prior to the content sync. 

  1. UI/UX team will create an Arches QA dedicated page (e.g., page name to include '_ArchesQA' suffix  in the DEV environment in support of their development & verification process. 
  2. Once the component updates have been verified in the DEV environment, UI/UX to request a Razl content sync to SPR in coordination w/ their updates getting built and deployed to SPR. (Ricky can assist w/ Razl syncs) 
  3. QA will then use the Arches QA dedicated page in SPR to test the target components.  Once validated in SPR, QA will work with DEV (Ricky) to sync content to upper environments (STG/RLS) as the changes are promoted. 
  4. PRD deployment (e.g., pre-task) should include a step to sync the Arches QA dedicated page to PRD (Author ONLY, do not publish to Delivery) in order for QA validate in PRD. 
  5. Once validated, need to ensure there is a clean-up process to remove/delete QA dedicated pages, once ready (in ALL environments) 

Notes:  

It is important that we have a way to roll back our work at any point throughout these cycles and we need to be able to do this in a way that BL can be comfortable with. This plan doesn’t really account for if something goes pear shaped in Sprint C but we should probably iron that out as well, especially if something goes wrong during the push to production. 

This looks like a three-sprint process, but we may be able to consider identifying the next batch during sprint C to speed up conversion if necessary.

#acc/arches #acc/arches/conversion #acc/guidance