What's the purpose of the Check-In Notes? Why use them instead of just the "Comment" you enter when you check-in.
I see there are four types of Check-In Notes: Code Reviewer, Developer, Security Reviewer, and Performance Reviewer. Is the idea to put in the name of these reviewers or some actualy comments by these people. Does this presume that you do do a team walk-through before checking-in code? I know policies can change whether these are required, but I'm not sure what they really add on top of the "comment" field.
The short answer is that you're supposed to put the names of the people who assisted with those aspects of the checkin; and/or, their names can be added to the checkin details later when people in those roles audit the checkin.
Related
We are migrating from an in-house tool to Jira for managing our scrum board, and we have concerns that I have been unable to resolve by searching the Internet. But you folks are smart, right? ;-)
Our current scrum board shows the usual swim lanes across state columns (for todo, progress, review, done). Each swim lane represents a user story, and has a link to (and a snippet of) the user story description in Jira. It also has a number of 'tickets' (these would be subtasks in Jira lingo) that start in 'todo' and move across to eventually end up in 'done'.
So far, Jira can do all of this, too (although creating sub-tasks is rather a lot more work in Jira than in our in-house tool). However:
When we commit code, we include a ticket ID in the commit message, and thus each ticket displays a list of commits that were done to complete that particular ticket / partial story. I haven't been able to find out how to do this in Jira -- if it's possible at all. Instead, it seems one must open a sub-task to see if there are any commits on it?
Each commit also shows its review state, which gives us an excellent overview of how close to done a ticket really is. I haven't been able to find out how to do this in Jira -- if it's possible at all. Instead, it seems one must open the sub-task, and drill down further into Fisheye(?) in order to see the review state?
In total, our tool provides a one-screen overview of the state of each user story, ticket, commit, and review state; and it's very lightweight to pull in new stories (from Jira) and add tickets. We fear that Jira is not able to provide such a one-screen overview, forcing us to open Fisheye in order to know whether a given commit has passed review.
Is it really true that Jira must be this cumbersome?
For reference, here is what a single ticket (subtask) looks like in our system:
And if you look at the whole scrum board, it's actually quite easy to get a feel for the number of commits on individual user stories and tickets, and the ratio of pending/passed/failed code reviews:
I agree with your fears when you say
We fear that Jira is not able to provide such a one-screen overview
In my experience (7+ years with Jira/Agile) I've not seen a such condensed view of information about a sigle user story even on a swimlane with relative cards.
Also in the Atlassian marketplace there seems to be no good plugin to solve your issue, even partially.
To make such move from your in-house tool to Jira retaining all you have there, I fear you should develop a custom Plug-in using Jira SDK to integrate with the agile boards.
It may be enough to start by developing a custom field to show what you need from a "ticket" (ie sub-issue) and trying to insert it into one of the three "slots" available for cards (I mean Rapidboard card layout configuration screen).
If you wanna try, start from here.
Another option to create a new custom field would be the Adaptavist Scriptrunner plugin. It will ease the building of custom fields: your new field can be written also in Groovy rather than plain Java. I've used it to build an extended status custom field (just to give the user an immediate big picture of it) that informs him in plain english and with stylish css colors why an issue is blocked or anything else relevant, getting data from other fields or linked issues that are not immediately visible to the user. IMHO, it is very similar to your problem.
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.
I have an existing team working on one solution using Visual Studio Online. Now I have to add new developer to work on one of the projects. Due to security concerns I have to hide other team members' contact details and ideally names as well.
How can I accomplish this?
You're not going to be able to have everyone working in the same team project and keep this information hidden. There are ways to minimize the avenues through which someone can see the information -- for example, you could isolate the one developer into their own team, so names/emails wouldn't show up on the team's home page -- but if they're working on the same code in the same repository, they'll be able to see things like commit history, which will definitely have identifying details attached.
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!
You can limit "Check-In Policy" rules via the "Custom Paths" policy. But the "Check-in Notes" tab doesn't seem to fit in to the same system. Why isn't "Check-In notes" just another "Check-In policy"??
I'm using Team Foundation Server 2008 SP1
We had a similar problem some time ago. For some sub tree we wanted to require entering a code reviewer. I ended up implementing a custom policy and used the Custom Path Policy to restrict it to certain folders. That works well, except that you have to deploy your policy assembly and TFS has no built-in mechanism for that, yet.
That's an interesting question - the short answer is you cannot.
I have ran into the issue myself a lot where people get check-in notes and check-in policies confused because, while very different in implementation on the server, they often serve similar purposes.
Check-in notes are bits of structured meta-data that you want to collect on every check-in to a Team Project. They can be thinks like who was the code reviewer or a reference to a ticket in an external CRM system or something. You can make them required, or just have them defined for people to optionally fill out.
Check-in policies are bits of code that run on the client at the point of check-in that get a say if the check-in should be allowed or not. These are useful for checking things like you have associated a check-in with a work item, given it a comment or the code you are check-in in passes certain key static code analysis rules (such as basic checking for SQL injection attacks etc). If a check-in policy fails in the evaluation of the check-in then the user gets alerted and they get the ability to fix the problem or check-in anyway with a check-in policy override than can easily be reported on or alerted for by the TFS administrator.
Both check-in notes and check-in policies are defined and scoped at the Team Project level. However, Microsoft got feedback that some people would like check-in policies would like to be applied to specific paths in version control rather than just the Team Project and so the Custom Path Policy was invented.
The Custom Path Policy is a bit of a hack that allows you to wrap check-in policies inside the custom path policy. The custom path gets evaluated on every check-in and if it contains files inside the defined path then the wrapped check-in policies are evaluated for those files. The Custom Path Policy ships in the TFS Power Tools and is not part of the "Out The Box" TFS experience.
So, to answer your question a different way - I suspect the answer is "because that's the way it was designed and not enough people have asked for it to be changed".
If you wanted to leave feedback at http://connect.microsoft.com/VisualStudio I know they take customer feedback very seriously.