Overview
Azure DevOps Services is free for up to five users with access to Basic features and for unlimited Visual Studio subscribers and Stakeholders who can access limited features. Learn what else you get with Azure DevOps Services. If you want, you can also use Azure DevOps Services with any IDE or code editor, like the following examples: Eclipse, Android Studio, or IntelliJ; Xcode (see Git or TFVC) Visual Studio Code. You can use Azure directly from Visual Studio Code through extensions. Using either the Azure CLI or the Azure App Service extension, you can have your application running in Azure in minutes. Visual Studio Code Marketplace # There are many VS Code extensions on the Marketplace that make it easy to build and host applications on Azure.
Pull requests let your team give feedback on changes in feature branches before merging the code into the master branch. Reviewers can step through the proposed changes, leave comments, and vote to approve or reject the code. Azure DevOps provides a rich experience for creating, reviewing, and approving pull requests.
- Code resides on a centralized version control (TFVC) in earlier version of Team Foundation Server.
- I'm quiet new to C# and Azure functions and don't know how to properly implement this in my own project. I would really appreciate it if someone could guide me into the right direction. I am using Visual Studio with.NET Core 3.0 and Azure Functions. Here is the code so far.
It is required that you complete the Git lab prior to taking this lab.
Prerequisites
Visual Studio Code with the C# extension installed.
Azure Repos Extension for Visual Studio Code
This lab requires you to complete task 1 from the prerequisite instructions.
The Git lab is required to be completed as a prerequisite for this lab.
Exercise 1: Working with pull requests
When the Git lab ended, we had created a new branch and made a change to some of the code. Now we need to commit that change to the new branch and push it to the server. Once there, we can create a pull request so that the branch can be merged with the master.
Task 1: Creating a new pull request
Return to Visual Studio Code.
Select the Source Control tab. It should recognize that you have uncommitted changes to Category.cs. Enter a comment of “Category change” and press Ctrl+Enter to commit to the local release branch.
Click the Synchronize Changes button to push the commit to the server branch.
Press Ctrl|Shift+P to open the Command Palette.
Start typing “Team” and select Team: Create Pull Request when it becomes available. This will open a new pull request for the current branch in a new browser tab.
The New Pull Request form should already contain the key information reviewers will need, as well as who those reviewers should be (if any). If not, select release as the branch to merge into master.
You can customize any of this, and some of it may be required based on policy. Also note that the work item associated with the branch when created is referenced. Click Create.
Task 2: Managing pull requests
Return to Visual Studio Code.
Click the Browse your pull requests button at the bottom of the screen.
Select the pull request you just created. This will open it a new browser tab.
The Overview tab contains all of the key information specified in the creation form, as well as options to approve and complete the request.
Select the Files tab to review the files involved in the commit.
Note that you can select a specific update from the dropdown if you like.
Click the Add comment button next to the source file. Enter a comment using markdown and click Comment to save it. Note that there is a live preview of your comment before you commit to it.
The new comment is placed in line with the code. This makes it very easy to have discussions about lines and sections of code within their proper context.
The new comment is also tracked as part of the pull request. It’s expected that every comment will be resolved before a pull request will be completed, so this convenient marker lets you know if there’s anything else that needs to be reviewed.
Update the comment to mark it as Resolved.
Note that this now updates the tracking as well.
Select the Updates tab. This contains details on the updates in the branch.
Select the Commits tab, where you can review the commits made to the branch.
Since everything seems to be in order, Approve the pull request.
Since the approvers have signed off, Complete the pull request.
You can accept the default messages in the pull request dialog. The first option is to complete the work items linked to the branch being merged. Note that you also have the option to delete the target branch after merging, as well as the ability to squash changes during the merge. Squash merging is a merge option that allows you to condense the Git history of topic branches when you complete a pull request. Instead of each commit on the topic branch being added to the history of the default branch, a squash merge takes all the file changes and adds them to a single new commit on the default branch. Squash merging keeps your default branch histories clean and easy to follow without demanding any workflow changes on your team. Click Complete merge.
When the merge completes, the pull request should be marked as Completed.
Return to the Pull Requests home.
Select the Completed tab and click the pull request as though you were visiting it fresh.
You can review the pull request, as well as Cherry-pick or Revert it if needed. Cherry-picking is the process of selecting specific commits from one branch to apply to another, conceptually similar to a copy/paste operation.
Under Work Items, click one of the linked work items.
Note that the work item has now been marked as Done.
Under the Development tab, you can see the commit and pull request have been associated with the work item.
Task 3: Managing Git branch and pull request policies
As projects and teams scale in complexity, it becomes help to automate more of the processes put in place to ensure quality.
Open Project settings.
Select Repositories under Repos.
Select the PartsUnlimited repo. Like everything else in Azure DevOps, you can manage security to a great level of detail. Select the Options tab. This allows you to set some useful policies, such as whether or not you want to allow users to fork the repo, whether discussed work items are automatically linked, and so on.
Select the master branch. Like the repo, you have a great deal of control over its security settings. You can also define a wide variety of policies for the branch to enforce. Click Branch Policies.
Azure DevOps branch policies are very effective in enforcing a level of quality control in the repo. For example, you can control pull requests by requiring a minimum number of reviewers, checking for linked work items, requiring that all comments have been resolved, and more. You can even require validation through a successful build and configure external approval services. If there are certain sections of code that require their own approvers to be included, you can include them here as well.
Check Require a minimum number of reviewers. By default, this requires at least two reviewers to approve a pull request, and also requires (by default) that the original author is not one of them.
Click Add automatic reviewers.
Add yourself as a Reviewer and set the Path filter to “/PartsUnlimited-aspnet45/src/PartsUnlimitedWebsite/Controllers/*“. Having the requirement of Required ensures that you will be required to sign off on any changes proposed to the controllers code in the web app. Click Save.
Click Save changes to save the changes to the policy.
Overview
Azure DevOps supports two types of version control, Git and Team Foundation Version Control (TFVC). Here is a quick overview of the two version control systems:
Team Foundation Version Control (TFVC): TFVC is a centralized version control system. Typically, team members have only one version of each file on their dev machines. Historical data is maintained only on the server. Branches are path-based and created on the server.
Git: Git is a distributed version control system. Git repositories can live locally (such as on a developer’s machine). Each developer has a copy of the source repository on their dev machine. Developers can commit each set of changes on their dev machine and perform version control operations such as history and compare without a network connection.
Git is the default version control provider for new projects. You should use Git for version control in your projects unless you have a specific need for centralized version control features in TFVC.
In this lab, you will learn how to establish a local Git repository, which can easily be synchronized with a centralized Git repository in Azure DevOps. In addition, you will learn about Git branching and merging support. You will use Visual Studio Code, but the same processes apply for using any Git-compatible client with Azure DevOps.
Prerequisites
Visual Studio Code with the C# extension installed.
Git for Windows 2.21.0 or later.
This lab requires you to complete task 1 from the prerequisite instructions (Skip cloning, it is done in the exercise).
Exercise 1: Configuring the lab environment
Task 1: Configuring Visual Studio Code
Open Visual Studio Code. In this task, you will configure a Git credential helper to securely store the Git credentials used to communicate with Azure DevOps. If you have already configured a credential helper and Git identity, you can skip to the next task.
From the main menu, select Terminal | New Terminal to open a terminal window.
Execute the command below to configure a credential helper.
The commands below will configure your user name and email for Git commits. Replace the parameters with your preferred user name and email and execute them.
Exercise 2: Cloning an existing repository
Task 1: Cloning an existing repository
In a browser tab, navigate to your team project on Azure DevOps.
Getting a local copy of a Git repo is called “cloning”. Every mainstream development tool supports this and will be able to connect to Azure Repos to pull down the latest source to work with. Navigate to the Repos hub.
Click Clone.
Click the Copy to clipboard button next to the repo clone URL. You can plug this URL into any Git-compatible tool to get a copy of the codebase.
Open an instance of Visual Studio Code.
Press Ctrl+Shift+P to show the Command Palette. The Command Palette provides an easy and convenient way to access a wide variety of tasks, including those provided by 3rd party extensions.
Execute the Git: Clone command. It may help to type “Git” to bring it to the shortlist.
Paste in the URL to your repo and press Enter.
Select a local path to clone the repo to.
When prompted, log in to your Azure DevOps account.
Once the cloning has completed, click Open to open the cloned repository. You can ignore any warnings raised about opening the projects. The solution may not be in a buildable state, but that’s okay since we’re going to focus on working with Git and building the project itself is not necessary.
Exercise 3: Saving work with commits
When you make changes to your files, Git will record the changes in the local repository. You can select the changes that you want to commit by staging the changes. Commits are always made against your local Git repository, so you don’t have to worry about the commit being perfect or ready to share with others. You can make more commits as you continue to work and push the changes to others when they are ready to be shared.
What’s in a commit?
Git commits consists of the following:
The file(s) changed in the commit. Git keeps the contents of all file changes in your repo in the commits. This keeps it fast and allows intelligent merging.
A reference to the parent commit(s). Git manages your code history using these references.
A message describing a commit. You give this message to Git when you create the commit. It’s a good idea to keep this message descriptive, but to the point.
Task 1: Committing changes
From the Explorer tab, open /PartsUnlimited-aspnet45/src/PartsUnlimitedWebsite/Models/CartItem.cs.
Add a comment to the file. It doesn’t really matter what the comment is since the goal is just to make a change. Press Ctrl+S to save the file.
Select the Source Control tab to see the one change to the solution.
Enter a commit message of “My commit” and press Ctrl+Enter to commit it locally.
If asked whether you would like to automatically stage your changes and commit them directly, click Always. We will discuss staging later in the lab.
Click the Synchronize Changes button to synchronize your changes with the server. Confirm the sync if prompted.
Task 2: Reviewing commits
Switch to the Azure DevOps browser tab. You can review the latest commits on Azure DevOps under the Commits tab of the Repos hub.
The recent commit should be right at the top.
Azure Devops Vs Code Extension
Task 3: Staging changes
Staging changes allows you to selectively add certain files to a commit while passing over the changes made in other files.
Return to Visual Studio Code.
Update the open CartItem.cs class by editing the comment you made earlier and saving the file.
Open Category.cs as well.
Add a new comment to Category.cs so there will be two files with changes. Save the file.
From the Source Control tab, click the Stage Changes button for CartItem.cs.
This will prepare CartItem.cs for committing without Category.cs.
Enter a comment of “Added comments”. From the More Actions dropdown, select Commit Staged.
Click the Synchronize Changes button to synchronize the committed changes with the server. Note that since only the staged changes were committed, the other changes are still pending locally.
Exercise 4: Reviewing history
Git uses the parent reference information stored in each commit to manage a full history of your development. You can easily review this commit history to find out when file changes were made and determine differences between versions of your code using the terminal or from one of the many Visual Studio Code extensions available. You can also review changes using the Azure DevOps portal.
Git’s use of the Branches and Merges feature works through pull requests, so the commit history of your development doesn’t necessarily form a straight, chronological line. When you use history to compare versions, think in terms of file changes between two commits instead of file changes between two points in time. A recent change to a file in the master branch may have come from a commit created two weeks ago in a feature branch but was only merged yesterday.
Task 1: Comparing files
In the Source Control tab, select Category.cs.
A comparison view is opened to enable you to easily locate the changes you’ve made. In this case, it’s just the one comment.
Go to the Commits view in Azure DevOps to locate some of the source branches and merges. These provide a convenient way to visualize when and how changes were made to the source.
From the dropdown for Merged PR 27, select Browse Files.
This view offers the ability to navigate around the state of the source at that commit so you can review and download those files.
Exercise 5: Working with branches
You can manage the work in your Azure DevOps Git repo from the Branches view on the web. You can also customize the view to track the branches you care most about so you can stay on top of changes made by your team.
Link Visual Studio To Azure
Committing changes to a branch will not affect other branches and you can share branches with others without having to merge the changes into the main project. You can also create new branches to isolate changes for a feature or a bug fix from your master branch and other work. Since the branches are lightweight, switching between branches is quick and easy. Git does not create multiple copies of your source when working with branches, but rather uses the history information stored in commits to recreate the files on a branch when you start working on it. Your Git workflow should create and use branches for managing features and bugfixes. The rest of the Git workflow, such as sharing code and reviewing code with pull requests, all work through branches. Isolating work in branches makes it very simple to change what you are working on by simply changing your current branch.
Task 1: Creating a new branch in your local repository
Return to Visual Studio Code.
Click the master branch from the bottom left.
Select Create new branch from….
Enter the name “dev” for the new branch and press Enter.
Select the master as the reference branch.
You are now working on that branch.
Task 2: Working with branches
Git keeps track of which branch you are working on and makes sure that when you checkout a branch your files match the most recent commit on the branch. Branches let you work with multiple versions of the source code in the same local Git repository at the same time. You can use Visual Studio Code to publish, check out and delete branches.
Click the Publish changes button next to the branch.
From the Azure DevOps browser tab, select Branches.
You should see the newly pushed dev branch. Click on more actions drop down and Select the Delete branch button to delete it. Confirm the delete.
Return to Visual Studio Code.
Click the dev branch.
Note that there are two dev branches listed. The local (dev) branch is there because it’s not deleted when the server branch is deleted. The server (origin/dev) is there because it hasn’t been pruned. Select the master branch to check it out.
Press Ctrl+Shift+P to open the Command Palette.
Start typing “Git: Delete” and select Git: Delete Branch when it becomes visible.
There is only one local branch to delete, so select it.
Click the master branch.
Note that the local dev branch is gone, but the remote origin/dev is still showing.
Press Ctrl+Shift+P to open the Command Palette.
Start typing “Git: Fetch” and select Git: Fetch (Prune) when it becomes visible. This command will update the origin branches in the local snapshot and delete those that are no longer there.
You can check in on exactly what these tasks are doing by selecting the Output window at the bottom of the screen.
Note that if you don’t see the Git logs in the output console, you may need to select Git as the source.
Click the master branch.
The origin/dev branch should no longer be in the list.
Exercise 6: Managing branches from Azure DevOps
In addition to all the functionality available in Visual Studio Code, you can also manage your repo branches from the Azure DevOps portal.
Task 1: Creating a new branch
Switch to the Azure DevOps browser tab.
Navigate to Repos | Branches. Click New branch.
Enter a name of “release” for the new branch. Use the Work items to link dropdown to select one or more work items to link to this new branch. Click Create branch to create it.
After the branch has been created, it will be available in the list.
Return to Visual Studio Code.
Press Ctrl+Shift+P to open the Command Palette.
Start typing “Git: Fetch” and select Git: Fetch when it becomes visible. This command will update the origin branches in the local snapshot.
Click the master branch.
Select origin/release. This will create a new local branch called “release” and check it out.
Task 2: Deleting a branch
Return to Azure DevOps and click the Delete branch from the more actions drop down to delete it.
You can Restore branch if you want by searching for an exact branch name. Select Restore branch as shown below.
Task 3: Locking a branch
Locking is ideal for preventing new changes that might conflict with an important merge or to place a branch into a read-only state. Alternatively, you can use branch policies and pull requests instead of locking if you just want to ensure that changes in a branch are reviewed before they are merged.
Locking does not prevent cloning of a repo or fetching updates made in the branch into your local repo. If you lock a branch, share with your team the reason why and make sure they know what to do to work with the branch after it is unlocked.
From the master context menu, select Lock.
Alerts daemon mac. The branch is now locked.
Now Unlock the branch using the same process.
Task 4: Tagging a release
While it may not seem like much, the product team has decided that this version of the site is exactly what’s needed for v1.1. In order to mark it as such, navigate to the Tags tab. Simulation 3d software.
Click Create Tag.
Enter a name of “v1.1” and a Description of “Great release!”. Click Create.
You have now tagged the project at this release. You could tag commits for a variety of reasons and Azure DevOps offers the flexibility to edit and delete them, as well as manage their permissions.
## ##
Exercise 7: Managing repositories
You can create Git repos in team projects to manage your project’s source code. Each Git repo has its own set of permissions and branches to isolate itself from other work in your project.
Task 1: Creating a new repo from Azure DevOps
From the project Add dropdown, select New repository.
Set the Repository name to “New Repo”. Note that you also have the option to create a file named README.md. This would be the default markdown file that is rendered when someone navigates to the repo root in a browser. Additionally, you can preconfigure the repo with a .gitignore file. This file specifies which files, based on naming pattern and/or path, to ignore from source control. There are multiple templates available that include the common patterns and paths to ignore based on the project type you are creating. Click Create.
That’s it. Your repo is ready. You can now clone it with Visual Studio or your tools of choice.
Task 2: Deleting and renaming Git repos
Sometimes you’ll have a need to rename or delete a repo, which is just as easy. Open Project settings.
Select Repositories under Repos.
From the New Repo context menu, select Delete repository. Alternatively, you could rename it here.
Enter the name “New Repo” to confirm the repo and click Delete.