One cool unintended benefit of having a CI server going is that there is somewhere that has the latest code for all projects checked out in the file system. When issues that have come up that might be cross projects, I can just use find, grep, and other fun command line tools to quickly find effected projects. Then because the naming convention used in our CI server is tied to our issue tracking (thank god) I can quickly open up tickets for the teams to address the issues.
This doesn't help if a project is in prod and has been fixed since, but it's a lot better than not knowing where to start.
At some point, using good software tools has a benefit greater than the sum of it's parts. ;-)
Checking out and compiling the project code is the most basic of "smoke" tests. It's amazing what kind of basic check-in mistakes it will find in a CI environment
ReplyDelete...and it doesn't require any tests to be written, so it can be started on virtually any project.
Once people see the benefit of just compiling code in CI, testing may follow.
This was more along the lines of a "we've discovered that using class X can be dangerous. Who is using it?"
ReplyDeleteGrep'ing the source shows that pretty fast.
Another one that I used the other day is how the test runners for maven find tests vs. eclipse. Eclipse seems to look for @Test or if a class somehow extends TestCase. In surefire (maven), it matches the name of the file. So if you have a unit test filename that *doesn't* end or start with Test, it won't find it. You could have broken tests and not know it.
It's pretty easy to find these instances when you do something like:
find . -name *.java | grep 'src/test/**/*.java' | grep -v Test.java
(yes, I know that looks icky)