VSO – Prabhu Kumar

We’ve enabled a rating and review system on VS Marketplace for VSTS and VSCode extensions. Until now, download count of an extension served as a proxy for estimating the quality of an extension but no more!

You can see a 5 star rating on the extension on the marketplace homepage. Note that rating and review was already available for Visual Studio extensions. This enables it for VSTS and VS Code extensions as well.

Hovering over the stars shows you the exact rating and the number of people who have rated this extension.

Clicking on the extension takes you to the details page, where we show the average rating of the extension and the number of ratings on the banner,

If you notice carefully, you can see that that color of the stars on the banner will change between orang-ish or red-ish based on the background color on which it is rendered. This is done so that the stars have a nice contrast and can be seen clearly against the background. Here’s an example: red stars on a light background and orange stars on a dark background,

You can click on the stars to scroll down to the details section,

The detailed section consists of, as you can probably guess, details of the reviews. You need to be logged-in to leave a review, you can use your Microsoft Account or any other AAD backend account for this. The detailed section shows the picture and the display name associated with your profile. You can easily change this by clicking on your name at the top and then editing your profile details,

The name and picture you set here will be used in the review details section. So you have the control to change this anytime.

Clicking on the ‘Write a review’ button brings up the review submit dialog, (who’s excited about pink buttons! :-)

You need to provide a rating, that’s mandatory. The submit button will be disabled until you select a rating. The review comment is optional and you can choose not to enter any text, though I recommend entering the text as it helps the developer get more details out of the review and figure out what you like/dislike about the extension.

After you provide a rating and review comment, click on ‘submit’ and your review will magically appear in the details section!

If you see a review that’s offensive or just plain spam, use the flag icon on the review to report it. We have three categories that show up currently,

You can select the most relevant option while reporting a review. Our team will run through the reported reviews and take appropriate action based on the content of the review.

That’s it for now, stay tuned for more!

You can read more about this here,

https://blogs.msdn.microsoft.com/bharry/2016/03/23/ratings-and-reviews-in-the-vs-marketplace/

https://blogs.msdn.microsoft.com/visualstudioalm/2016/03/23/now-rate-and-review-extensions-on-marketplace/

We’d love to hear any feedback, feel free to leave a comment or ping me on twitter at @prabhuk

Branch policies in VSO allow you to set certain rules against branches in your Visual Studio Online git repos. They are more or less like gated check-ins which TFS has had since forever. Visual Studio Online supports the below policies by default:

Changes must be submitted to a branch only via Pull Requests
A build must complete successfully before changes can be merged to the destination branch
Add certain reviewers if the pull request modifies files in certain paths in the repo

To know more details on the complete workflow involving pull requests on visual studio online, check this excellent post http://blogs.msdn.com/b/visualstudioalm/archive/2014/06/10/git-pull-request-visual-studio-online.aspx

Setting up branch policies

To setup branch policies login to your visual studio online account and navigate to the team project, which has the git repo you want to set the policy on. You will need to have administrator privileges on the team project to setup the policy. After you’ve navigated to your team project, click on the settings wheel icon on the top right corner, this will take you to the admin panel of your team project. Select the ‘version control’ tab, and on the left rail select the branch you want to set the policy on (master branch in my case), and click on ‘branch policies’ tab. Refer the figure below, the click points are highlighted in yellow.

Under ‘Automatically build pull requests’, select both check boxes. You will need to provide a build definition here which VSO will queue every time a pull request is submitted or updated with a new commit. The second check box, ‘Block the merge’, is actually optional, if you want to allow the merge even on build break, you can uncheck this. Though I’m not sure why you’d want to do that.

The next section, ‘Code review requirements’, allows you to control how changes can be submitted to master branch. The first check box, ‘Require code reviews using pull request’, ensures that any changes to master happen only via pull requests and no one is able to push their changes directly to master. ‘Allow users to approve their own changes’, allows to you add yourself as one of the reviewers and approve the changes, which is nuts really :-)

The last option, ‘Add a new path’, enables you to add reviewers optionally depending on the files involved in the commits. For scenarios where you really want Dave C to look at the changes if anyone modifies files under \kernel\base. It has support for wild chars as well.

After the policies are set, when someone tries to push their changes directly to master, they see this:

So what you need to do now, is move your changes to a feature branch, push that branch to server and create a pull request to merge the changes to master. This workflow is explained in the link shared above.

Now let’s say, the feature branch was pushed and a pull request was created, but the change list has a silly syntax error. You will see the branch policies show up in the right rail and a build will be queued for verification.

Since the pull request had a syntax error, the build will fail and attempting to merge the changes to master will be blocked.

The next step is to fix the build failure, add a commit to the pull request and make sure you have at least one approval from reviewers. As soon as you push your local branch to server, a new build will be queued automatically and the status updated.

To enhance this even further, you can improve your build definition by, let’s say, adding a unit test build step and a code analysis build step, to ensure that all unit tests pass, before the pull request can be accepted and merged into master.

Category: VSO

Ratings and reviews on VS Marketplace!

Branch Policies in Visual Studio Online