Define Application Lifecycle Management
Most projects will have a full quality assurance plan and team. However, each member of the maker team needs to participate in some capacity to ensure quality solutions. From unit testing, as you configure to assist in release pipelines with Azure DevOps, there are plenty of points in a project that you can influence and guide to success.
Application Lifecycle Management (ALM)
Generally speaking, the solution architect, or a DevOps engineer will own the ALM process. But as a key member of the maker team, your involvement under their direction is necessary. To be successful, you will need to understand and follow ALM processes, as defined by the solution architect (or devops engineer). Ask questions, offer to document the plan, and get confirmation of your understanding. While creating this documentation, you will also be learning more about the ALM plans for the project.
As you build you will be validating your work using platform tools such as app checker, flow checker and solution checker.
All of your work will be happening in the context of a solution and you should understand how to create, export, and import solutions as instructed by the solution architect. For a larger project, you will likely encounter more formalized build pipelines and automated continuous deployment.
Solution packager
Solution packager should be used to take the unmanaged solution from development and prepare it for storing in a source control repository. Solution packager takes the single solution file and breaks it into individual files representing each solution component. This solution packager process is referred to as unpacking the solution. The output from solution packager is then checked in to the source control repository. This output version that is checked in, now represents the source of truth for the project.
Solution packager can also pack the folder from source control, re-creating the single solution file. The files that are checked into source control are then used to create the solutions that will be imported into the other environments. While Solution Packager can be run manually, it is more commonly run using Microsoft Power Platform Build Tools as part of an automated pipeline.
Package deployer
Package deployer allows you to create a package that includes multiple solutions, data from configuration migration tool and developer code logic that runs before and after the import of the package is completed. In many ways, you could think of package deployer as an install wizard for Microsoft Power Platform. Package deployer can be run interactively to manually import packages and data into an environment. Package deployer also supports running via PowerShell, which would allow automation and integration into Azure Pipelines.
Solution checker
As Power Automate and Power Apps are used to customize a deployment, each offers their own inline app checkers that are helpful for real-time issue resolution. However, solution checker (more details here) is able to look at the whole solution, do static analysis, and produce a detailed list of any issues found.
Solution checker should be run regularly on any unmanaged solution you are building in your development environments. Solution checker can analyze Power Apps and Power Automate flows as well as code assets like plugins that developers create. The project team can manually run solution checker from the maker portal by selecting the solution and then running the checker. Solution checker can also be automated to run as part of a build process either using PowerShell or Azure Pipeline tasks. By automating the run of solution checker, it can become an integral part of the build process and even can be set up to stop the build if too many errors have occurred. Simply running solution checker is not enough for the team to be successful they must also have a plan in place to regularly evaluate and resolve problems identified.
Automate deployment
An area that is as important as part of the build plan is looking at what automation can be used to make the process repeatable. There are many tools available both from Microsoft and the community that can be used to automate the build process. Microsoft is investing in Azure DevOps and a set of Microsoft Power Platform tasks that can be used to automate the solution management and deployment tasks. For example, a team could have an Azure Pipeline that every day at 7:00 PM extracts from development and checks it into a git repository. The same pipeline can also be used to run solution checker so when the team comes in the morning they know immediately if there were any issues identified in the prior night's build. The pipeline could also import the solution into a clean build environment that will allow detection of any dependencies that were introduced unintentionally through that day's development. This ensures what is checked into source control is a clean version ready for deployment into other environments. Pipelines can also be used to automate testing so that it’s just another step within the pipeline. Azure Pipelines are also used to produce the managed solution artifact that will be used in the release pipelines to deploy to the upstream environments such as test and production. The same solution artifact that was used in test is used all the way to production. This ensures that it’s not introducing new surprise changes as the promotion progresses through the series of environments ending at production. Azure Pipelines can also be used to build developer code assets to ensure that they are not being built on a local developer workstation.
Version control
By default, as changes progress from dev to test to production it represents a single work stream of changes. If a problem is identified in production, you would fix it in development and then promote it through the series of environments back to production. A single work stream like this works well if no new development is done. If the development team has already moved on to version 2 in their development environment and then fixes a bug that was identified in production, as the fix is moved to production so would any of the work in progress for version 2 because it was all mixed together. The ideal action is where the change is made in a separate work stream development environment that represented only what was already in production and what was promoted only included the fix and not anything from version 2. This requires the project team to plan ahead and have a strategy for managing multiple active versions. This could be as simple as an active development stream and a maintenance stream to support production. More complex projects might even have multiple active development streams going on at the same time.
Handling both active development and maintenance streams at the same time is typically handled through a combination of Dataverse environments and source control branches. Branches allow having a copy of the project assets and an isolated way of making changes in an environment associated with that branch. Changes from one branch can be merged with another branch. Branching strategy should be kept as simple as possible to avoid having to resolve many conflicts during merging of branches.