Change request: Configuration Sync / Deployment Pipeline for Multiple VertiGIS Studio Web Apps
Based on practical experience with the Web Designer (particularly regarding rendering performance and memory/cache behavior) it has proven beneficial to build multiple smaller, focused WebGIS applications rather than one large monolithic app.
Our deployment strategy therefore looks like this:
- 4–5 separate VertiGIS Studio Web Apps, each scoped to a specific department
- Each app has a pre-production and a production environment
- This results in a total of up to 10 app configurations to maintain in parallel
Any change that needs to be applied across all apps, even a small one, must currently be replicated manually up to 10 times. This is:
- Extremely time-consuming
- Error-prone (inconsistencies between environments)
- Not scalable as the number of apps grows
- A serious bottleneck for any CI/CD or deployment workflow
This is not a niche use case. Any organization running multiple apps with staging environments will face this exact problem.
Questions to the Community & VertiGIS Team
1. Is there already a solution for this?
Does a synchronizer, or scripting approach already exist. Either officially from VertiGIS or from the community?
2. Programmatic access to app configurations via Portal REST API
VertiGIS Studio Web Apps are stored as ArcGIS Portal items. The official ArcGIS Portal REST API (/sharing/rest/content/items/<itemId>/data) can be used to read and update app.json programmatically. This is a documented and stable Esri API. What remains unclear: Does VertiGIS officially support and document the app.json schema in a way that makes it safe to manipulate programmatically? Is the config format versioned or subject to breaking changes?
-
- Do you use the built-in deployment mechanism?
https://docs.vertigisstudio.com/webviewer/latest/admin-help/deploy-an-app-across-a-single-.html or
https://docs.vertigisstudio.com/webviewer/latest/admin-help/deploy-an-app-across-multiple-.html (you can set Environment Values https://docs.vertigisstudio.com/webviewer/latest/admin-help/environment-values.html and exclude items from deployment https://docs.vertigisstudio.com/webviewer/latest/admin-help/exclude-items-from-deployment.html) - Yes I know there are organisations which developed deployment scripts.
- Can you give examples of changes?
- I'm not aware of documentation of the app.json schema.
1 - Do you use the built-in deployment mechanism?
-
We went the route of building our own using python scripts and arcpy. We use a similar concept to ESRI's migration using groups. We use a Content group that contains only what needs to be migrated. This allows us to divide up migrations for stuff that is shared across all apps so we have content groups for Shared Workflows, Basemaps, Imagery services and then a content group for each application. The migration will create the exact same IDs across our Dev/Stg/Prd portal environments (with the exception of a few items like Map Layer/Feature Layers). Combined with the content group is a configuration file we maintain for each application that indicates what “Replacements” need to be made in the content as it is migrated. We chose this route due to limitations in how the VertiGIS studio deployments worked (of course I can't remember exactly what those were)
NOTE: While this is working extremely well, it is a bit complicated to maintain and isn't 100% effective - things like content thumbnails we have not implemented yet and you have to ensure it works with each version of Portal. You have to spend a lot of time interrogating the portal content to fully understand the implementations to maintain the script. So far the only thing we haven't migrated yet from VertiGIS is the Reports as they have a really strange server implementation. Even server workflows had logic to how they were implemented. Reports is really strange though.
0
Please sign in to leave a comment.
Comments
3 comments