What is ALM?
ALM stands for Application Lifecycle management. In the context of the Power Platform, Microsoft define ALM as follows:
ALM is the lifecycle management of applications, which includes governance, development, and maintenance. Moreover, it includes these disciplines: requirements management, software architecture, development, testing, maintenance, change management, continuous integration, project management, deployment, and release management. ALM tools provide a standardised system for communication and collaboration between software development teams and related departments, such as test and operations. These tools can also automate the process of software development and delivery. To that end, ALM combines the disciplines concerned with all aspects of the process to achieve the goal of driving efficiency through predictable and repeatable software delivery.
Why Does ALM Matter?
A good Application Lifecycle Management approach is key to project success, and if not considered at the start of a project can cause serious problems further down the line.
An example of this might be a project which starts out with some simple customisations to Dynamics 365, completed in a single solution in a sandbox environment and then manually deployed to production once tested. Whilst this scenario would likely satisfactorily satisfy the requirements of the project in its early stages, as the project progresses perhaps another developer is added to the team, or another testing environment added, or both! Once this happens, it becomes much harder to track who has changed what, which version of a solution is in which environment, and what might have caused an issue in the production environment. ALM can help with these issues, by providing visibility of changes, as well as automation around deployments and environment management, which will greatly reduce the risk of human error within the project.
ALM is a large and complex topic, so this blog will focus on a specific area, solution management within Dynamics 365 and the Power Platform.
What is a Solution?
A solution is a container for changes. Within it can exist various Power Platform components, such as tables, columns, flows or bots.
Solution can be ‘Unmanaged’ or ‘Managed’. Unmanaged solutions are used in development environments and contain details of all the changes made within that solution. Unmanaged solutions should be exported, unpacked, and checked into a source control tool, such as Azure DevOps, to maintain a history of the customisations that are made. Managed solutions are then used in any environment which is not a development environment, such as UAT, SIT or production.
How Can Azure DevOps Help?
Microsoft have released Power Platform Build Tools, which is a set of tools that can be installed in Azure DevOps and help with automating the tasks associated with good ALM practices, such as exporting and importing solutions, and adding them to source control. The toolkit also contains features which help with environment management and the deployment of data as well as customisations, but these will the topic of separate blogs. Here’s an insightful video about how Infinity Group run projects using DevOps.
Details of the Power Platform Build Tools can be found here: Microsoft Power Platform Build Tools for Azure DevOps – Power Platform | Microsoft Docs
Using the build tools, a pipeline can be created in Azure DevOps which automatically exports an unmanaged solution from a development environment, unpacks it, and checks it in to source control. Unpacking is the term used for extracting the contents of a solution into separate components, once an unpacked solution is checked into source control, it is then possible to track changes to the individual components within that solution. An example pipeline to extract and unpack a solution might look like this:
Once this process is complete, it is then possible to compare versions of a solution component to identify what might have changed. This example demonstrates the process of comparing two files, and shows that we can see where a field has been moved:
Being able to compare solution components like this at a granular level means any issues can be easily traced, and changes can be undone if required. We can then use the build tools to take a solution and import it into a production environment, a simplified version of that pipeline could look like this:
By automating these steps, we not only make the process of managing solutions more efficient and therefore save valuable consultant time, but we also make the process repeatable and robust. With the correct pipelines configured in Azure DevOps a completely new development environment can be create, configured, and deployed within seconds. This opens up a powerful set of opportunities when working on multiple concurrent projects or with teams of developers.
In a future blog post we will cover the process of deploying packages, where both customisations and data are included, to demonstrate the power of being able to deploy and configure an environment in an automated fashion.
If your project is suffering from versioning issues, or you’re struggling to have multiple resources work on Microsoft Dynamics 365 concurrently, please get in touch and one of our Consultants can assist you.
