©  Ambily K K 2020
A. K KAzure DevOps for Web Developershttps://doi.org/10.1007/978-1-4842-6412-6_4

4. Version Control Using Azure DevOps

Ambily K K1  
(1)
Hyderabad, India
 

The versioning of code is important in a DevOps implementation. Version control systems enable you to collaborate with team members by tracking and controlling changes within your code. Most version control systems provide the basic features required for working with team members in parallel on the same codebase or file. These features include versioning code, rolling back to previous versions, comparing versions to identify the changes, and so on.

This chapter focuses on version control systems, branching and merging strategies, and the associated functionalities.

Repos

Repositories define the source code management component of Azure DevOps. You can configure multiple repositories in a team project to manage the different source code related to a project. For example, a team can plan for a repo for the UI application and have another repo for API development.

Once created, this new repo will be empty. Initializing a README file is an optional step but industry best practice, as shown in Figure 4-1. The README file helps the reader to understand the usage of the project, language, and steps required for project setup.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig1_HTML.jpg
Figure 4-1

Initial repo setup

The team can set up the repo by importing an existing repo from another repository directly or by pushing an existing project from a system using the command line.

The following are the steps used to push the existing codebase from a local system:
  1. 1.

    Open a command prompt (Start ➤ cmd).

     
  2. 2.

    Navigate to the folder containing the source code of the project.

    Git should be installed before cloning or pushing the Git repository. Download Git from https://git-scm.com/download/win and install it to proceed.

     
  3. 3.

    Initialize the Git repository using this:

    git init
     
  4. 4.
    Once the repository is initialized, link the local Git setup to the Azure “remote” repo so they can communicate, by adding origin to the git remote command.
    git remote add origin https://[email protected]/authorambily/SampleProject/_git/SampleProject
     
  5. 5.

    Once the repo is linked with Azure DevOps, push the existing code from the local version to the remote version using the git push command. You will see the code in the Azure repository called SampleProject.

    git push -u origin –all

    This may prompt you to provide your Azure DevOps credentials to continue.

     
  6. 6.

    If you get the following error message, set up the branch corresponding to our repo.

    No refs in common and none specified; doing nothing.

    Perhaps you should specify a branch such as 'master'.

    Everything up-to-date

    To fix the previous error, clone the Azure DevOps repository again using the git clone command.
    git clone https://[email protected]/authorambily/SampleProject/_git/SampleProject
     
  7. 7.

    Navigate to our project folder using cd SampleProject.

     
  8. 8.

    Set the username and password, if they’re not detected automatically, using the Git global settings commands.

    git config --global user.email [email protected]
    git config --global user,name "Ambily"
     
  9. 9.

    Add the existing content to the local Git repository using this:

    git add .
     
  10. 10.

    Once the content is added, commit the changes to the local repository using this command:

    git commit -m "first file update"
     
  11. 11.

    Once the local codebase is ready to be merged with the centralized repository, push the code using the git push command.

    git push
     
Observe the merged codebase in Azure DevOps along with the change commands, as shown in Figure 4-2.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig2_HTML.jpg
Figure 4-2

Repo files

The user can do minimum changes in the browser itself. The browser-based code editor supports a minimum level of IntelliSense, as shown in Figure 4-3.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig3_HTML.jpg
Figure 4-3

Changes using the browser editor

Branching and Merging

Before proceeding, let’s explore the concepts associated with repos and branches. By default, every repo will have one branch associated with it: the master. As per industry practices, the master branch code should be the same as the code released to production. Developers will work in a separate branch created from the master, normally called the dev branch. Based on the branching and merging policy of the organization, the number and names of branches will vary. For example, some organizations use a separate branch called the release branch for deployment to production.

Branching strategies and merging should be defined and documented to control the release activities associated with the project. Along with branching and merging, tags can be used to track intermediate patch releases and hotfixes.

Branching allows the following:

  • The development team to work parallel in different features

  • Multiple teams like production support and developers to work independently

  • Proper control on release management

You can create branches from any existing branch, unless protected by policy. As shown in Figure 4-4, in a normal project setup, there will be one master branch and a dev branch along with other feature development branches, if required. Developers clone the repository along with a branch to the local system to implement the features. Once cloned, updates from the remote repository will be pulled to the local repository and merged with the local changes. After the code implementation, the developer pushes the code back to the remote repository. Branches will be merged into the master branch or parent branch using pull requests (PRs).
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig4_HTML.jpg
Figure 4-4

Branch, push, and pull

It is recommended that developers push the code to the remote repository every day to avoid a lot of conflicts as part of the merge changes. But, in some cases, developers will continue to work on the local copy for a longer duration or work offline in local Git branches to complete the implementation of the feature. Once the feature implementation is completed, the developers will push the changes to the remote repository. Developers use different branches in the local Git setup to manage the codebase and feature implementations. For example, the developer working on a feature may need to work on a production bug as part of a hotfix. In this case, the developer can configure a different branch to handle the requirement and bug fixes.

Microsoft’s recommendation on a branching strategy is available at https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops.

Project Repo

Project repos in Azure DevOps provide a set of features to manage the repo efficiently. Figure 4-5 shows the options available at the repo level.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig5_HTML.jpg
Figure 4-5

Options at the repo level

  • Clone: This option allows you to clone the repo into the local system using HTTPS or SSH. Also, it provides an option to open the repository directly in Visual Studio.

  • Fork: This allows you to create a copy of the existing repository in a current or different project.

  • New: This option allows you to add new files and folders directly into the repo through the browser.

  • Upload file(s): This uploads one or more files from the local system to the Azure repo.

  • Download as Zip: This downloads the repository as a zip folder to the local system.

  • Hide files tree: This hides the file tree to get more screen space for the files list.

Other options available for each file listed in the file tree are Edit, Rename, Delete, and Download.

The History tab lists the changes or commits to the current repo under the selected branch, as shown in Figure 4-6. Also, this tab provides the option to filter the data based on the different views, author, and from and to dates. Every commit captures the merge operation through the Graph column and lists other details in the Commit column.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig6_HTML.jpg
Figure 4-6

File history

Click the Commit entry to navigate to the files committed as part of the commit and to view the changes in each file level, as shown in Figure 4-7. New lines or code added as part of the commit will be highlighted in green, whereas the deleted lines will be highlighted in red.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig7_HTML.jpg
Figure 4-7

Commit history

There are number of filtering options available on top of the changes to drill down to the changes. Moreover, there is an option (../images/501036_1_En_4_Chapter/501036_1_En_4_Figa_HTML.jpg) at the top right to add a global comment to the commit. This option can be used to provide review comments or changes to the commit.

Branch and Tags

Based on the branching and merging strategy, new branches will be created from a remote existing branch. Moreover, the user can use a tag to mark the current codebase with a label, which can be referred to later to get a snapshot of the codebase at that particular time. Tags are useful for versioning the code into specific points in the commit history. Once tagged, the same codebase can be retrieved using the tag in the future. For example, tags created as part of the QA releases can be used for debugging and reproducing bugs that are not shown in the latest codebase. See Figure 4-8.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig8_HTML.jpg
Figure 4-8

Branch and tag options

Create a new branch using the “New branch” option available in the branch menu, as shown in Figure 4-8. Provide a name for the new branch along with the base branch; the base branch will be your parent branch. See Figure 4-9.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig9_HTML.jpg
Figure 4-9

Creating a new branch

Moreover, the system allows you to link one or more work items to the new branch, as shown in Figure 4-9. If your branching policy is to create a new branch for each feature, then link the new feature to the new branch.

Similarly, you can add repositories using the “New repository” option available next to the existing repository, as shown in Figure 4-10.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig10_HTML.jpg
Figure 4-10

Creating a new repo

The “Manage repositories” option takes the user to Project settings ➤ repositories, which we discussed in Chapter 2. The “Import repository” options allows you to clone or import repositories from other systems such as GitHub or from another organization or project.

Commits

The Commits section shows the commit history with filters and options to drill down further, as shown in Figure 4-11.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig11_HTML.jpg
Figure 4-11

Commits section

Using the Graph option on the top, the user can toggle the commit graph. The user can search using the commit ID, if available. Click the commit to view the files and associated changes.

In addition to navigating through and understanding the changes, there are two important operations on the commit details page, Cherry-pick and Revert, as shown in Figure 4-12.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig12_HTML.jpg
Figure 4-12

Commit details

  • Cherry-pick: Git’s cherry-pick operation is for applying the changes to a different branch that is not the parent of the current branch. For example, if you have made some changes in a release branch as part of a production issue fix and want to apply it in a feature branch, you can cherry-pick the commit from the release branch and apply it directly to the feature branch. The system will not apply the change directly to the feature branch; instead, it creates a new branch out of the feature branch, applies the new commit, and asks for a pull request to merge it to a feature branch. This way, Azure DevOps protects the feature branch codebase from any unwanted cherry-pick merges. Pull requests can be further enhanced by multiple code reviewers or approvals.

  • Revert: This option reverts the changes done as part of this commit operation. The Revert operation also creates a new branch from the current branch without the selected commit and asks the user to create a pull request to merge it back.

Pushes

The Pushes section shows the list of commits pushed to the remote repository (see Figure 4-13). Each push may have one or more commits done on the local repository. Commits are done in the local repository to track the changes locally. A set of commits associated with a task or feature implementation will be pushed and will get merged to the remote repository.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig13_HTML.jpg
Figure 4-13

Pushes

In Figure 4-13, there are two pushes; one has one commit, and the other has two. The user can click the push item and view the changed files and corresponding changes. As discussed in the “Commits” section, you can revert the change, cherry-pick the commits, or create a new branch from the change.

Moreover, the Pushes view provides an option to raise a pull request to merge the commits with another branch. We will look at pull requests in the next section.

Branches

This section lists all the branches associated with the selected repo and related options. Branches are grouped under Mine, All, and Stale.

  • Mine: This lists all the branches created by the user.

  • All: This lists all the branches related to the repo.

  • Stale: This lists the branches without any commit or activities in the last three or more months. This will help in tracking the unused repos and remove them. See Figure 4-14.

../images/501036_1_En_4_Chapter/501036_1_En_4_Fig14_HTML.jpg
Figure 4-14

Branches and options

Along with the branch names, these other details are displayed: the last commit, who authored the commit, the date of the commit, and the pull request details. Moreover, the user can view the branch status with respect to the master branch; the Ahead data shows the number of commits that have not been merged with the master branch or parent branch, and Behind shows the number of commits that need to be merged into this branch. The “Add to favorite” option is available for each branch so the user can select a favorite branch.

The other options, as shown in Figure 4-14, are as follows:

  • New Branch: This creates a new branch based on the existing branch.

  • New pull request: This creates a new pull request to merge the changes with another branch.

  • Delete Branch: This deletes the branch.

  • View files: This lets you view files associated with the branch.

  • View history: This lets you view the commit history.

  • Compare branches: This compares two branches.

  • Set as compare branch: This marks one base branch for comparison.

  • Set as default branch: This sets the default branch.

  • Lock: This locks the branch and prevents any updates to the commit history or any new updates from others. Only the locked user will be able to perform activities on the branch. This feature can be used to freeze a feature branch to complete the feature implementation.

  • Branch policies: This defines the branch policies using Project settings ➤ repositories ➤ branch, as discussed in Chapter 2.

  • Branch security: This defines the branch security corresponding to each group and users. This option also allows you to receive an email with a detailed report about the branch security.

Tags

The Tags section shows the set of tags and related options, as shown in Figure 4-15. Tagging helps to version the codebase to a specific commit and as required extract the tagged codebase for multiple purposes. We can use the git checkout command and tag name as parameters.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig15_HTML.jpg
Figure 4-15

Tags

The options available are as follows:

  • New Branch: This creates a new branch out of the tag.

  • Download as Zip: This downloads the tagged codebase as a zip file.

  • View files: This allows you to view the files marked with this tag.

  • View history: This makes the history of the codebase tagged using the specified tag.

  • Delete tag: This deletes the existing tag.

  • Set as compare tag: This uses the tag as a base tag for comparison.

Pull Requests

The “Pull requests” section lists all the pull requests and options to create new pull requests, as shown in Figure 4-16. Pull requests are grouped under Mine, Active, Completed, and Abandoned.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig16_HTML.jpg
Figure 4-16

Pull requests

Select “New pull request” to create a pull request to merge the changes from any of the branches to the master or to another branch, as shown in Figure 4-17.

In Figure 4-17, the source branch is set to dev, and the target branch is the master, indicating that the commits from the dev branch will be merged into the master branch. Provide a title and description to refer to the pull request later. If the PR requires reviewers, add them to review the codebase before merging with the other branch. If it is mandatory that a certain person reviews the codebase, add the person as a required reviewer by using the link “Add required reviewers.” The user has an option to link to one or more work items to establish the traceability of the implementation. Also, the user can add a few tags to tag the PR.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig17_HTML.jpg
Figure 4-17

New pull request

Once the PR is created, reviewers can view it and select Approve. The user can select Set auto-complete, Complete, or Abandon for the PR based on the review.

In Figure 4-18, there are no required reviewers, so any team member with access can complete the PR and merge the changes to the target branch.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig18_HTML.jpg
Figure 4-18

Pull request: approval

Figure 4-19 shows another set of options available as part of the PR to process.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig19_HTML.jpg
Figure 4-19

Pull request options

  • Share pull request: This allows you to share the PR over email. This option helps you share additional information with reviewers, if required.

  • Save all comments: Review comments are added in the PR for tracking. By default the comments appear as Active with edit, delete, and like options, as shown in Figure 4-20. Users can respond to the comments or mark them with a status such as Pending, Resolved, Won’t fix, and Closed.
    ../images/501036_1_En_4_Chapter/501036_1_En_4_Fig20_HTML.jpg
    Figure 4-20

    Pull request comments

  • Disable live updates: This disables the live updates.

  • Follow: Follow the PR to get notified on new comments and activities.

  • View merge changes: View the changes after the merge.

  • Restart merge: Restart the merge operation based on the fixes done by the developer to incorporate the review comments.

  • Change target branch: Change the target branch.

  • Cherry-pick: Cherry-pick the changes to another branch.

On the “Complete pull request” screen, select the different merge options supported by Azure DevOps, as shown in Figure 4-21.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig21_HTML.jpg
Figure 4-21

Pull request: merge options

  • Merge (default): This merges the codebase along with all the commits.

  • Squash commit: This merges the codebase as a single commit to target branch. In this case, the target branch is not aware of the commits that happened to the source branch and isn’t tracking the commit comments.

  • Rebase and fast-forward: This merges the target changes to the source and rebases the target from the source and fast-forwards it.

  • Semi-linear merge: This rebases the source commits onto the target and merges the two parents.

Working with Visual Studio

Most of the developers using the Microsoft technology stack for development use Visual Studio for development activities. To connect Visual Studio to Azure DevOps, open the Team Explorer using the menu View ➤ Team Explorer. Once the Team Explorer is opened, select Projects ➤ Manage Connections, as shown in Figure 4-22.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig22_HTML.jpg
Figure 4-22

Team Explorer

This will show the Manage Connections menu with two options, Hosted Service Providers and Local Git Repositories, as shown in Figure 4-23.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig23_HTML.jpg
Figure 4-23

Team Explorer, Manage Connections menu

Click the Connect link under Azure DevOps to connect to the DevOps repo that is configured. The system will prompt you for your DevOps credentials to connect to the respective organizations. Once the credentials are validated, the system will populate all the organizations where the user has access to connect.

Select the repo to proceed, as shown in Figure 4-24.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig24_HTML.jpg
Figure 4-24

Connecting to a project

Visual Studio will establish a connection to the selected repo and provide all the services associated with the repo to the developer to perform from within Visual Studio. See Figure 4-25.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig25_HTML.jpg
Figure 4-25

Azure DevOps operations

All the operations discussed with source code can be performed directly within Visual Studio, as shown in Figure 4-25. For example, select Branches to view the options associated with the branch and the list of existing branches. See Figure 4-26.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig26_HTML.jpg
Figure 4-26

Team Explorer, Branches

The New Branch option helps in creating a new branch, whereas Merge allows you to merge the code from two branches. Rebase will override the existing branch code with the selected branch. Figure 4-26 shows these branch-related options.

Navigate to the Changes section to configure the username and email for committing the changes to the repo. Perform a commit and push of the codebase from the local repo to the Azure DevOps repo. In a remote execution mode, there are four methods: pull, push, fetch, and sync. Figure 4-27 shows all the options related to change tracking.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig27_HTML.jpg
Figure 4-27

Team Explorer, Synchronization menu

  • Fetch: This fetches the remote changes but does not apply them to any local branch. After selecting Fetch, invoke Merge to merge the remote changes with the local repo.

  • Pull: This is a combination of Fetch and Merge, where the system gets the changes from the remote repo and merges them with the local copy.

  • Push: This pushes the local changes to the remote server.

  • Sync: This is again a combination of Pull and Push, where the system pulls the remote changes and pushes the local changes back.

Commit is another activity that can be confusing for developers. Commit will mark the local repo with a new change and version the changes. Commit will not impact the remote repository. Commits are used to protect the local changes in a version control system. Once the codebase is ready to be merged with the remote repository or with the code changes of other developers, then use any of the previously discussed methods to merge the changes with the centralized repository. Figure 4-28 shows the different Git operations.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig28_HTML.jpg
Figure 4-28

Git operations

Working with Visual Studio Code

To connect Visual Studio Code with Azure DevOps, install the Azure Repo extension from Extensions, as shown in Figure 4-29.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig29_HTML.jpg
Figure 4-29

Azure Repo extensions

Once it’s installed, ensure that the system has been set up with the TFVC command-line client (TF.exe). If the user has the Visual Studio Community edition, TF.exe will be available in C:Program Files (x86)Microsoft Visual Studio2019CommunityCommon7IDECommonExtensionsMicrosoftTeamFoundationTeam Explorer f.exe. Set this location to the tfvc.location setting under VS Code Settings, as shown in Figure 4-30.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig30_HTML.jpg
Figure 4-30

TFVC location

Now, select the Team option in the status bar of VS Code, as shown in Figure 4-31, to connect to Azure DevOps.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig31_HTML.jpg
Figure 4-31

VS Code status bar

You have two options to connect with Azure DevOps; either provide the access token or follow the instructions to connect and generate the token, as shown in Figure 4-32.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig32_HTML.jpg
Figure 4-32

Azure DevOps connect options

Follow the steps to connect to Azure DevOps. Note that this extension or TFVC support is limited to local workspaces. This option supports local branch management and also has direct integration with the Azure DevOps servers.

Working with Git Bash

Git Bash is similar to the standard command prompt, where Git commands can be executed. Along with Git command support, Git Bash has a wrapper over the standard command line and supports Linux commands. If you are from a Linux background and want to use similar commands, then use Git Bash to manage the Git repos.

Some of the Git commands used for managing the repo are discussed at the beginning of this chapter. A few of the most useful branch-related Git commands are as follows:

  • Use this command to list the branches available:

    git branch
    or
    git branch -a
The first command will list all the remote branches, whereas the second command will list the remote and local branches available, as shown in Figure 4-33.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig33_HTML.jpg
Figure 4-33

Git branches

  • Use this command to change to another branch:

    git switch <<branch>>

  • Use this command to check out a branch:

    git checkout <<branch>>

  • Use this command to show the status of the working branch:

    git status

Sample Application

We have discussed the various version control features offered by the Azure DevOps service. Let’s explore these features through a web application developed using Angular and the .NET Web API, as shown in Figure 4-34.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig34_HTML.jpg
Figure 4-34

Sample app

The Angular development will be done using the Visual Studio Code IDE, and the .NET API will use Visual Studio as the integrated development environment (IDE). SQL Server database can also be added to the source repo using the database project templates available in Visual Studio.

Version Controlling an Angular App

As mentioned, the Angular development will be done using a Visual Studio Code IDE. As of now, this IDE will not support direct integration with the Azure DevOps service. Follow these steps to add the Angular app into the Azure DevOps service:
  1. 1.

    Create a team project in the Azure DevOps service using Git as the version control system.

     
  2. 2.

    Configure a repo for adding an Angular app.

     
  3. 3.
    Clone the empty repo to the local system using the git clone command.
    git clone https://[email protected]/authorambily/SampleApp/_git/angularapp
     
Note

Instead, you can push an existing repository from your system using the following:

git remote add origin https://[email protected]/authorambily/SampleApp/_git/angularapp
git push -u origin –all
  1. 4.

    Navigate to the newly created repo, as shown here:

    cd angularapp
     
  2. 5.

    Create a new Angular app using ng, as shown here:

    ng new <<appname>>
     
  3. 6.

    Add all the newly created files into Git using the following:

    git add .
     
  4. 7.

    Commit the newly added files or changes, as shown here:

    git commit -m "first version"
     
  5. 8.

    Push the changes to the remote repo, as shown here:

    git push
     
Note

If the repo was initiated with ReadMe.md, then do a pull before push, as shown here:

git pull
The first version of the Angular app is updated to the remote repository. The first commit will be done in the master branch, which get created along with the repo creation. Any further changes or modifications will be done in a separate branch such as the dev or feature branches. Follow these steps to update the Angular app:

  • Create the dev branch from the master branch, using the Azure DevOps portal.

  • Check out the dev branch.

    git checkout dev
Note

This may lead to the following error:

error: pathspec 'dev' did not match any file(s) known to git

This is due to the new branch being added to the remote repo. Pull the newly added branch details before checkout the same as when using the git pull command.
git pull
git checkout dev

  • Verify the branch.

    git branch

  • Modify the application to implement a feature or bug fixes.

  • Commit the changes properly to the local repository. to stage the changes

    git add .
    git commit -m "commit comment"

  • Once the implementation completes, push to the remote repository.

    git push origin dev
Based on the remote repo modifications and local updates, there may be scenarios where merge conflicts can happen, which the system tries to resolve using the default merge strategy. If it fails to resolve the conflicts, it shows the following kind of error in git push:
To resolve this, pull the changes using git pull. This brings the remote changes to the local version and displays both the changes in Visual Studio Code along with options to resolve them, as shown in Figure 4-35.
../images/501036_1_En_4_Chapter/501036_1_En_4_Fig35_HTML.jpg
Figure 4-35

Merging conflicts

  • Accept Current Change: This option accepts the local changes.

  • Accept Incoming Change: This option accepts the remote changes.

  • Accept Both Changes: This option accepts the remote as well as local changes.

  • Compare Changes: This option compares the changes and makes a decision manually.

Another way to merge the conflicting changes is to use the git merge command.
git merge -s <<strategy>>
git merge -s ours

Refer to the merge strategies at https://git-scm.com/docs/merge-strategies to understand the different strategies and their usage.

Version Controlling the .NET API

APIs or the middle layer of an application will be developed using any of the IDEs such as Eclipse or Visual Studio. .NET APIs are generally developed using Visual Studio, which supports direct integration with Azure DevOps. Refer to the section “Working with Visual Studio” to version control the .NET API using Azure DevOps and VS.

Summary

Version control and branching strategies define the development and release management of a project. Based on the branching strategy, the team works on different branches in parallel to complete the development, production support, and feature releases. The build and release setups are also dependent on the way the version control management system is configured with the branching strategies.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.212.145