As a consultancy that delivers software solutions via the Microsoft Dynamics 365 CRM/CE and Power Platform platforms, the build and release management of solutions is a critical component of solution delivery. In fact, I would argue that build and release management is as important as requirements gathering, your delivery methodology on a day-to-day basis, and all other facets of delivering a project.

So, what do we mean by “principles overprocess”?

In the book titled “The Trusted Advisor Field Book: A Comprehensive Toolkit for Leading with Trust” by Charles H. Green and Andrea P. Howe, they discuss “Principles over process”. A principle is a fundamental truth about something; whereas a process refers to a set of steps to achieve a particular end.

We often get hung up on processes when doing software work, instead of focusing on the principles. As an example, you may get hung up on how to deploy solutions using Microsoft Azure DevOps versus how you do them with Jenkins. Focusing on Jenkins versus ADO is a flaw in the fundamental thinking of a Consultant. The focus, instead, should be on the principles of what you are trying to achieve instead of the process.

The problem with focusing on processes over principles is that Junior Consultants will get flustered when new situations arise. Processes do not handle changes well, whereas guiding principles do. And especially in software consultancy where the software is ever-changing.

Then, what are the principles of build and release management?

‍

1. Build jobs should be separate from release jobs.
2. A build job results in your deployable solution (i.e., artifact).
3. You should strive for no manual intervention in a build job.
4. Artifacts should be versioned, including a build number, and stored as part of your deliverables.
5. The artifact that results from your build job is what gets pushed to ALL other environments (i.e., the build job that comes out of your development environment is the one that gets pushed to the QA, UAT, and Production environments; do not push an artifact that is built out of QA into UAT and Production, and so on.)
6. Pushing your deployable solution (i.e., artifact) to other environments is called a “release”.
7. You should strive for no manual intervention in a release job.
8. User stories and features should be cross-referenced to all builds they are associated to.

‍

‍‍About Purely CRM

For close to a decade our Purely CRM team has been laser-like focused on delivering CRM solutions built solely on Microsoft Dynamics 365 CRM, combined with Power Apps and the Microsoft Power Platform. We’ve expanded our team immensely in the past years to help better serve our clients and partners. Most recently we merged with Endeavour Solutions, a top Microsoft ERP, CRM, and Cloud consulting firm to further expand our talented team of CRM consultants.

Our core focus is on large mid-market and enterprise CRM Design & Development projects, Staff Augmentation, and CRM Support. When needed we can also tap upon our peers at Endeavour for Dynamics 365 Business Central ERP to provide an All-in-One Cloud ERP-CRM.  We provide services to clients Coast to Coast across the United States and Canada. We do not use resources overseas.

Reach out to explore our track record, rates, skills, and approach to discover how we can collaborate and drive YOUR SUCCESS.

‍