Our company has multiple projects, and uses code reviews in most of them. However in one decades-old project we get the following message: "This feature can't be used until your Azure DevOps administrator has enabled it on the team project."
In Visual Studio / Team Explorer / Pending Actions, I drop down the list of Actions, and select 'Request Review' to get the above message.
We can't find the setting to enable code reviews, and google can't find any mentions of the error message.
We're still using Team Foundation version control, not Git.
We are on "Azure DevOps Server 2020 Update 1"
The closest match I've found on the web is this but it's not quite the same, and I'm reluctant to poke around with the templates without understanding them. It is quite possible that this project has been imported from our old Source Safe system some time ago though, the history is murky.
There used to be a new feature enablement wizard in versions up to Team Foundation Server 2018, It has now been removed. So now you'll have to do this manually. The blog post you referenced looks correct at first glance..
What you need to do is to make sure the right work item types, categories and relationships exist in your team project.
This official doc lists the steps to take. You'll need to:
Download the latest process template: Get the definitions you need to import or update
Import WITs: Code Review Request and Code Review Response
Update Categories:
Add the Code Review Request and Code Review Response Categories
Add the Code Review Request and Code Review Response Categories to the Hidden Types Category
Update ProcessConfiguration: Add work item colors for Code Review Request and Code Review Response
To verify, create a code review request.
You're likely missing more features, all of upgrades are described in the linked documenation.
Related
I am looking for some guidance on how to best setup Azure Devops where multiple project teams can submit work requests to my team. My team would review the work request, size it up, enter the implementation date, etc...the other teams can view status updates once my team completes sizing up the request. Those requests would then be moved into our main Board to initiate dev work.
Here is a summary of the current process in place:
Other project teams would submit an intake request through a
sharepoint form.
My team would review the intake request, size it up along with any
other necessary info.
My team would than open a PBI in TFS with all applicable info from
the SharePoint intake request.
Complete the work and update the status to "Done" in TFS.
Go back to SharePoint form and update the status on the intake
request to Complete.
Notify the other project team that work is complete and deployed,
etc...
I'm looking to consolidate this process completely into ADO. My teams board should not have access to edit by other project teams. Perhaps something like a PBI can be opened by other project teams with a specific access to a limited number of State/Status options? This way my team can segregate PBI's by State (Status).
Any recommendations on the best approach to handle intake requests and consolidate everything into ADO with permissions in mind would be be appreciated! I'm open to different ideas.
The rough approach I would take uses area paths to control visibility. Under Project Settings -> Project Configuration, Areas tab, ensure that two area paths exist for your team: one for work intake from other teams, one for work tracking for your team (this may already exist if your project team has already been created).
Then, edit Security for the intake area path (options drop down for each area path). Add each other project team AND your project team, with "Edit work items in this node" set to "Allow".
Then, edit Security for the work tracking area path. Add each other project team, with "Edit work items in this node" set to "Deny". Your team should have "Allow" access here.
Your workflow then becomes that external teams will contribute work items to the intake path, and your team changes the area path to your work tracking area when it's time to prioritize and work them. External teams should be able to see the board, but not make modifications at this point.
I have confluence page, where I want to store all my feature files(specflow), so that Business can have a look. Currently these feature file resides in a repository in Azure Devops. Is there a way to dynamically link these two , so that Confluence gets updated with the latest feature files ?
Thanks,
Rajee
I have the same basic problem, too. Our code is in DevOps and our product owner needs access to the feature files, but without a higher license in DevOps they cannot see repos.
I submit a pull request even to include new features. I mention the work item Id for the epic, story, feature or bug it pertains to in the commit message. I like to use conventional commits for commit messages in this case:
docs: Cucumber tests for X feature (related #1234)
(where #1234 is the work item Id in DevOps)
Make sure the epic, feature or story is linked to the pull request in DevOps.
Upon completing the pull request DevOps adds a link from the epic, feature story or bug to the pull request, providing some traceability to the real code.
Next, I copy and paste the feature files and scenarios into the acceptance criteria for stories, steps to reproduce for bugs or the description for features and epics. I also include a relative file path in the work item description to the feature file:
(copied and pasted from Project.Specs/Foo/Bar.feature)
Feature: ...
In order to ...
As a ...
I want to ...
Scenario: ...
Scenario: ...
It's a manual process, but you could adopt something similar in Confluence. You might not get the link from the commit to the wiki document, but basically copy and paste is your only free choice.
If your customers have read access to DevOps (which they should) adopting the procedure I outlined above at least gives you some traceability between the work item and a pull request that added the features to the repository. Then it is a manual step to copy and paste the features into the work item descriptions or acceptance criteria so the customers can review and approve. Annoying? Yes. But it does the trick.
I want to link test run results to user story to add more traceability on board for all team members.
I've found that I can add link for New and Existing items, but there I can find only Work item type: Bug, Blocker, Epic, Feature, Test Case, User Story etc.
If I add link to test case, I will see only test case itself (test steps) and can't find any information about this test case in some test suit or test run results.
I've explored VSTS documentation: Link user stories, issues, bugs, and other work items and Linking, traceability, and managing dependencies.
As I understood, there is no such functionality right now in Azure DevOps (VSTS).
As you said, currently there is no such thing in Azure DevOps, but there is a great extension to add the test run results in the test case.
The (free) extension called View Latest Test Result, after you install it you need to modify the process template (to add the results) and then you got this:
On Developer Community I found opened ticket for it:
Need ability to link Test Results back to ANY work item type, especially User Stories
I did up vote, but it seems that for now I can only wait for this feature.
We have a project on VS online that uses the Agile process template. We have configured this project to
.
If I create a bug, I can't unfortunately delete it afterward. The 'State' dropdown only includes the 'New', 'Closed', 'Active' and 'Resolved' values. This does not match with what Microsoft documents in the following page. If you look at the section labeled 'Q: What workflow states does Agile support?', it says that you can go from 'New' to 'Removed'.
Why I am not able to do this change? What can I do to remove bugs that were created by mistake or that were simply not valid?
Note that I am the administrator of the project.
Sorry about the confusion. The Removed state is not part of the Agile Process Template, and we will update the documentation to reflect this.
We will also fix the product moving forward to allow to remove bugs on the backlog. Keep an eye to the release notes (and subscribe to the rss feed) to learn when we have fixed it.
Ewald Hofman (TFS/VSO Program Manager)
I can get the same behavior with you, so I help you submit a feedback on Microsoft Connect website, you can track the feedback from this link:
https://connect.microsoft.com/VisualStudio/feedback/details/1986844
For now, you can delete the bug via destroywi command:
witadmin destroywi /collection:https://<your project>.visualstudio.com/defaultcollection /id:<bug ID>
I have a GitHub account and Basecamp account. I have already setup my GitHub to use Basecamp service hook by selecting Service Hooks Menu and select basecamp. Fill all required form and get the setup work properly identified by green color.
Now, I have to-do list at my Basecamp account, but I don't know how to interact between GitHub commit comment and Basecamp to-do list.
For example, I commit my code by commenting fixing to-do list #123. But on Basecamp, I can't find to-do list ID (ex:#123) like common project management that I use before. I also can't find a documentation about it.
Can someone help me with this?
I don't think that's possible with the existing github-basecamp integration (the one in the predefined service hooks). So, in short: if I'm correct, it cannot be done the way you can close github issues, which you also seem to be referring.
So basically you'd need to do some coding of your own. You have two main choices.
You can enable a webhook in your github service hooks, have that do a POST request to an url of your choice, and have a script at that url use basecamp API to update the list. The todolists api seems quite simple: you should read a commit message coming in the POST request, and do a "update todolist" request with "completed": true.
Another alternative is to interact with Basecamp API from your local repo. There seems to be some existing tool called gitcamp, made by someone, to help with that - however as the api is quite simple, as well as your requirement, you could do your stuff with a custom script installed as a hook, and possibly with more ease.
I have send a same question to both github and basecamp support and bellow they answer.
Basecamp Support:
Sorry about that confusion with the GitHub integration! At the moment,
that integration only brings in the commits you make into the Progress
page and recaps. Here's the code behind that integration so you can
get a better idea of the guts of that service hook:
https://github.com/github/github-services/blob/master/services/basecamp.rb
If you have any other questions, just let me know and I'll be happy to
help. And have an awesome Sunday!
Chase Clemons 37signals CustomerCare
Github Support:
The Basecamp hook is for the new Basecamp system, and only adds to a
project's event log. There is a Basecamp Classic hook for the older
Basecamp system. It looks like that hook only creates Basecamp
messages. It doesn't look like anyone has written any Basecamp to-do
integration with GitHub at this time. Our 3rd party hooks are
contributed by other users because we don't actually use any of those
services (Basecamp included). You're welcome to contribute to them:
https://github.com/github/github-services
So it's clear at the moment (when I write this), what we commit and push into Github repository just automatically show on Basecamp Progress page.