When I discuss different Application Lifecycle Management (ALM) approaches with colleagues, customers and other community members there is often confusion about the differences between an Environment centric and Source code centric approach.

This blog post tries to explain the differences and shed some light on the different terms.

Environment centric approach

As the name suggests the single source of truth in the Environment centric approach is your development environment.

The basic approach is that you export your solution(s) as managed from DEV and deploy it to the downstream environments. I would say that this approach is the one which is used in most of the current Power Platform projects.

Usually, this means that the focus is on the development environment. It will be nurtured and taken care of. Which in itself has a positive and negative impact. When the development environment fails and becomes unusable or any wrong change is made which can’t be undone you might get problems since it is the only environment where you can make changes.

The following image illustrates the approach.

Advantages and disadvantages

As with everything there are certain advantages but also disadvantages of this approach.

The Environment centric approach is easy to set up and manage (until a certain size). This explains why it is, as mentioned, most commonly used. In addition, it is the approach which feels like the most natural one, especially at the beginning of a project. In this period there are a lot of people making changes and the time pressure is high. Usually, the focus does not lie on a proper ALM process. This leads to manual deployments.

Problems may arise when something happens to your development environment and it gets unusable. In that case you might loose the configuration you made so far or at least need a considerable amount of time to restore your development environment.

Another downside of all the nurturing and caring for the development environment is that “it is getting old”. With that, every whatsoever small configuration made to the environment stays as is and sometimes never gets revisited or documented as well as the recreation is never “trained”. As soon as there is some stuff turnover information about at least some of this manual configuration is lost. All this together makes it even harder when the environment gets lost or corrupt somehow.

Source code centric approach

In this approach, the source code (or repository) is the single source of truth.

An implementation would export the solution from development and unpack it to the repository. When the solution should be deployed to the downstream environment the solution zip file is packed from the repository and deployed to the target environment.

This approach does require some kind of automation through pipelines. It is not possible to do this manually. But it is possible to introduce it after the environment centric approach has been used earlier.

The following illustration explains this approach. There is no direct relation between the environments. Everything is moving through the repository.

Diana Birkelbach (LinkedIn and Twitter/X) has a nice article on how to implement parts of this approach.

Advantages and disadvantages

This approach does require more management and discipline. It also requires to be implemented in an automated approach via pipelines as well as the pipelines get more complex.

The dependency on certain environments is minimized. This means when the development environment gets unusable for some reason it is possible to recreate it from the current version in the repository.

A branching approach which is normally used when it comes to software development can be implemented with this approach as well. This would make it easier for developers to start with the Power Platform.

The source code centric approach also enables the project to do more advanced ALM stuff. Such as injecting the correct version of Plugin DLLs or Web resources while packing the solution.

In addition the traceability will be increased since WorkItems in Azure DevOps can be linked to commits. This means one could pin point the changes made to the Solution for implementing a certain WorkItem.

Thanks to Parvez Ghumra for pointing it out in his shout-out to this post.

“Combined” approach

Often projects would like to use some parts and flexibility of the source code centric approach without all of the added complexity. In most cases this happens subconsciously without the person even knowing there are the two mentioned approaches.

This can be achieved by a combination. This means the pipeline that does the export from your dev environment will export a Managed Solution Zip file but also unpack an unmanaged version of the solution to the repository. With that one still has an
environmental centric approach, but can easily recover from losing it since there is an unpacked version of the current solution in the repository. The mentioned problems around the “old” configuration would still be the same.

Summary

While both (or all three) approaches are valid the source code centric approach is preferred because of the mentioned advantages.

I hope this post was helpful and explained the difference. If you have any feedback or questions do not hesitate to leave me a comment or get in touch with me.