Version Control and Change Management

What is Version Control?

There will always come a time when changes will need to be made to a solution. Whether you are working in an Agile, Waterfall, or even a WAgile team, change requests and scope creep are bound to make their way into your life. Let’s figure out how to journey our way through the day with these items weighing on us.

Version control is a systematic method that is used to track changes to existing solutions during development. The purpose of a structured version control process is to ensure that appropriate changes are tracked effectively, collaborating developers are aware of adjustments, responsibility and accountability is established for the changes applied, and of course, worst case scenario, you have something to fall back on should sh1t hits the fan 💩.

How Change Management Fits In?

Ever worked on a project where work items keep flowing in after requirements were already finalised? It’s not always just customers, it can be Project Managers, internal stakeholders, or sometimes yourself. Regardless, change is bound to happen and it is imperative that all changes are backlogged and vetted to ensure they fit into a release plan. The issue starts to creep in when you become a “Yes Man”. It’s ok to accommodate minor changes at times, but the more you take on, the more scope creep you allow. A structured change request process establishes ownership, accountability and priority for these requests and allows you to track, scope and align these items with your project. You now have traceability and oversight on changes, features, bugs and enhancements in line with a structured process. Below is an example of a basic change request process that can be followed.

Environment Strategy

Before we dive into building a structured version control, I am being optimistic in assuming you already have an environment strategy setup. I would hate for you to make some changes with hundreds of users actively using your solution. The purpose behind an environment strategy is to allow for your end users to interact with the most stable version of your solution in a separate environment whilst you continue to build on and improve the solution elsewhere. This helps keep the two solutions far apart and gives you control as to when your end users get to make use of all the awesome features you were working on. If you have not yet set up an environment strategy, be sure to check out my post on this here.

Version Control Within Power Platform

Canvas Apps

A very common starting point within the Power Platform is Canvas Apps. When building a Canvas App, most developers are aware that a new version of the solution is created upon each save, and the latest version becomes available when the developer publishes the solution. If you go to the details of the Canvas App, you should be able to see the apps various versions as well as who last modified it, when it was last modified, which version is live (ie. published) and lastly, what Power Apps release version the app was built on.

Now I have purposely left the Power Apps release version last for a reason 😊. Although this has the word “release”, within the Canvas App context, it gets referred to as the “Authoring Version”. This does not have anything to do with the version of the app that you have built. The authoring version rather refers to the platform version used to build the Canvas App, ie. what Power Apps Studio version you used at the time. If I were to change this authoring version, you may come across a variety of new preview or available features.

Solutions

Ideally, you should always be building objects from within a solution. When creating a new solution, you defaulted to a 1.0.0.0 version structure that you can adjust if needed. When designing your version control framework, it may be ideal to also align it with your change request process. Be it a bug fix, feature or enhancement, these changes can help drive how you structure your solution version. Here is a breakdown of a 4 tier version control process that I have made use of within smaller projects.

Let’s consider a solution that is versioned at 2.0.3.7

7 is the lowest version level. This usually includes changes such as minor bug fixes or changes, i.e changing misspelled text from “Helo” to “Hello”.

Next comes 3. This section accommodates minor features, designs or fixes that were implemented. Now, when this version increases to 4, our lowest version number resets to 0. So now our version is at 2.0.4.0.

Let’s say there was a complete UI/UX revamp on the solution and you need to release the new version. This is now a major feature/design release and sets the version to 3.0.0.0

Starting to make some sense? Let’s put it on a table.

At the start of your build, your solution version should be 1.0.0.0. Should foreseeable changes be applied following the aforementioned structure, your solution version could ultimately look like 2.1.0.23.

Pro-Code

When it comes to version control in most development frameworks, there is a centralised and distributed method that can be used. Without diving into the specifics, these methods align with the similar process of source control where developers can store their code in repositories related to a project. It is far more relevant to pro-code and tenf to make use of platforms such as GitHub, Azure DevOps or Bitbucket to store the code. The ALM Accelerator is a great example of how we can make use of version and source control within the pro-code side of the Power Platform.

Conclusion

Version control is an invaluable process within a Power Platform ALM framework that simplifies how change management is processed and helps structure this change into relevant categories and version levels. Whether you are managing version control from within a solution manually, or through Power Platform Pipelines, or even through the ALM Accelerator, you start to assign structure and accountability to your solutions, resulting in more stable deployments, fail-safes for rollbacks, streamlined change management. Effective version control and change management is a fundamental step when it comes to building stable, scalable and sustainable solutions within the Power Platform.