For Power Apps citizen developers, that may not come from a developer background, the beauty and relatively simplistic development platform allows for the creation of line of business (LOB) applications at a rapid pace and low cost. One of these features is the inherent continuous development, and integration, (CD/CI) on a single trunk. This is best suited for a single developer since this development environment does not really allow for concurrent development.
My Experience
At a recent customer engagement, after releasing a new version, one of the platforms did not work as expected. The application was hosted in multiple environments such as a browser, Teams, iPad (iOS) client, or Windows client. The browser version, as well as iPad client application, worked as expected but the Windows client experienced an error that prevented the application from functioning correctly.
This scenario raised a separate problem with the CD/CI paradigm when you publish a new version the old version is replaced, and the client applications will download the latest version thus replacing the old. This is not optimal in a traditional sense where business is used to a development, QA/testing, and production environment however, the following strategy will satisfy the desire to maintain a stable production environment as well as the ability to continue development.
My Strategy
As a developer, you work in an agile pattern but the business is expecting functionality to be delivered based on a waterfall schedule. Compromising, we will finish each gated version by exporting the application/solution.
The package is a zip file and it is also a ‘backup of the current version. We will use this package when we create a new version to continue the development. When it is time to start the next development cycle, we will use this backup file to create a new version.
After the completed import we now have the new development, QA/testing branch where the development may continue in an agile CD/CI pattern. This new version does not affect the current production version.
When development and testing have reached the next production deployment point, we will follow the same export/import process described above for the next version even if it may be the last version planned.
In conclusion, by using the Export/Import function we can create new independent versions. The scenario above will create new independent versions. However, if we instead of selecting the setup type of Create as new we choose Update and which application to update, we want to update the current application will be replaced by the new version. This makes the sharing settings easier to manage but we sacrifice a phased rollout.