Plan the build, test, and quality control processes
This unit reviews development processes that are used to manage the build, testing, and quality control processes, and provides information about how to plan for managing these processes.
Create a project plan for builds
Depending on the methodology that you choose, you need to select times and locations for builds. You also need to decide in what order your builds occurs. For example, you wouldn't want to build your code from the Development environment to the Production environment without going through the Testing environment first.
You also need to consider how to handle development that does not pass testing because that development needs to be rolled back. This prevents you from promoting errors. You can use Lifecycle Services to help manage your build from environment to environment.
For example, a build might roll back any code with errors from your Testing environment to your Development environment, promote the successful code from Testing to Production, and then finally promote your finished code from the Development environment to Testing.
Decide what environments are needed
Choosing your environments should be planned at the beginning of the implementation. When planning your environments, you should:
- Decide the environment's purpose. Consider whether the environments are used for development, system testing, user acceptance testing (UAT), or operations.
- Consider the environment topology, such as Develop or Build and Test.
- Consider the environment tier (Tier-1 or Tier-2).
A Tier-1 environment is a single-box environment with all the components installed on the same server. A Tier-1 environment uses Microsoft SQL Server and is structured to maximize development efficiency. This tier isn't a good option for UAT or performance testing.
A Tier-2, or higher, environment is a multi-box environment with components that are installed on multiple servers. Instead of Microsoft SQL Server, Tier-2 environments use Azure SQL Database. The architecture in this environment is the same as the Production environment, but it does not use disaster recovery. This environment should be used for UAT and performance testing.
The standard cloud offer for environments includes a Tier-1 environment for development and testing, a Tier-2 environment for UAT, and a production environment. These environments are provided at different times. Tier-2 is provided during onboarding. The Tier-1 Develop and Test environment is provided when the Design phase starts and Microsoft Azure DevOps has been configured. Finally, the Production environment is provided during production system readiness with Microsoft. This environment must be requested through Lifecycle Services.
You can also add another Add-on environment for Tier-1 and Tier-2 environments if needed. Tier-1 environments can also be deployed as a cloud-hosted environment or an environment image. Cloud-hosted environments are managed by the customer or partner. The environment image is an on-premises environment that uses a virtual hard disk.
You can select which environments you need and when you need them. You must summarize your required environment lists in a matrix for Microsoft.
You can use the environment plan to help choose the flow for building code in all your environments and to structure your ALM.
Plan for how much testing is required
While implementing finance and operations apps, you need to decide how to test your development for approval, who is testing, what criteria you use for approval, and how to track testing. Unit tests, regression tests, and performance testing can be used to test the system.
Unit testing is useful for testing whether a specific piece of functionality is working. Unit testing does not check if the new code affects existing features in the system.
Regression testing runs a test against an entire process to make sure that existing features still function with the new development. For instance, if a modification is made to add functionality that is related to customers, you might want to perform regression tests to make sure that the new functionality does not interfere with existing functionality such as sales orders.
You might also want to consider performance testing the system to make sure that the system is stable by having multiple users enter the system and perform high-volume taxing processes. This can help you find opportunities to increase performance.
Finance and operations apps includes the Task recorder tool to document the steps of a process that a user takes. Azure DevOps also lets you link tasks to a development project solution. The task can be used to track updates, testing documents, and other notes.
Source control and quality control for developers
Occasionally, several developers might be working in Finance and operations apps at the same time. To prevent developers from interfering with each other's work, source control can be set up with an Azure DevOps project.
The Azure DevOps project hosts the source code of your model, which lets users check objects in and out. When checking out an object, you are telling the system that you are making changes. When checking the object back in, the system you create a new version of that object.
Version control lets you see what previous changes were made. You can undo pending changes to the most recent checked-in changes. Additionally, you can select Get latest on objects, which pulls in the most recent checked-in version of the object. This feature should be used regularly by developers to make sure that they are using the most up-to-date code.
To ensure quality among development, follow the Microsoft Dynamics X++ best practices. Also, you might want to develop your own best practice, such as naming conventions, to keep all development standardized among the organization.
Select a version control system
In finance and operations apps, a version control system is mandatory. Azure DevOps supports both Team Foundation Version Control and Git.
Azure DevOps Team Foundation Version Control
The Azure DevOps Team Foundation Version Control system is a one version control system for finance and operations apps. It’s a centralized version control system, which means that developers work in one branch and have one version of each file on their development machines. Each branch belongs to a server workspace, and each developer works in a local workspace. When a developer checks in source code, they must ensure that they check in the latest version and resolve any conflicts.
By default, Team Foundation Version Control repositories are disabled in the Azure DevOps Organization settings, and you must enable them before you can create a new Azure DevOps project with Team Foundation Version Control as the version control system.
To enable Team Foundation Version Control (TFVC) in your organization, follow these steps.
- Open Azure DevOps at dev.azure.com/<your organization>.
- Select Organization settings in the lower-left corner of the dashboard.
- Open Repos > Repositories.
- Turn off Disable creation of TFVC repositories in All Repository Settings.
You can create new DevOps Projects with TFVC as the version control system.
Git
Git is the Microsoft default version control system that’s recommended for development. While TFVC is a centralized version control system, Git is a distributed system. Each developer has their own copy of a source repository (or lightweight branch) and can commit changes into it. Developers can create new private branches, and switch from one branch to another. In TFVC, it was more difficult to switch from one branch to another, and it often required multiple development environments.
It’s important to note that you can migrate from TFVC to Git, and vice versa.