After a brief introduction in my first post, this will expand into more detail as to why ALM (Application Lifecycle Management) is critically important to your projects. Along with platform governance, it is a core aspect of using Power Platform and Dynamics as professional development tools to complement traditional methods such as coding. Without them and without multiple teams, the ecosystem will not be able to be managed efficiently and projects will never be able to move to enterprise scale.

Requirements

Power Platform is a software development tool and with any software development project, requirements (functional and non-functional are key). I will start with a controversial statement to many – software is not about developers or IT. It’s not about what code we want to write, what tools we want to use, if we follow scrum or not, it’s about users. Without being able to help people do what they need to do in a simpler, understandable way, it is just a hobby.

With that out of the way, let’s look at requirements. For this, you need a dedicated product/project manager who understands non-technical user needs and what is technically possible. They can draw up change requests, proof of concepts, technical research, etc in tools such as Azure DevOps which by the time it reaches the engineering team, are fully defined and ready to plan and implement. At this stage of my career, I believe developers drawing up their own requirements will not end up with the best software – there will always be technical bias that cannot be challenged by a user due to lack of knowledge.

Engineering / Infrastructure

These teams are 2 sides of the same coin – infrastructure look after the environments, security and licensing; engineering oversee customisation of Dynamics and process creation. All elements have to be done by the nature of the platform, but too many in the hands of one team (or person) is running a very high risk of becoming unsustainable.

Let’s use some examples. All control with engineering focussed staff – they want to get things done and do it quickly. They may use System Administrator roles, not use teams, choose a Dynamics license instead of Power Apps per-user, not have multiple environments to build, test and live – you can see how quickly this will unravel and become a security and cost risk. Infrastructure focussed staff – they will want to ensure security and affordability, but this may make changes slower, using inefficient tools, not release managed solutions – usability will become poor.

Both teams have to exist, specialise in their areas and hold each other accountable. It isn’t about throwing tasks over the wall, but complementing each other to have high quality development, released in a minimised risk way. It is vital for the leads to help team members understand both sides and that each are heavily intertwined with the other.

Testing

Developers cannot reliably test their changes in a full and robust way. We can write unit tests, run flows, check the interface, but QA staff are as specialist in their own area as developers are in theirs. Testing isn’t just running a script (manual or automated) over and over again – that just proves what works – you have to prove what doesn’t work. A combination of manual smoke tests, automated regression and performance, UAT by the organisation are all highly important and if you don’t do them all, you haven’t tested.

Things can also go the other way – too much of 1 thing. Do you do unit tests and mocked integration and real integration and front end and… and… and… which make your builds take 30 minutes to run? It’s too much. Testing needs focus and a reason, just like development needs a reason – it’s all about the users.

We’ll aim to go into this in more detail in the future with a QA lead sharing their ideas.

Releasing

This is a big technical topic that has partially been covered in the previous post about what is Power Platform? To repeat:

• Always have a minimum of 3, if not 4 environments – Dev, Test (QA and UAT), Live.
• Only use unmanaged solutions in dev, nowhere else – really, absolutely, nowhere else.
• Use managed everywhere else – Test, Live, the Moon. You should not be making any changes outside dev.

To add some detail, I would recommend a 5th environment – Prototyping. This is a mimic of dev to allow for proof of concept work, which is still properly planned via your Product Manager, but may not go into full development after demo. If it doesn’t, the changes are reverted, but if it does, the unmanaged solution is copied to dev and continued from there. If staff want to do training, experiment, etc then use trial or developer environments – never let anyone into your non-default environments unless there is a specific need and only for fully defined change requests.

Define your solutions in a structured way that works for you and stick with it. Never create new solutions as you go along – this isn’t a .net project, releasing cannot operate in the same way as code, but even if it could – would you create a new project or class file every time? Of course not. I like to define around business usage, say emails, document management, etc rather than technical item (flows, apps, JS, etc) as you will eventually have dependencies between customisations and will have to include mixed types. It will also make it easier to find your customisations.

To release solutions, always ensure you have connection references within them. If you don’t, you will not be able to retain what accounts are used and fundamentally breaks the premise of solutions.

Use automation. When you import a solution, the owner becomes the person importing and connections the references use have to be owned by that user. This will very quickly become a major issue if that person leaves – the flows will stop, the connections will break and your system will stop working. It may sound extreme, but I’ve seen it happen. Power Platform has a new built-in pipelines option, but I wouldn’t use this as it simply automates a manual import. Azure DevOps is the only robust answer, as you can then use Azure App Registrations which are non-interactive users and therefore will never expire and have increased security. I will be writing 2 full posts soon about Pipelines vs DevOps and how to build a DevOps release.

Conclusion…

All of this ensures consistency between environments and therefore a reliable system the users can trust and developers can support.