I would like to check in code after a code review is approved. I came across this stack about creating code reviews and checking in, but my question is a little different.
My issue is that I want to create a code review; however, I do not want to check in the code until it is approved. That limits me from being able to start another code review with removing related work items. What I would like to do is create code reviews and check in from the code review tab in the Team Explorer
Is that possible? It is the same principle as creating a code review after the check in, but with Code reviews and checking in. I do not want to go to pending changes and check in there because I may have removed the related items. But I do want a check in to be tied to my code review.
Unfortunately, there is no "proper" way to do what you are trying to do. You could have your working directory on a shared drive and just notify your reviewer when you are ready for them to start their review process, but that side-steps the accountability by not having each development/review iteration officially logged within TFS. This means you should check in your work and let the reviewer do their job, then continue on in that fashion to make any changes requested by the reviewer, check in, and get another code-review.
For completeness I will mention my suggestion from my comments here as well.
My suggestion would be to create a self-contained, short-lived development branch where you will do your development and have your code reviewed. Then once the development and reviewing has been completed to satisfaction, that branch can be merged back up and destroyed. This provides a much cleaner and safer approach. 1) It reduces the clutter in the history within TFS. 2) It prevents multiple unnecessary automated builds/tests/etc... from being triggered.
In your comment you suggest that this changes the "structure of your branching methods". I don't see how doing this changes anything in any way that matters. Your merge would be just like your final development check-in except that by this time all reviews have been completed and you are performing a single, clean check-in. It will still contain all of your check-in and review information, however instead of a cluttered chain of check-ins, you will have a single collapsed node which contains every single thing that was done for that particular task.
I would check with your manager, your code reviewer and/or anyone you have that is in charge of TFS and creating/maintaining your TFS policy. This approach really doesn't change anything in regard to how the rest of your process works. You would have simply abstracted your development cycle to a self-contained environment. The second you perform your merge you are right back into your normal process as you have it now.
Okay, so for documentation purposes. I did not fully understand the shelving that TFS allow me to do. After reading Shelve and Unshelve Pending Changes, it makes more sense to me. I can shelve what I am working on, unshelve the code that I have done a code review for, then check in that code. That way I can create a code review and continue working until that code review is approved. Once approved, I can go unshelve the changes and check it in.
Related
We had a few cases when:
Someone changes a task group (or build/release/whatever).
Makes some mistake.
Then publishes/saves it.
But doesn't notify anyone that such changes were made.
Some hours later some dependent build breaks because of those changes.
And we have to spend even more time trying to find what and when has changed as it is not often that simple to find out with external task groups.
What we want to have:
Ideally - some approval process for such changes. Kind of like code review, but for task groups/builds.
If not - then at least some way to receive notifications about changes in task groups and etc. we are interested in?
I found neither, and, honestly, doubt that such features are present in the TFS version we use (TFS 2018.2), but perhaps I've missed something.
There isn't any workflow security or approval process for the groups. You could suggest that kind of feature on the developercommunity. Restrict access to edit Task Groups to only those who understand how to bump the Task Group version. That way at least you will keep backward compatibility across your builds unless that explicitly upgrade to that version.
There aren't any built in notifications, but you could create an automated process to send email notifications using PowerShell using the existing API.
Get the Id for the task group using the taskgroups list api
Use the revisions api to get the history _apis/distributedtask/taskgroups/{taskgroupid}/revisions
Send an update for anything that edited today
Is there any way to do this? I have looked into TFPT, Review Assistant, and the Microsoft.TeamFoundationServer.Client and Microsoft.VisualStudio.Services.Client NuGet packages. I just want something that I can create code reviews with which will display the progress of those code reviews on my team's TFS board.
No this currently cannot be done as far as I can tell, at least not without serious mucking around wit the workitem template for Code Review Request.
You may be able to achieve your goal by adding all required fields for tasks to the Code Review Request work item and adding Code Review Request to the TaskCategory, but since this work item type is tightly coupled with the UI implementation I do not know how far you could go before the UI will break.
The process is largely the same as the work required to add Bugs to the taskboard. so you could experiment with that. I suspect you may run into issues around mapping the states of the Code Review to the States of the Task workitem, which will likely break the Visual Studio UI as well.
As an alternative you could create a custom dashboard widget using a Work Item Query. It would show up on your Team's homepage on TFS and would show you your status.
I would like to automate the code review process to check in easily in Team Foundation Server.
It is possible to add code review in the check-in policy, but the problem is that it creates a lot of back and forth, even if the code review is okay and there is no comment or modification to make.
Maybe it is possible to make it happen in a smoother way?
Sketches (simplified on purpose)
What we can do with the actual code review workflow:
What I would like to do:
(hoping my sketches are understandable)
I'm thinking about developing a new extension if it doesn't exist.
Any help would be appreciated, thanks!
What you're looking for is called a pull request. Pull requests are not available for TFVC at the moment, but are available for Git. My understanding is that pull requests will eventually be an option for TFVC.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I have a small team of developers that use bitbucket as our git repository.
I want to know how to limit who can merge code on a pull request in bitbucket? AND/OR force at least one approval before the merge can be done. Basically I am looking to force a code review.
As of now the creator of a pull-request (and everyone else) can not only approve but also merge the code in which can be an issue for quality purposes. Thanks in advance.
Update:
Bitbucket now allows for control over push permissions, branch deletion, and history re-writing. The full management instructions are here: https://confluence.atlassian.com/bitbucket/branch-management-385912271.html
There still is not a way to force a minimum number of approvals however.
I want to know how to limit who can merge code on a pull request in bitbucket? AND/OR force at least one approval before the merge can be done. Basically I am looking to force a code review.
This functionality is not available in Bitbucket right now, but Atlassian's behind-the-firewall version of Git hosting has it.
Stash allows you to:
limit who can change branches
enforce a minimum number of approvals before merging pull requests (it can do a similar thing for Bamboo builds - i.e. the code must compile before it can be merged)
reset approvals if a pull request changes
It's a curious asymmetry in Atlassian's own products.
Answer from attlassian:
Mary Anthony [Atlassian Technical Writer]
Hi,
So, a repository can have branches. Within that repository, you can't
set permissions on a branch that are different from the repository.
You can set permissions on the repository that would allow developers
to fork the repository and issue pull requests against it. To
configure this:
Create a group on your account and call it "developers".
Give the group read permissions.
Add all the developers to that group.
Edit the groups on the repository and add developers.
Hope this helps.
Mary
Here it is: https://confluence.atlassian.com/display/BITBUCKET/Work+with+pull+requests?focusedCommentId=321851850#comment-321851850
In other words, you can make your dev fork the project and issue pull requests from their fork. In your project , you can set the project to disallow public fork. I assume that they will fork the project and it will be hidden. That said, they will be able to issue pull request and edit their own repository. It looks quite akward but it should work.
I don't have the feeling that there is a good way to handle permissions on github/bitbucket and so on.
edit
Not really a solution to enforce it but still quite valid. Since approval of pull-request is quite optional. Doesn't mean that you're screwed and in fact, if I were you. I wouldn't try to enforce a system. The reality is that code review is important. Pull request makes it easier to review sets of commits.
I worked many months being the only one in my team to create/approve pull requests. The team in which I worked decided that pull requests was a waste of time and I guess that none of them did code review until I left. Last thing I heard is that my team mate is currently refactoring my code because he has no idea how it works.
What I'm trying to say is that code review shouldn't be enforced and your team should see it as a quite important thing to do. Each member of your team should work together and code review each others on their own. By doing code review, they will have the right to deny code that they feel is "ugly" or should be designed in a different way. Each member get to stay updated on what other devs are working and may not have much problem switching on anybody's work in case of illness, departure or death!
Enforcing the process in the system could be good from a manager's point of view. But I believe that having approval as optional isn't bad either. And then, the manager's job will be to check the merged pull request for the pull request with 1 or less approved person. Check who merged the pull request and who approved. Find someone to review the code anyway.
On the other hand, if a pull request is hanging around forever and nobody is reviewing it. It's the dev task to ask a mate to review it.
We recently started using Team Foundation Server 2012 and are using the code-review feature to have other developers review code changes. It seems to work great; however, as a project lead I would like to be able to see that a given changeset has been reviewed by someone else.
For example, say Developer Bob makes changes and requests a review on those changes. This generates a shelveset for the changes and creates a code-review work item for the requested review. Developer Alice reviews the changes, makes some comments, and finishes the review. Bob incorporates Alice's suggestions and checks in the changeset.
As a project lead, I search for changesets and see that Bob checked in changeset 123. If I look at this changeset, there is an associated work item for the task Bob was working on, but no indication that the changeset was reviewed by anyone else.
If I look at code-review work items, I can find the things that have been reviewed and see the comments. This is cumbersome as I have to sift through work items and find the one that happens to be related.
How can I tell from a given changeset that it was reviewed, as well as see the review comments?
Changesets can be linked to any kind of Work Item, including Code Reviews. When you request a review on a set of pending changes, they are automatically associated to the new review Work Item. When you double click on the changeset you should be able to see under Related Work Items something like this:
In this case there were 2 reviews for this changeset, the second one was automatically there when it was requested. The first one had to be manually linked, just like the Task.
If you double click on the review item, you can see all the comments.
Tip: If you want to do a review post-checkin: go to the History view --> double click on the changeset --> Actions --> Request Review.
Tip2: It is a bit annoying that you have to manually check that each changeset has a review. If lack of review is really a problem for your team, I would suggest setting up a check-in policy.
You can make queries searching for code review work items and you will find associated changesets on the field Associated Context (Changeset id or Shelveset Name)
Inside the Code Review, you can check the changeset via the link at the top of the work item view.
Of course, there is another option that is querying directly to TFS Database (Warehouse) but it's tricky and requires access to that database and knowledge on the schema.
from work item history u can check out all the change sets ....changeset was reviewed by anyone else this functionality TFS does Not provide!
may be i have lost Something but i don't see any answer regarding to change set that is was reviewed.
but you can check the change through (history , and sort the source control by date ).
good luck!