In this article, we introduce you to Unified Development ALM (Application Lifecycle Management), starting with the first step, which involves configuring Azure DevOps.
What is Unified Dev ALM?
The first question is: What can you do with Unified Dev ALM, and what are the recommended practices for following ALM?
We recommend using Git for version control, although the Microsoft team continues to support Team Foundation Version Control (TFVC) for Finance and Operations.
The Microsoft team also supports Azure DevOps for managing artifacts, builds, and releases in F&O. Additionally, they provide Azure DevOps tasks for builds, deployments, and tests.
With Unified Dev ALM, you can enforce consistent development policies across different applications and development teams.
Furthermore, you can also manage auditing, approvals, change management, signing, and more.
Unified Application Lifecycle Management
When initiating an implementation project, the design and development phases may involve developments in either F&O, Dataverse, or both. The source code will be stored in source control as usual, and by utilizing a build agent and build pipeline, you will create a unified package.
To deploy this unified package to target environments, you need to use PAC CLI.
Getting started on Azure DevOps (ADO)
When configuring Azure DevOps, follow these major steps:
- Sign up for Azure DevOps, create an account, and start a new project.
- Select Git as your version control system, as it is widely recognized in the software industry. However, TFVC can also be used if necessary.
- Disable the creation of new TFVC repositories under Organization Settings > Repositories. This will only prevent the creation of new TFVC repositories and will not impact existing ones.
- Create an Azure DevOps team project.
- Establish the recommended folder structure for your team project.
- Initialize the repository.
Configure Azure DevOps – Finance & Operations
Now, let’s move on to the steps required specifically for Customer Engagement:
- Install Power Platform Build Tools for Azure DevOps in your DevOps project.
- Install Dynamics 365 Finance and Operations Tools from the Visual Studio Marketplace in your DevOps project.
- Create service connections for Dataverse environments with configured service principals.
Version Control
Git operates as a distributed version control system, allowing each developer to have a complete copy of the repository on their local machine.
This setup ensures that developers can work independently and maintain full functionality without relying on a network connection. With Git, developers can commit changes locally and perform version control operations, such as viewing history and comparing versions, all without needing a network connection. These capabilities significantly enhance productivity and flexibility in development.
Git supports lightweight branching, enabling developers to swiftly create and manage branches locally. This is particularly useful for developing different features or variations of the codebase.
Developers can effortlessly switch between branches to work on various features or codebase variations, improving workflow efficiency and enabling effective multitasking.
When changes are ready to be integrated, branches can be merged easily. Developers also have the option to publish branches for team collaboration or discard them when they are no longer needed.
Lastly, Git integrates seamlessly with Visual Studio and Azure DevOps, and it is compatible with third-party Git services and clients. This integration provides developers with flexibility in their tool usage and development workflow.
Source Control Guidelines
To maintain high standards in our development process, we must establish several source control guidelines:
- Default Target Branch Locked
- Merges Through Pull Requests (PRs)
- PRs Reference Work Items
- Consistent Commit History
- Branch Naming Conventions
- Clear Repository Documentation
- Secrets Management
- Public Repository Guidelines
- These are essential engineering fundamentals checklists.
Branching
To ensure the stability and efficiency of your Finance and Operations development environment, it is crucial to implement a robust branching strategy.
Branch configurations can vary depending on the development team’s preferences and the Dynamics 365 implementation cycle. Teams should consider the following minimum branching criteria:
- Isolation of untested development code (code that is still in development)
- Isolation of in-development code from test-eligible code
- Isolation of in-test code from production code
- Support for long functional testing cycles
Ideally, the branching strategy should align with all requirements posed by the project plan. Scenarios can include:
- Developer isolation of features not ready for production in the current phase.
- Stabilized branches serving UAT/SIT (User Acceptance Testing/System Integration Testing) scenarios.
- Hotfix branches enabling the creation of hotfix packages to be released to production.