Version Control for WebMaps in ArcGIS Online

[Fabiode_Carvalho_Paiano]

Some enterprise customers of ArcGIS Online would like to have the possibility of rolling back to a previous version of a webmap.
In large organizations the permissions to create and edit webmaps are delegated by IT to end users, who are the domain specialists. However, some of these webmaps are part of mission critical apps and should be possible to restore them quickly in case a user mistakenly deletes or changes the map in a way that renders the app unusable.
Hence the request for a simple version control to webmap documents on ArcGIS Online, in a similar way that Content Management Systems and Wikis have version control to pages and/or attached documents.

[JohnBrockwell]

You could always make a copy

[RonnieRichards]

This would be a great addition. Currently we use GIT for our ArcMap / Server geoservices and exploring how to modify this process to support web maps. If ArcGIS Pro 2.3 supported overwrites this would be much easier as it would preserve the WebMap id and all dependencies.

[EmlynJones]

Hey Ronnie - mind if I ask how you guys managed to do that? Does this mean that your ArcGIS Server site is version controlled using Git so that you can revert back any changes to configuration/services?

Thanks!

Emlyn

[RonnieRichards]

Yes we have repositories of Map Documents managed by Git in BitBucket. It is not ideal since it is a binary format but does work well since the file does show up in the change detection. Various GIS staff have access to pull from the repositories in BitBucket. When a staff member checks in a branch, they merge with a build plan branch for one of our environments (DEV, QA, PROD). When merged the repository triggers Bamboo which uses python scripts which obtains the MXD's that changed from the commit and deploy those MXD's to the appropriate environment. Environments are controlled by a python configuration file. 

In the event of a rollback, this is a function of bamboo and it simply re-deploys the previous build artifact in a matter of minutes.

We plan to start working on moving ArcGIS Pro projects into a new Git repository so we can version web maps and feature layers but have been focusing automating our locator updates first.

Hope this is enough info! 

[JohnWilliams4]

"Making a copy" is an untenable overhead for many organizations, and always rife with mistakes to be made.  Avoiding manual file manipulation is critical as an organization grows and builds out ever more complex features for users and internal customers.  

[Anonymous User]

I completely agree with you, making a copy is great if you only have one project you are working on... but when you have a lot of content ( and you can't even organize/archive items into sub-folders) then it quickly becomes untenable.

[Anonymous User]

Something like this would be priceless when dealing with indecisive managers who flip flop on how they want the map configured, for a higher profile product where items are heavily configured with Arcade expressions/HTML and such configuration seems so painful that when you have to delete your work only to redo it again... ughh.

This would also be useful if it allowed for modifications to a map/app to be made but not published so I can do my work on a live map before my deadline and instead of having to leave the browser window open while I wait for my manager to get out of a meeting, I can save without publishing the changes ( "save a draft") then when everyone who needs to sign off on the changes has done so I just click a button and its published.  No more leaving my borwser window open all weekend so my manager can approve it on Monday... or worse accidentally closing the browser window while waiting for approval...  

[TimDuhamel_AT]

Workaround I am using for version control of Web Maps (and other Portal Items): Use AGO-Assistant to retrieve the item's JSON, copying this JSON into a git repository, overwriting the file with each new version.

It is a manual process, and by no means a comprehensive or integrated approach, but it is similar to creating 'tags' in a version control framework, allowing me to diff between versions.