For the last few years, Application Lifecycle Management (ALM) and Development and Operations (DevOps) have been the hot topics in discussions for how your code is built and made its way into your users’ hands. Whether it’s through internal users, mobile applications, AB testing, deployment slots, etc, etc – these were key themes of discussion that focused around the practice of delivering your code to different environments that adhered to some pretty basic principles;
- Deploy consistently to each environment (validate and test your process).
- Automate as much as you can to simplify your life – gone are lengthy, manual deployment plans.
- Continually building solutions and code to ensure you are getting immediate feedback on what may or may not be going wrong.
- Integration of Unit Tests to validate your code before it reaches the environment and user.
- Handle and automate connections and variables between environments.
All of this together, I’ve always looked at ALM and DevOps with the primary goal of simplifying my life – letting me focus on the work that needed to be done – not the structure and plumbing.
CRM and PowerApps have come a long way with their integration to DevOps, especially over the last year.
- Ongoing Integration into Azure DevOps
- Integrated Git Source Control
- Deployment Pipelines
- Pushing for Managed solution delivery (even though you can toggle it off – you shouldn’t)
- Automated solution checker in deployments.
- Integrated Data Flows
- Solution Environment Variables
Whether you are coding, no coding, or vibe coding (plans) – these are fundamental parts of your delivery that you shouldn’t ignore, because they will set you up for success when you get the request to;
- Deploy to a new environment (because someone, somewhere needs access to data).
- Look at the history of why someone made a change 3 weeks ago that is now causing an issue with your users.
- Not have to deal with people changing things in production because it’s all open.
- Being able to see what deployments failed the night before.
I’ve always been a huge proponent of making sure I understand what I’m building on – I don’t know if this is from innate curiosity, from having done many house renovations or from having had to cleanup loads of techdebt over the years – but if you don’t know what you’re building on, how are you going to understand the impact to what you are building towards?
Who builds a deck 15 feet up and throws a hot tub on it, not wondering if the structure can hold its weight? No one wants to be under that thing when it falls over?
The same goes for your ALM and DevOps strategy; don’t throw it out or ignore it simply because a tool you are using didn’t ask about it.
Force the conversation, include it in whatever great app you are building; it will save you in the long run, it might not look cool and fancy today, but it will save you.