In my current company, we are sometimes approving our own pull requests for the sake of bugfixing. If it's a small bug, or someone has breakdown service, they are required to be able to fix things quickly.
Because some people abuse this functionality to approve their own 'features', I wish to remove the ability to do this, except if the there are only 'bug' workitems linked to the PR.
As far as I have seen, I can only check some marks regarding the policy of the masterbranch.
Can I create a policy to enable people to approve their own pull requests, if no work-items other than bug items are linked to it?
That's not supported in Azure Pipelines - it's either allowed or not based on your branch policies. Everything that follows is opinion, so take it with a grain of salt - I'm not convinced that such a feature would solve your problem.
You said that you currently allow developers to approve their changes because, if there's an urgent bug they need to be able to move quickly. That's understandable. Also, developers can "game the system" by PR'ing features.
If you were to restrict branch policy to allow developers to merge PR's only if bugs are attached, what prevents the developer from putting new feature functionality into bug fixes?
In other words, your PR policies work by convention, and that convention can be broken. Your proposed solution is another convention that can be broken.
Related
There is one particular point I don't understand for GitLab's merge requests.
I cloned a repository and made a feature branch. I worked something on it, committed it, and pushed the new branch to my GitLab repo.
With that I can make a merge request. When I do it says:
Assignee (and Assign to me)
Who should I assign it to? I mean, if I assign it to me, it is going to be me who "reviews" the change and approves it, so what is the point?
Or should I assign it to the repository administrator? Or to other member reviewers, so that they can check that and approve the merge?
What is the "Assign to me" option, and how does that makes sense?
There is documentation for that. It states:
This person owns the merge request, but isn’t responsible for reviewing it.
Additionally, the documentation explains an exemplary merge request workflow. You would typically create the MR before working on your feature branch. Then you can use the Assign to me feature to indicate that you are the one currently working on implementing the features of the MR. After your work is done you can request approval from a reviewer by assigning the MR to them (see Step 7 in the MR flow).
The people who are assigned to a merge request are the people who are responsible for it, not in a review kind of sense.
Usually it is the person who creates the pull request who counts as responsible for it i.e. has the responsibility of merging when all reviewers are happy and have approved or making changes according to the reviewers comments.
However, multiple people can have this responsibility as it is not always prudent for this to rest on a single person (what if the person goes on vacation?).
Another case is if multiple developers have been working on the same feature and therefor have shared responsibility for the code in the merge request.
It is actually described in Gitlabs Documentation for Merge Request
TL;DR Multiple people can have responsibility / can be accountable for the merge request.
we are using Azure DevOps as our ALM system. When a user story or bug fix is resolved, it shows in a public query - like a stack - where our QA team members subsequentially pull tickets independently for verification. As this is part of a pull request review, a PR can not be merged unless QA finished testing. So we aim for fast response times and parallelization of testing to minimise the potential of merge conflicts. Often times, we find that multiple work items are self-assigned to the same people, while other team members do not have work items assigned, increasing the potential response times for our devs (unless people change assignments) and leading to a rather subsequential then parallel verification of work items
So we are looking for a way in Azure Dev Ops that allows us to make sure that members of a certain user group can only be assigned one work item of certain work item type and state at the time. We looked into Custom Rules in detail but failed to get anything like this out of it. I'm thankful for any ideas and hints on how this can be accomplished (extensions also welcome)
There is no such rule or policy in Azure DevOps.
And it won't prevent someone from working on it anyway to be honest... I assume testing multiple changes in a single go isn't an option? It would simplefy things tremendously...
Is there a way to filter to show only issues that are related to a specific issue? There's ways to filter an assignment and author and such but I can't find how to filter like:
linked:[issuenumber]
As of Gitlab 13.9, no. After searching through all their issues, it doesn't seem anyone has even brought it up. That's where I'd start if you're a free tier user, otherwise contact your sales rep or support for paying customers to request it. They tend to implement features faster if it affects paying customers than they do for free users.
We're currently evaluating the use of GitLab for our project and one thing we find slightly off is the comments when reviewing a merge request.
The problems starts when some comments were entered as part of the code review and a new commit was pushed to address these comments.
Both the comments made on the commits and those made on "Changes" panel are shown on the "Discussion" tab, but there's no indication that some changes around the same lines were made. Going to "Changes" panel and looking at the latest-to-base comparison - I get exactly what I'd expect (everything done on the branch thus far), but then we have no was to see that overlaid with comments made on the old commits or old review.
I was half-expecting that in the discussion panel I'd be getting another section under each comment showing what was changed in the code recently. That, or be able to access all the comments ever made in the "Changes" panel when looking at the latest, even comments made on older versions.
Is there something I'm missing here when it comes to GitLab review process and managing comments?
GitLab has evolved considerably since 2016, and the new 13.1 (June 2020) adds a feature which is relevant for your use case:
Mark any Design thread as resolved
When you receive lots of feedback on a Design, the number of comment pins can build up quickly!
As your discussion thread grows, it gets hard to know which discussions are complete and which still need work.
With 13.1, you’ll have the ability to mark any comment as Resolved to signify that it is now complete.
Even better — your resolved comment pins will disappear from the Design so you can focus on what’s left!
And, of course, if you need to revisit something, all of your resolved threads will be available in the Resolved Comment area at the bottom of the sidebar. From there, you can find them again and see which revision applied at the point of revision.
We think this will greatly improve your workflow so you can focus on what is important.
See Documentation and Issue
GitLab 13.5 (Oct. 2020) will add a clear distinction between merge-request participants ("assignee") and reviewers:
To bridge these gaps, GitLab 13.5 introduces merge request "reviewers," which easily allows authors to request a review as well as see the status of the review.
By simply selecting one or more users from the "reviewers" field, the assigned reviewers will receive a notification of the request to review the merge request.
This makes it easy to determine the relevant roles for the users involved in the merge request, as well as formally requesting a review form a peer.
Requesting a pull request review is already available for GitHub
With GitLab 13.7 (December 2020), you have a clearer definition of reviewers:
Reviewers for Merge Requests
Asking a colleague to review your code should be a routine part of contributing code, but it’s often needlessly complex.
A simple task like asking for a review can lead to confusion. For example, how should you ask? An email? Comment? Chat message?
Without a formal process, reviews can be inconsistent and hard to keep track of. Previously, an option was to assign a reviewer to a merge request, but even with this formality, both the author and the reviewer appeared in the same assignee field, making it hard for other team members to know who was doing what.
GitLab 13.7 introduces reviewers for merge requests, which allows authors to request a review from someone.
The new “Reviewers” field allows users to be designated as reviewers in a similar way to assignees. The reviewers receive a notification inviting them to review the merge request.
This provides a formal process for requesting a review and clarifies the roles of each user in a merge request.
Future iterations will include showing the most relevant reviewers for a merge request as well as a streamlined merge request approval flow that puts reviewers at the center.
You can follow along in the merge request reviewer assignment epic for more details.
See Documentation and Issue.
See also GitLab 14.6 (December 2021)
View inline the change that outdated a merge request thread
When addressing review feedback in merge requests, you often change lines your reviewers have commented on.
In those comment threads, GitLab indicates that new changes were made.
However, to understand if those new changes address the feedback, reviewers would have to navigate away from the context of the discussion.
Now, when viewing threads related to old changes, you can view the new changes directly in the thread.
This improved context helps you review faster and more accurately.
See Documentation and Issue.
And GitLab 15.3 (August 2022):
Submit merge request review with summary comment
When you finish reviewing a merge request, there are probably some common things that you do, like summarizing your review for others or approving the changes if they look good to you. Those common tasks are now quicker and easier: when you submit your review, you can add a summary comment along with any quick actions like /approve.
See Documentation and Issue.
My company is planning to start a forum for our software product which the clients can refer for general FAQ's, problems etc.
Right now we are planning to have:-
User manuals.
Best practices for different section's of the application
Frequently faced problems.
Forum where user can discuss issues with development team.
Any other ideas?
Edit:-
We have RSS and E-mail notification subscription to the forum.
Forum where user can discuss issues
with development team.
I don't know if this is a euphemism for "issue tracker" but if not, make sure you include a way for people to submit bug/feature/enhancement reports and track them to completion. Nothing is worse than not being able to submit a bug report or being able to submit a bug report but only into a black hole.
Communication is key.
If you add an issue tracker as suggested by Kevin, your list seems pretty ok to me.
I'd also suggest that you do not start out with too many different services that require interaction from your side (e.g. your developers) at first - I've seen (too) many good initiatives die simply because nobody in the company had enough time e.g. for regular answering of the forum questions.
In your case, I guess "best practices", "frequent problems" and the forum will all consume regular time from your dev team if you want to keep them alive and up-to-date, especially in the beginning. So I would not add more services at the beginning but make sure to get these right (and you can always add more services later on if you find that the users need them :-).
You.
Show that you care about your customers.
Many useful tips at Creating passionate users blog.