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 will need to select times and locations for builds. You will also need to decide in what order your builds will occur. 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 will also need to consider how to handle development that does not pass testing because that development will need to be rolled back. This will prevent 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 will be 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 is not 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 choose which environments you will need and when you will need them. You will need to 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 will need to decide how to test your development for approval, who will test, what criteria you will 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.
This project will host 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 will 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 will pull 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.