This article on “non-blocking code review” keeps knocking around my head. As part of wanting to move closer to that, I've written a small tool to view commits related to a ticket. I want to grow this into a full code review tool; haven’t yet decided whether this will be written in Ruby or be used as an opportunity to play in a new language.
Mulling over the idea that a good way to track the stability of an application (in terms of the amount of bugs introduced over time) is to track the number of support tickets raised per-project. This would probably benefit from a severity rating and classification, also.
Different people have different standards for the speed of unit tests and of their test suites. David Heinemeier Hansson is happy with a compile suite that takes a few seconds and a commit suite that takes a few minutes. Gary Bernhardt finds that unbearably slow, insisting on a compile suite of around 300ms and Dan Bodart doesn't want his commit suite to be more than ten seconds
Set up a git pre-receive hook for ensuring commit messages contain ticket references. It's a shame GitLab makes this so difficult, they should be first class citizens.