ci
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.
Tags:
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.
Tags:
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
- https://web.archive.org/web/20221222080746/https://dhh.dk/2014/slow-database-test-fallacy.html
- https://web.archive.org/web/20190329045845/https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric
- https://web.archive.org/web/20220124070115/http://dan.bodar.com/2012/02/28/crazy-fast-build-times-or-when-10-seconds-starts-to-make-you-nervous/
Tags:
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.
Tags:
Good article by Rouan Wilsenach on an approach that might be a good step towards the CI vision I've outlined.
Tags:
This was a good talk by Jez Humble. Of particular note was HP going from spending ~5% to ~40% of time on feature development by investing ~25% of their time on test automation.