- Visual Studio Code Azure Devops Repository
- Visual Studio Code Azure Devops Integration
- Azure Repos Extension For Visual Studio Code
- Visual Studio Code Azure Devops Repo
- Browse other questions tagged git visual-studio azure-devops or ask your own question. The Overflow Blog Podcast 331: One in four visitors to Stack Overflow copies code.
- And after the initial connection is established, Visual Studio remembers it so that it auto-connects the next time you open the repository. Info bar to establish initial connection to Azure DevOps project. By default, whenever you open a repository, Visual Studio loads the associated solution/folder in Solution Explorer.
- Azure DevOps - Services for teams to share code, track work, and ship software. Visual Studio - State-of-the-art tools and services that you can use to create great apps for devices, the cloud, and everything in.
- Visual Studio Code A powerful, lightweight code editor for cloud development GitHub and Azure World’s leading developer platform, seamlessly integrated with Azure Visual Studio Subscriptions Access Visual Studio, Azure credits, Azure DevOps and many other resources for.
Overview
Initiate pull requests directly from Visual Studio. Connect to your Project from Visual Studio. Select View Team Explorer to open Team Explorer. You can also select Ctrl+ then Ctrl+m. Select Home, then choose Pull Requests. Select New Pull Request to open up a web browser where you can create the new pull request in the Azure DevOps Services web portal.
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.
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.
Source: techgenix.com
If you are a cloud administrator, you are probably working with code to some extent. It could be a simple as automation scripts using PowerShell to manage a couple of resources, or a full ARM template set of files to deploy your entire infrastructure. You can always use Visual Studio to manage your code, and it has native integrations with Azure DevOps. However, a great tool to work with code and supports repositories, Azure DevOps including tasks is Visual Studio Code.
In this article, we are going over the process to install it and integrate it with Azure DevOps.
Setting up the environment
The first step is to get our tools downloaded on the disk. Here is a list of the tools that we need to accomplish the goal of this article with download links.
- Visual Studio Code
- Visual Studio Team Foundation Server (VSTS) client
As you may have noticed, Visual Studio Code is for everyone, and you can use it on your Windows, Linux or macOS.
The first step is to install the Visual Studio Code, and the installation is straightforward. In case you need some guidance, we are going to describe the step-by-step, as follows:
- In the License Agreement: If you agree with the terms and conditions, select I accept the agreement and click Next.
- In the Select Destination Location: Leave default settings, which is C:program filesMicrosoft VS Code folder, and click Next.
- In the Select Start Menu Folder page: Leave default settings and click Next.
- In the Select Additional Tasks page: I recommend selecting all options available. They are useful when managing code files in Windows Explorer. Click Next.
- In the Ready to Install: Review the settings selected until this point, and click Install to start the installing process.
- In the final page of the wizard: Click on Finish and the Visual Studio Code will be launched automatically.
The first view could be scary, but after spending a few hours using Visual Studio Code, you start getting acquainted with the new interface. I’m sure you will love it, and it will be your favorite tool to manage code.
The interface is simple, and I will try my best to describe in a few sentences. On the left side (Item 1) we have the Activity Bar, where your future extensions may add icons to the editor. The default icons are Source Control, Files, Search, Debug, and Extensions. When we click on any of those icons, a new area on the side will be displayed (Item 2).
All the configuration of the Visual Studio can be found using the settings icon (Item 3). In the Status Bar (Items 4 and 6), we can see numerous icons that will give you an idea of what is going on based on the extensions that you have installed. Item 4, specifically, takes you to a console where we can check Problems, Output, Debug Console, and even a Terminal.
Last but not least, in Item 5 we can see the area where the files will be open and where we can work with them.
The next step is to install the Visual Studio Team Foundation Server (VSTS) client, and the installation is straightforward. Leave default settings. The most crucial step is to capture the path of your tf.exe because this is the executable that will integrate Visual Studio Code with Azure DevOps.
In my machine (I have Visual Studio 2017 installed), the location of the tf.exe is C:Program Files (x86)Microsoft Visual Studio2017EnterpriseCommon7IDECommonExtensionsMicrosoftTeamFoundationTeam Explorertf.exe. Please find the file and store the information because we are going to use it.
Enabling integration with Azure DevOps
Now that we have Visual Studio Code and the Visual Studio Team Foundation Server client installed on our workstation, we can start integrating with Azure DevOps.
One of the coolest features of Visual Studio Code is the F1 or Ctrl + Shift + P, which brings the command palette and that is a must-know feature. Using the command palette, we can interact with the extensions installed and perform virtually any tasks that we would have to use a mouse to interact with the editor. By default, all available commands are listed, and if they have a keyboard shortcut, it will be displayed on the right side.
In the example below, we tried to see if there is anything out of the box with Team Foundation and no commands couldn’t be found, which is expected.
Click on Extensions icon on the left side (or Ctrl + Shift + X), and that will bring the Extensions Marketplace. A list of all enabled and recommended extensions available will be listed, type in repos in the search field, and select Azure Repos from the list.
In the right side, we will have a brief description of the selected extension. Click on Install to add that to your Visual Studio Code.
Now that we have the extension enabled, we need to connect the dots to allow the integration. Click on Manage icon on the bottom left corner, and click on Settings. Type in tfvc.location and fill out the Location field with the path of the tf.exe file that we performed in the previous section. The save is automatic, no need to worry about it.
Synchronizing your first repo
Let’s assume that you have a Repo created in Azure DevOps. To create a local copy click on Clone.
Visual Studio Code Azure Devops Repository
In the new window, select Clone in VS Code on the IDE area. The Visual Studio Code will be open automatically, and a dialogue box asking confirmation to allow the extension to access a URL, click Open.
The next step is to select where we want to create a copy of the repository in our local disk. Select a folder, and the entire infrastructure that you have on your Azure DevOps repo will be replicated to your local disk. Click on Select Repository Location when done defining the folder.
An informational popup will be displayed, and it will inform the user that the repo is being in the cloning process. After the cloning process is complete, another popup will be displayed, this time the question is to open the recently cloned repo, click Open.
Visual Studio Code Azure Devops Integration
The result will be all folders and files being displayed on the left side. When the replication is complete, we will have a local copy. However, we need to able to make local changes and send back to our Azure DevOps repo. The first step is to connect to Azure DevOps. Type F1 and find Team: Signin (or type it) and hit enter when you have that option selected.
The same command palette will ask how we want to connect. We have two options: provide an access token manually (current experience) and authenticate and get an access token automatically (new experience). We are feeling adventurous today, and we are going to try a new experience: Select the second option and hit <enter>.
A random code will be displayed in the command palette copy that information and hit enter. A new Azure portal will be open automatically. Enter the code that we have just copied and click Next. The next step is to authenticate using your credentials.
Now that we are connected, we can click on Source Control icon on the left side. If we change and save any given file in that repo (for example, README.md, which was the first file created when we initialized the repo). The result will be the file being listed on the left side under the Source Control icon.
Azure Repos Extension For Visual Studio Code
To commit the changes, we can click on the Check Icon located beside of the Source Control: Git in the image above. A dialogue box will be displayed. Click on Yes to confirm the changes to be committed. The command palette will ask for a commit message, type something meaningful and hit <enter> to confirm.
Visual Studio Code Azure Devops Repo
The final step is to synchronize the committed changes with the repo. There is an indicator at the bottom that gives us an idea of the changes that will be sent to the repo.