Recently a had a session at an event I planned for the Power Platform User Group Iceland – PPUGIS on the ALM for Power Platform(PP) applications. This blog is to follow up on that session and share some thoughts on ALM. To better understand the inner workings of the Power Platform framework I will start by explaining the concepts of environments and solutions and then how we use those for our ALM strategy.
The ALM strategy covers the lifecycle, development, governance, architecture, maintenance, delivery, testing and much more. The ALM is designed and created in order to maintain dicipline of the whole process for an application from the firste idea until the application is scrapped. The ALM is a a culture and lifestyle that is implemented as a team effort but not by a single person.
The ALM strategy is bigger than so it can outlined in one blog post, but I will give you a nidge in the right direction with inforation about the basics you need to know and understand. I will also follow up on this post in few days with a post or videao about how to use Azure DevOps automation to deploy a solution from DEV to TEST.
We can think of environments as containers, a box, a crate, or similar that makes sense in our personal PP lingo. An environment is where everything begins or at least should begin when it comes to creating apps, flows, bots etc. The most common environments we use when creating applications and other software are:
- Development or DEV
- Production or PROD
This off course also applies for PP application making and we will come to these later in this blog, in the ALM section.
There are few types of environments available and knowing the difference between them and when to use what type is important, before reading the rest of this blog read about the environment types.
The environment strategy is a big part of the ALM and it should support the development work/process in your company with the overall goal to increase the development productivity. The strategy is setup to manage environments, solutions, security, provision new environment(s) and so on. The following points are a good guide for you to consider for your company’s strategy:
- How will the default environment be used?
- If you develop multiple applications, you need to make sure they are isolated and can be delivered independently.
- Organize the assets/resources in a logical manner that fits your company and the work you do.
- Limit the number of people that have permissions to provision new environments.
- On the bullet above always ask “Why new environment?”. You want to keep the number of environments as low as possible.
- Support and maintenance are a big part of the ALM. As soon as your company ships an application to one customer, that customer expects help on how to use the application and there must be a process in place to tackle bug fixes and further development.
- Geo location must be considered. Where you create the environment determines where data and other resources are stored.
The Default environment is not for development, test nor production
Solutions are the centeriece in your ALM strategy and the mechanism to use in buildng your overall ALM strategy. Solutions are containers within a single environment that app makers can use to group together elements and artifacts the develoment team decides should be delivered together. There are few key concepts for solutions that are important to understand and know how they work, read the details here.
The most important concept to learn about and understand about solutions are managed and unmanged solution. In its simplest version we use unmanaged solutions in our development environments and preferably managed in all environments.
- The unmanaged solution can be modified but the managed can’t be
- The unmanged solution can be exported but the managed can’t be
- When you delete an unmanaged solution all the components remain intack
- When you delete a managed solution all the components are deleted as well
Application Lifecycle Management
There is no one single ALM strategy that is correct for all companies, projects, developers, app makers and so on. Creating and maintaining a healthy ALM process for all the Power Platform work that is done is not something you create ones and then just get busy creating stuff, that is not how this works.
In the beginning of the journey the whole team should discuss things like goals and purpose of the ALM strategy. What is the ALM strategy going to achieve? Who should know the ins and outs of it? Who is responsible for what parts? What environments should exist? Do we need single solution, multi solutions, inter-linked solution or mix of it all? These are just few exmples of the questions the team needs to discuss and answer in the absolute beginning and not as I have often seen, closer to the end when an app and some flows are in production and there is something that needs to be fixed but no one knows how.
The key areas of the ALM are:
- Plannind, designing, building and testing amongst other
- As soon as you devlier an app or a solution to a production environment an obligation of maintenance is on your shoulders
- Who can do what and where. You need to control not only access to the solutions in production but you also need to think about who can create, change or even delete an environment
Here are two really good resources to get you started
About healthy ALM
Overview of application lifecycle management with Microsoft Power Platform