Deployment of Content and Data/Settings

[nunoaguiar]

Is your feature request related to a problem? Please describe.
The Deployment Tool (as seen on DW9) has some limitations that prevent it from being used more. As it is considered for DW10, we'd like to see if it can be improved so it's used more widely

Describe the solution you'd like
This is from the perspective of a Technical user (not a customer), where we need to commit changes to Version control.
The improvements we'd like to see are:

UX/UI

• We found the tool most useful when configured to mimic the backend. People that use the Deployment Tool, know to have to go to different places in the UI to create custom fields, change ecommerce settings or website setting. So it's easier for them to relate to the UI when wanting to deploy
  • And assuming this argument is valid, then there's a something to say about having a "Deploy" action across the UI screens, instead of a dedicated place where the UI structure is "replicated"
  • The screenshot is from DW9, but this entire thread is for DW10 only https://www.screencast.com/t/8sY8kjX5

Permissions Data Item Provider

• Deploying permissions is not doable currently
• Usually based on Project Requirements, a developer would configure Segments that populate User Groups, to then assign permissions to
• Because User Groups don't have GUIDs, they cannot be deployed and have to be manually recreated (hence new IDs in the destination)
• Because IDs won't match, we cannot deploy permissions
• Because there's no "Permissions Data Provider", we would need to use the "SQL Data Item Provider", but this provider is not capable of handling page GUIDs (so it would copy the Page ID, rendering it useless)

Area Data Item Provider

• In Areas we have values that may be different per environment vs solution
  • i.e. Domains, NoIndex NoFollow, GTM credentials - these are different per environment
  • i.e. Ecommerce settings, Name, (some) item type settings - these should be the same for all environments
• Currently by not having the ability to granularly determine what properties to exclude (blacklist or whitelist) it compares everything
  • This will always be flagged as different (because in Staging or any other environment, some values need to be changed)
  • It's comparing a blob, so it becomes useless https://www.screencast.com/t/3Cc5ZuFC

Content, Page, Row and Paragraph Providers

• Currently it does not represent pages in a tree view - this makes it difficult to manage the list of results https://www.screencast.com/t/ht5vc4j4YpJ
• Represent the Item values as individual properties, rather than a blob
  • We can't really tell what's different, which could be a typo, an environment changes (i.e. Title was changed in the Destination) or a valid change to be deployed (checkbox updated)
  • https://www.screencast.com/t/MIgd3BTbfNyz

Page Data Item Provider

• If we could have an optional field to pick the "Parent/Root" page, that would make the Data Item Provider more usable to be applied directly on a Page (under Actions) for something like "Deploy this page"
  • Another optional field to "Include subpages" would be useful if we were to use it under "Actions" - sometimes we just want that particular page; sometimes a whole tree of pages

Row and Paragraph Data Item Provider

• If we could have an optional field to pick the "Parent" page, that would make the Data Item Provider more usable to be applied directly on a Page (under Actions) for something like "Deploy this row/paragraph"

Item Data Item Provider

• Whenever we send pages and paragraphs, the Data Providers are capable of sending the GUIDs, so that the IDs in the source and destination can be different
• It is common on Item Types to have fields (i.e. radio buttons) that have an Item Type as the source
  • i.e. Component Selector
• Currently if the source points to (Item ID) 1234, in the destination the Item ID might be 2000. This results in the Item (i.e. Product list paragraph) still pointing to 1234 in the destination, so a user has to manually go in and select the same Component (which is now ID 2000)
  • https://www.screencast.com/t/E7BcBngPZ6

Module/App/XML Data Item Provider

• Either as a new Provider, or extend the Content and Paragraph Providers, a more granular list of the settings is important
  • i.e. The Shopping Cart app may have settings that are environment specific (i.e. Email notifications) which we want to be different across environments
  • i.e. At the same time there will be settings that are different, as a result of the Task being developed (enable/disable checkboxes)
• The same can be said for Checkout Handlers, Shipping Providers and other provider based features. By having them compared as text (xml), we get a blob which becomes hard to use
  • https://www.screencast.com/t/9iHVadA2Y9D9

Packages optimizations

• Currently all Data Groups are within the zip file, when in fact all that should be needed is/are the data groups that triggered the package
  • https://www.screencast.com/t/KAtHtKdwIj
• If we got the contents unzipped (on a folder named as the zip would), we could commit to git as text files rather than a binary file
  • that would help with Pull Requests and general auditing
• The JSON file that's created always contains ALL of the data from the source
  • Since we'd like to have more granular control of the differences, we should be able to only send the properties that are different (instead of all)
  • This is a page update (not a brand new page) https://www.screencast.com/t/u6rKUWnzd
  • Reducing this to just the selected changes, would also allow for better "code review"/PRs and auditing (when we have issues and need to track things down to justify to the customer - currently it's always a "I don't know")

Describe alternatives you've considered
Creating SQL scripts for the changes, so we can commit them to Git. But this is very time consuming and would require even more skilled developers.

Additional context

• This is from the context of an developer/implementation team following project requirements.
• We've tried to have technical customers to use the Deployment tool (for both content and development) but they run into the challenges mentioned above. And the less tech-savvy the customer the harder it is for them to use the tool.
• We (developers) find a lot of value in it, and use it within it's limitations, while having to document (and redo) the manual steps. We're looking to improve the tool, so we reduce the forced manual (ideally completely).
• Having everything in Git will also help work with Customers that are accusatory, because it's easier to compare/revert to what's in Git. Also improving the UX will help onboard more Partners and Customers to using it.

Justin Sjuow @Justinvolved and I also met with Jeppe Agger dw-jea discuss the items mentioned above.