topic Shared ExperienceBuilder development in ArcGIS Experience Builder Questions

Shared ExperienceBuilder development

PaulCharsley — Fri, 09 Sep 2022 05:27:59 GMT

We have a team of developers using the ExperienceBuilder developer edition to create a web app. We are using ArcGIS Enterprise. Different developers may work creating widgets and a theme which they will want to share. What is best practice for doing this? We are planning to:

Download and commit the ExperienceBuilder development installation to our git repository
In this way all developers can share the same version of the development environment and more importantly, the "your-extensions" folder with widgets and themes

Is this a good approach?

I've also noticed that experiences can be created locally and there doesn't seem to be a way to push them to the portal. Where are these local experiences stored? Is there another folder separate from the "your-extensions" folder where locally created experiences are stored?

Re: Shared ExperienceBuilder development

Grant-S-Carroll — Fri, 09 Sep 2022 05:41:43 GMT

Hi Paul

I use Docker as a way of seperating my widget code from the Experience Builder framework, this means that I don't have to commit Experience Builder in to the repo, only my widget code. I mostly use Azure DevOps and build my widgets and apps using pipelines.

In order to share how to do that I've put together some blog posts on how to use docker with Experience Builder and also how to build your widgets and optionally also push them straight in to Portal as well. See below.

https://www.spatial-innovation.co.nz/post/using-docker-to-speed-experience-builder-development

https://www.spatial-innovation.co.nz/post/esri-custom-widgets-part2

https://www.spatial-innovation.co.nz/post/creating-and-distributing-esri-custom-widgets-part-3

Experiences are stored in the server\public\apps folder. Using docker you could also optionally store these in a single folder and map them in to docker. Likewise, you could also use the REST API and some python code in a pipeline to push these portal if you needed to as well. Note, you need Enterprise 11 to host custom widgets.

There is also an approach suggested under the FAQs here as well, if you scroll towards the bottom of the page.

Hope that helps.

Re: Shared ExperienceBuilder development

MarkJTurnbull — Fri, 09 Sep 2022 06:06:20 GMT

Hi Paul

I am currently going through the same process to include a team of developers to update app/experience configurations and custom widgets.

I have just setup a couple of BitBucket repos for app configs and custom widgets using information at this FAQ

We are going through and testing the process right now, learning as we go. I have found that even though we are logged into Portal as administrators we can't edit an app/experience as a user other than the owner, so we are having to edit the info.json file for the app to change the ownership as required. I am currently chasing down a better way of overcoming this issue, I tried this suggestion but it does not work. Apparently, there is no ability to perform shared updates, but may come in a later version.

Mark

Re: Shared ExperienceBuilder development

AndreasEugster — Wed, 10 Apr 2024 13:02:38 GMT

@MarkJTurnbull how did you proceed ? any insights?

Confronted with the same problem. We have ~10 people working with the ExB-Dev-edition. We have an organisation-template-app which per default is used for most experiences. As described in the FAQ each developer has the public/app folder as a git-remote-repo... but as long as the developers don't change the "owner" prop in the info.json they can not use/see the template... which again interfers with the .git workflow.

Re: Shared ExperienceBuilder development

TimWestern — Fri, 01 Aug 2025 12:54:07 GMT

I don't think that totally committing the server and client to a repo may be the best way, especially when updates occur.

That having been said, I have found it useful to setup the client part as a repo, especially if you have both custom extensions (widgets) and themes. (what I'm saying is, for each instance of EXB you can have a different client folder under a folder named for the experience you are crafting. Then run one server! and which every client you want to test.

If you have more than one widget needed in an experience this is probably better than, having the widgets individually for testing. I'm not saying you couldn't just create a repository for each widget, but integrations between widgets make this a gray area. Especially if custom actions are involved.