cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
xilef
Level: Powered On

Best way to develop a relatively large app?

Hello, we have a scenario that we are developing a large app consists of say 10 SharePoint data sources.

Once finished, this app will be in production and widely used within my organization.

Image later someday, we want to develop a new feature on this app, while we don't want to stop or disturb our users from using the app, so what is the best practices for this?

Not publishing the app. This does not work because while the new feature is in developing, we may occasionally test it, by clicking submit, modify, or delete button, which will destory the backend data sources and affecting normal users.

 

What if we duplicate the production SharePoint lists for testing purposes? We have faced implementing issue: How can we switch between testing and production data sources effectively?

Say we have a production list named Prod1 and the corresponding duplicated testing list named Test1.

In the OnStart property of the app, we use:

Set(IsDebugging, true) // or false if we want to publish
Set(SourceRef1, If(IsDebugging, Test1, Prod1)) // use a variable to reference the underlying source

Then in the gallery control, we set its Item property to SourceRef1. It seems to work but not behave well. When we use SubmitForm to create a new record, the underlying source is updated, but the SourceRef1 is not refreshed, so we have to call this

Refresh(If(IsDebugging, Test1, Prod1))
Set(SourceRef1, If(IsDebugging, Test1, Prod1))

After each time we call SubmitForm. And not only SubmitForm, but also we have to do so for Remove, Update, Patch, or ANY function that modifies the referenced data source. And we have 10 data sources, That situation is jsut unacceptable.

We are wondering if there is any elegant way to solve this problem? Without this, I doubt if we can use PowerApps in any relatively large project. I don't know if I clearly state what I want to express, you are free to ask me for further explanation.


Thanks.

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
samuelJ
Level 8

Re: Best way to develop a relatively large app?

We don't really use sharepoint much in our apps but we use sql server.  So I assume you can implement something similar.

 

Similar to what you said, we have a PROD and DEV database with the same table schemas.  We also have a PROD and DEV powerApps App.  We do our development and testing in the dev app, then when we are ready to deploy in prod, PowerApps has an "export" and "import" feature for things like this: see Link.  So you export your dev app as an "update existing project" then you import that to your PROD app.  (This next part is true with SQL not sure on sharepoint) When importing a project, you can choose a datasource to use.  So when we have a PROD and DEV DB we choose the respective source and as long as the tables schemas are the same, there are no issues.  

 

We have had no issues with this process, it eliminates the needs for a "test" variable in your app, like you suggested. 

4 REPLIES 4
Administrator
Administrator

Re: Best way to develop a relatively large app?

Hi @xilef I will add in a Product Manager to review your situation and hopefully provide a solution for you. 

 

@TopShelf-MSFT

Highlighted
samuelJ
Level 8

Re: Best way to develop a relatively large app?

We don't really use sharepoint much in our apps but we use sql server.  So I assume you can implement something similar.

 

Similar to what you said, we have a PROD and DEV database with the same table schemas.  We also have a PROD and DEV powerApps App.  We do our development and testing in the dev app, then when we are ready to deploy in prod, PowerApps has an "export" and "import" feature for things like this: see Link.  So you export your dev app as an "update existing project" then you import that to your PROD app.  (This next part is true with SQL not sure on sharepoint) When importing a project, you can choose a datasource to use.  So when we have a PROD and DEV DB we choose the respective source and as long as the tables schemas are the same, there are no issues.  

 

We have had no issues with this process, it eliminates the needs for a "test" variable in your app, like you suggested. 

xilef
Level: Powered On

Re: Best way to develop a relatively large app?

Thanks for your reply. Unfortunately this method does not work with SharePoint. When I was trying to import a package, I could only either use existing sharepoint connection (which is the one exported), or create a new connection with the same site (so the created one were as same as the existing one). I did not see a third option.

Administrator
Administrator

Re: Best way to develop a relatively large app?

adding in @KeremY to assist with this SharePoint question

 

@TopShelf-MSFT