Application Lifecycle Management (ALM) in Power Platform

There has been a steady increase in the complexity of business applications and business requirements that are inclined to develop new processes and procedures to manage the entire application lifecycle. The definition of application life cycle management varies project by project and technology and ALM is not one size fits.

By definition :

Application Lifecycle Management (ALM) is the people, tools, and processes that manage the life cycle of an application from conception to end-of-life.

While the Software Development Life Cycle (SDLC) mainly focuses on the development phase, Application Lifecycle Management (ALM) includes development, governance, maintenance and finally the obsolescence of software.

In the Power platform, the application lifecycle management is the cyclical software development process that involves these area:

The components of the Power Platform are heterogeneous nature and complex, but they work together, so it has its own application lifecycle. The Dataverse in Microsoft Power Platform lets you securely store and manage data used by business applications. In order to use the features and tools available for ALM, all environments that participate in ALM must include a Dataverse database.

The following concepts are important for understanding ALM by using Microsoft Power Platform:

Environment :

An environment servers as a container to separate apps that might have different roles, security requirements, or target audiences. Developing an environment strategy means configuring  environments and other layers of data security in a way that supports productive development in your organization while simultaneously securing and organizing resources. A strategy to manage environment provisioning and access, and controlling resources with them.

Solution 

Solutions are the mechanisms for implementing ALM; we would use them to distribute components across environments through export and import. Microsoft Power Platform projects consist of components that can be packaged inside solutions in environments and components that cannot be added to solutions such as components deployed in Azure, configuration data, and Power BI reports.

The solution architect needs to decide if application lifecycle management will be managed by using solutions or by using source code control.

Traditionally, Microsoft Power Platform projects have been more environment centric, but many are now moving toward being source control centric.

If you use an environment-centric approach, then

The dev environment is the master copy of all changes.

Changes are promoted directly from dev > test > production.

If you use a source control-centric approach, then:

Source control is the master. The dev environment is re-created from source control (this process can be automated and repeatable). Changes from the dev environment are checked into source control.

Microsoft uses solutions to package apps and customizations and export from one Microsoft Dataverse environment as a file and then import that solution package file into another Dataverse environment.

Dataverse:

Microsoft Dataverse is a cloud-based, low-code data service and app platform, which allows you to leverage the security and connectivity of Microsoft services. It stores all artifact, including solutions.

Dataverse has two distinct layer:

Unmanaged layer: All imported, unmanaged solutions and specialized customization exist at this layer. all unmanaged solutions share a single unmanaged layer.

Managed layer: All imported, managed solutions and the system solution exist at this level. when multiple managed solutions are installed, the last one that is installed is above the managed solution that was previously installed. therefore the second solution that is installed can customize the one that was installed before it. when two managed solutions have conflicting definitions, the runtime behavior is "Last one wins" or a merge logic is implemented. 

Source control:

Solution-aware developer code assets (such as plug-ins, PCF code components, and form scripts (transpiled from TypeScript)) should be "built" on a build environment and not the developer's desktop. After being built, the assets should be deployed to an environment that the master solution will be exported from or built into a solution that will be installed.

Using a source control-centric approach will enable an Azure DevOps approach with build and release pipelines. Using an environment-centric approach means that you need to define the workflow for app makers and developers. The solution architect will need to define how and who will promote the app through the environments from development to production.

Source control should be our source of truth for storing and collaborating on our components.

Current ALM Gaps in the Power Platform: 

• Difficult to maintain separation of connections.
• Flows and apps lose connections.
• Difficult to change input parameters.

Conclusion:

ALM is not a one-size-fits-all solution, we have to articulate it to fit our project. The amount and sophistication of ALM should be decided on a project by project basis. It is important to understand the development methodology being used by the project team to design the solution. Also, it is important to understand the number of teams involved, especially those involved in optimizing. The ALM strategy must be influenced to support these teams, and allow project teams to work effectively.

Microsoft recommends

Build Unmanaged, Deploy Managed
as the best practice model for managing Solutions with all Dynamics 365 Legacy and Model-driven Apps.