• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 19 replies
  • Answers 1 answer
  • Subscribers 19 subscribers
  • Views 3957 views
  • Users 0 members are here
Options
Related

Deployment automation of factory default themes that were created trough developer mode

Eugene Shulga (SE)

Hi, 

We trying to implement full CI/CD workflow for our current Verint 11.x development, that includes:

  • Storing factory default widgets code and factory default themes code in a git source controls
  • Automatically package and deploy widget and theme releases into a stage and prod environments

What we achieved for now:

  • White check mark Widgets source control is implemented through "Verint Development Mode" and "Factory Default Widget Provider", all widgets source control now could be stored in our git repository
  • White check mark Widget packaging from git and deployment is implemented through "FactoryDefaultWidgetFileManifestUpdater" example https://github.com/Telligent/Widget-Source-Management-Sample
  • White check mark Theme source control is implemented  through "Verint Development Mode" + creation of Social theme copy, all theme files now could be stored in our git repository
  • X Theme packaging from git and deployment is NOT implemented because
    • plan A: was to deploy factory default theme in same way as factory default widgets is deployed trough Widget-Source-Management-Sample, but we have no proper example of packaging factory default theme files into DLL and no proper example of manipulating theme files through in-process API
    • plan B: was to automate theme import/export UI through headless Chrome automation, but it seems too risky and unreliable for us 
    • plan C: was to copy-paste changes from themefiles/d and themefiles/fd directory from git repository directly into on-prem Verint instance filestorage, and this also seems risky for us because it was never officially approved to be safe way by Verint team, also there undocumented behavior when non-devmode Verint instance could store some of theme files in themefiles/f, and this /f directory is not properly documented, and just copying /fd and /d directories is not always working, so we currently dropped this plan Slight smile

The question:

While we were digging for a possible solution we discovered that theme, in same way as widgets, have it's own in-process API for manipulating theme files, e.g.:

We want to implement something similar to the Widget-Source-Management-Sample, to package factory default theme files into DLL embedded resource and then add them to Verint instance during plugin installation, but we didn't find any code examples for these APIs.

Question Do you have code examples for these API or maybe you have something similar to Widget-Source-Management-Sample that could be applied for themes?

Question Or if there more proper solution for this - could you tell us about it?



minor text fixes
[edited by: Eugene Shulga at 4:23 PM (GMT 0) on Wed, Mar 10 2021]
Parents
  • 0
    Eugene Shulga (SE) said:
    plan C: was to copy-paste changes from themefiles/d and themefiles/fd directory from git repository directly into on-prem Verint instance filestorage, and this also seems risky for us because it was never officially approved to be safe way by Verint team

    Currently, this is the approach I would recommend for continuous updating. The fd/ and d/ folders are documented ( https://community.telligent.com/community/11/w/developer-training/65591/editing-themes-in-developer-mode ) and supported, however, note that the file system is not monitored so updates will require manual UI Cache expiration (Adminitration > About > More > Expire UI Cache).

    Eugene Shulga (SE) said:
    there undocumented behavior when non-devmode Verint instance could store some of theme files in themefiles/f, and this /f directory is not properly documented, and just copying /fd and /d directories is not always working, so we currently dropped this plan

    Storage in the f/ folder occurs when a factory default theme is edited, which is a valid behavior on a non-developer-mode site (like production). There are two versions of a theme implementation: the factory default version (only editable in developer mode) and the current version (site-specific, in non-developer-mode sites, preventing editing to the factory default so it is always available as a reference).

    Eugene Shulga (SE) said:
    Do you have code examples for these API or maybe you have something similar to Widget-Source-Management-Sample that could be applied for themes?

    There is not currently a versioning API for themes as there is for widgets. The files can be written directly as mentioned above either via the file system or through the centralized file system API.

    An alternative is to export and publish the theme to the production environment when changes should be promoted. This is fully supported, automatically expires the cache, and would overwrite all customizations made to the theme on the production environment (so it'll match the development version completely).

  • 0 in reply to Ben Tiedt

    On other hand, if we'd tried to use import/export as preferred method, there also an issue:

    Export feature doesn't include factory default widgets in exported XML (those that are not binded to theme and marked as "Default for All Themes")

    Or we need to mix deployment methods (e.g. export theme XML + copy factory widget to filestorage), or we need to bind every factory default widget to our main theme, right?

Reply Children

About
Privacy Policy
Terms of use
Copyright 2024 Verint, Inc.
Powered by Verint Community