Source control processes

• 15 minutes

Developers rely on source control to track code changes and discover differences among content that is created by various developers. Finance and operations uses Azure DevOps for source control, which is accessible through a web browser or Visual Studio by using the Team Explorer.

Azure DevOps, formerly Visual Studio Team Services

Azure DevOps is a cloud-based offering, which is also backed by a 99.9 percent service level agreement (SLA). While the core services are the same between cloud and on-premises, cloud also offers immediate access to new features, improved connectivity to remote locations, and simplified server management.

Azure DevOps

Azure DevOps is used as the source control service when developing for finance and operations apps. If you're upgrading from previous versions of Dynamics AX, you may be aware of Team Foundation Services for source control, this has been replaced by Azure DevOps. As a developer, you will need to ensure Azure DevOps is set up and configured before you start developing.

To enable source control through Azure DevOps, you need to go to https://visualstudio.microsoft.com/ and sign up for Azure DevOps to create your account. When you create your account, you select a URL for it. This will be the URL that you connect to from your development computer when you configure source control. When your account is created, or if you already have an account, create a new project.

To configure your Visual Studio environment to connect to your team project, follow these steps:

1. Open Visual Studio as an administrator.
2. Open the Solution explorer if it isn't already displaying by selecting File > Solution explorer.
3. Select the Team explorer tab at the bottom of the window.
4. Select Manage connections.
5. Select Connect to team project.
6. Select Servers….
7. In the Add/Remove Team Foundation Server window, select Add.
8. Paste the URL for your Azure DevOps project in the Name or URL of Team Foundation Server field.

9. Select OK.
10. Select Close.
11. On the Connect to Team Foundation Server window, use the dropdown to select the project you just added.
12. Select Connect.

When you are connected to the Team Foundation Server, you need to map your Azure DevOps project to your local model store and projects folders.

1. Open the Source Control Explorer from Team Explorer.
2. In the Source Control Explorer, select the Workspace dropdown at the top ribbon of the explorer.
3. Select Workspaces.. and you see a list of workspaces.
4. Select Edit for the first workspace you see.
5. Map the Metadata folder of your team project to the root folder of the model store on your local drive (this is typically K:/AosService/PackagesLocalDirectory).
6. Select Map.
7. On the next dialog, select No.
8. Repeat these steps for the Projects folder. You typically map the Projects folder to C:\Users[Admin Account name]\Documents\Visual Studio [VS Year]\Projects where Projects is a folder you create.

When creating a new Visual Studio project, you can add the project to source control. Source control enables version control on elements in Visual Studio. Version control forces you to check code out while developers are making changes to code.

When you have finished making your changes, you must check in your changes. Each check-in creates a new version of that element. This process allows other developers to see who made changes, what changes were made to an element, and when the changes were made. It also allows you to revert code to a previous version if errors are found in the current version. When you check in code, other developers can also then perform Get latest to merge all the latest available versions of the code.

When you perform a Get latest, you might come across some change conflicts, where a new version of code conflicts with what you have currently built in your code base. You can view and resolve conflict in Visual Studio on the Resolve conflicts page.

Three panes are available on the Resolve conflicts page:

• Left pane - Shows your current code
• Right pane - Displays the new code
• Bottom pane - Displays what the automatic merge code looks like

You can select to accept the automatic merge or individually accept which code is merged or overridden.

Branching and merging

Finance and operations uses branching to isolate individual software assets, which allows you to work in parallel with other developers to increase productivity. Branching requires more effort to merge code. No defined rule exists for how branches are set up, but there's usually a Development, Test, and Production or Release branch. A Development branch is used for code that isn't ready for testing; however, it's shared between developers. Some larger teams might use multiple developer branches. The Test branch is used to hold changes that are ready to be tested by other users. The Production branch holds all the source code exactly as it's deployed in the production environment.

You must create a deployable package to move code changes from one environment to another. We recommend that you use a build environment to create deployable packages that contain all changes. You can create deployable packages from the development environment.

To create a deployable package, follow these steps:

1. Select Dynamics 365 > Deploy > Create Deployment Package.
2. Select the packages that contain your models.
3. Enter a location to create the deployable package.
4. After the deployable package is created, sign in to Lifecycle Services.
5. Go to your Lifecycle Services project.
6. Select Asset Library.
7. Upload the deployable package that you created.

To deploy a package to a nonproduction environment or a production environment, you use Lifecycle Services. The process to deploy the package differs between the two. Also, a deployment to a production environment requires the package to successfully deploy to at least one sandbox environment in the same project.

To deploy a package to a nonproduction environment, follow these steps:

1. Open the Environment details view for the desired environment.
2. Select Maintain > Apply updates.
3. Use the filter to select the package to apply.
4. Select Apply. The status in the upper-right corner of the Environment details view changes from Queued to In Progress.
5. When the package has been applied, the environment status changes to Deployed and the servicing status changes to Completed.

To deploy a package to a production environment, follow these steps:

1. Go to your project's asset library in Lifecycle Services.
2. On the Asset library page, select the Software deployable package tab, then select the package that you want to move to production,
3. Select Release candidate. This indicates that this package is ready for production deployment.
4. Select the package you wish to apply in your production environment, and then Select Schedule to submit a request to apply it.
5. Specify the date and time to schedule the package application.
6. Select Submit, and then select OK to confirm.
7. At the scheduled downtime, package deployment starts.
8. After the environment is serviced, you can monitor the status. The Servicing status field indicates the status of package application. Additionally, a progress indicator shows the number of steps that have been run, out of the total number of steps that are available.
9. After the deployment is successfully completed, the Servicing status field is set to Completed.

While the production environment is being updated, the environment is unavailable. You can monitor the Servicing status field to monitor the status of the package application. When the deployment is complete, the servicing status reads Completed. The deployable package has now been applied to the production environment.

To learn more, review these resources:

• Branching overview
• Version control, metadata search, and navigation
• Choose a branching strategy with a DevOps mindset