Application Lifecycle Management for Power Platform
For several years, low-code solutions like Microsoftss Power Platform have empowered “citizen developers” to build impressive and effective solutions to their business problems. One of the Power Platform’s advantages (and reason for existence) is to put powerful software development in the hands of non-traditional software developers while shielding them from the complexity that comes with full-code software development.
But a funny thing happened on the way to the rollout of democratized enterprise software: many of the standard application lifecycle management (ALM) practices were lost in that process. Microsoft is now bringing many of those ALM powers to bear in the Power Platform.
What Is Application Lifecycle Management?
Application lifecycle management is defined as the tools and processes that manage the lifecycle of an application from conception through release and retirement. Adopting ALM is also closely associated with the continuous delivery of software with frequent releases (sometimes as often as several per day) as opposed to releases and updates only coming every few months. Application lifecycle management provides a framework for software development and ensures that every team member knows the Who, What, When and Why of any changes made during the development process.
Why Application Lifecycle Management Matters
If you are a software development professional coming from a full-code background, you are accustomed to several application lifecycle management practices and tools. One is a progression of infrastructure environments to move code through each release – dev, testing, staging and/or production (names will depend on your shop). These distinct environments enable you to run continuous integration and testing in a low-risk environment (dev/testing), perform internal checks and elicit stakeholder feedback (staging), and release for real and high-volume use (production) when it’s ready.
This staged release mechanism enables software developers to have a test data bed (remove personally identifiable information, etc.) while keeping production data clean. Separation of environments is also very important to make use of dev/testing values for things like emails and transactions (i.e. test credit card accounts) in non-prod environments for low-risk end-to-end testing. If you’ve been in the game for a while, you have become dependent on these powers. Without them, you are carrying out a lot of careful manual adjustments to achieve similar results – or you’re at risk of becoming the next “test in production” meme.
Does ALM Have a Place in Low-Code Development?
Traditionally, low-code tools and ecosystems have not had an ALM story, which has been viewed alternately as a feature and a problem:
- It is a feature because with low-code development you don’t have to be pestered with such things as formal deployments, formal QA, etc. You can just do your thing and roll it out – and that is exactly what most low-code developers do.
- It is a problem in the sense that even though low in code, these solutions carrying out enterprise and important jobs have to be right (not just “kind of right, not bad for a non-developer”). I’ve already played my hand, but MercuryWorks believes that ALM does in fact have a place in low-code development.
ALM for Power Platform: Two Approaches
As a leading low-code platform for developers, Power Platform makes an ideal backdrop for reintroducing application lifecycle management practices. There are currently two ways to apply ALM here: build your own features into Power Platform or use Power Platform Solutions.
1. Roll Your Own Low-Code ALM
Prior to having formal ALM facilities built into the Power Platform, low-code developers were forced to roll their own supporting features in their solutions. The following is an example of a “Test Mode” that we have built into Power Automate flows in order to provide a lever to place a process into non-production mode (and handle notification emails accordingly).
Simply put, we create a Boolean variable that determines whether or not the flow is current in Test Mode along with a variable to track the identity of the tester. This status flag and tester identity tracker can be used to great effect with a Flow in production use to operate as normally but include additional messaging and logging to testers/support staff.
With this strategy in place we can then use these values to either use custom “Condition” blocks that hinge on the Test Mode variable or cc: support staff (based on the value set for Tester Email Address) such as in this example (if not in test mode the null email address will keep anyone from receiving extra emails):
2. Power Platform Solutions
Luckily, as the low-code ecosystem evolves, it has moved into a maturation phase which has brought capabilities like ALM with it. Solutions are Microsoft’s mechanism for implementing application lifecycle management (ALM) in Power Apps and other Power Platform products, such as Power Automate.
Initially rolled out for non-production environments in mid-2021, at this time Solutions remain in Preview mode which brings with it a few caveats:
- They are not supported by Microsoft Support
- Functionality may be missing
- They are not meant for production use
For the above reasons, Solutions is a feature you may want to dive into, utilize for internal non-essential systems, and generally build capability with until they are removed from Preview mode.
Implementing Power Platform Solutions for ALM
Here are a few features and considerations to keep in mind as you leverage Solutions for your own application lifecycle management in Power Platform. Keep in mind that Solutions remain in Preview Mode and are not yet meant for production use:
Create Your Power Platform Environments
The first step in accruing the benefits of diverse environments and the classic dev-staging-prod lifestyle within Power Platform is to create your desired Environments. As you would expect, this capability is found in the Power Platform Admin Center (this used to be restricted to Dynamics 365 admin).
A Power Platform Environment is a space to store, manage and share your organization’s data, apps and flows. It also serves as a container to separate apps that may have different roles, security requirements or target audiences. When users create an app, they place it in an environment and then that app can connect to any object within that Environment.
Power Apps and Power Automate automatically create a single default Environment for each tenant. If you have not had reason to experiment with Solutions to date, your tenant most likely has that single Environment.
Microsoft has published full details on the steps required to create an Environment, but the following screenshots illustrate the environment creation process:
2. Get Hands-On With Solutions
Now that we are armed with multiple environments, you can begin to capitalize on the benefits of Power Platform Solutions. Solutions are Microsoft’s main mechanism for implementing Power Platform application lifecycle management, most notably in Power Apps and Power Automate.
Solutions are used to transport apps and components from one environment to another or to apply a set of customizations to existing apps. This means that a solution can contain multiple apps and objects (tables, processes, web resources, choices, flows and more) that are all involved to solve a business problem.
Within Power Apps and Power Automate, you can view a list of solutions by selecting Solutions in the left navigation. Note that because Solutions are still in Preview mode that you need to enable the “Solution preview on” toggle in the Admin Center.
What’s this look like?
Clicking on any solution in the overall list will drill you down into the objects contained within that solution.
If this as far as you choose to go with Power Platform ALM, the flows and apps you have placed in a solution will continue to work just as if you had constructed them outside of a solution. The only difference thus far is that rather than seeing your flows in the standard “My flows” tab (for example), you will need to drill into the relevant solution to access and modify the flow (or app or table, etc.):
Connection References, Not Connections!
A key ALM element that Microsoft added to Power Platform Solutions is that of connection references rather than direct connections.
Microsoft’s official definition of a connection reference is “a proxy or a wrapper around an API that allows the underlying service to talk to Microsoft Power Automate, Microsoft Power Apps and Azure Logic Apps.” In other words, instead of providing credentials for a connection to a service like Teams or Outlook.com, you make connection to these services via a reference that can change across environment.
Connection references manifest within each environment as a challenge for credentials that is applicable to only that environment. In this way you can have a developer user account to access connected services in a dev environment but use a system account as the connection authority in production.
Environment Variables
Environment variables are another new key Power Platform ALM mechanism. An environment variable can be created manually in the Solutions portal interface (or if you’re fancy you can also do so in code). A variable is managed within a specific Common Data Service entity and can be accessed from any Power Platform solution element. That means, for example, an environment variable for “Admin Email” can be accessed by any Power Automate Flow within the same solution. A variable can be one of the following data types: text, JSON, decimal number, “two options” (true/false), data source or secret.
Environment variables should be used to store configuration data specific to environments, similar to the DevOps pipeline practice of using environment variables in a build script to provide database connection strings applicable to dev, staging or production.
When used properly, the environment variables can avoid storing environment-specific/dependent configuration settings anywhere in a Power App or Flow. Instead, any solution component can reference environment-specific information such as URLs and configuration parameters.