[tlug] Continuous Integration

[Curt Sampson <cjs@example.com>]

On 2016-05-12 17:52 +0900 (Thu), Benjamin Kowarsch wrote:

> Imagine you are doing a major piece of work that will require several weeks
> of effort before it is in a state where it can be tested. You still want to
> be able to commit while you are doing this work, even if you cannot really
> test it yet.

Oh, well, that's true enough (I do this all the time myself), but then
that's something you explicitly don't want a Jenkins-like-thing to be
testing (that would waste both computer and developer time).

I was, of course, talking about the stage at which you're "publishing"
changes to others.

On 2016-05-12 11:05 +0200 (Thu), Josh Glover wrote:

> What we do on my current team is...

I guess my main point here is that for the majority of projects I think
that settig up a CI tool, hooks or similar stuff is basically waste of
time.

Tell your developers: "don't commit broken stuff that breaks the build."
They sometimes will anyway, especially the junior guys, but you want to
know their reactions when this happens. If the developer is horified and
scrambles to clean things up, he's clearly the kind of person that is
going to learn what level of testing he needs for any particular change.
If he doesn't care, your problem with that developer is not anything
that can be fixed by a CI tool; in fact, a CI tool can only give him an
excuse not to work more efficiently.

My standard morning routine, when I get in to the office, is on my
development machine to update a master-branch checkout, kick off a
full clean build and test cycle, and then start reviewing commits. If
something fails in the build I can start debugging immediately, rather
than seeing a problem in an e-mail message or in Slack and then starting
a fresh update/build cycle. I'll often kick off that update/build/test
cycle on my development machine several times a day, at the start of
lunch or a break, when I'm not using it because I'm pair programming
with someone else, or when I happen to see some interesting changes come
through. I can do it on branches too, as and where necessary.

With everybody doing this you have CI without sysadmin load, it's
focused where it needs to be, you save a server or two, and you reduce
your sysadmin load. It's a classic example of a situation where
developing good habits actually works better than trying to build tools
to cover for the results of bad habits.

A lot of people say that "CI can't hurt." But beyond the the time wasted
setting up and administering it, it often drags along things like "you
can't merge a change into master until it's passed CI," which, for good
developers, simply introduces unnecessary and costly delay in to the
release process. (Sometimes really bad delay: do you really need to do
a full build/test cycle after changing a README file that's never read
during the build and test?)

(I've been in organizaitons where though "good practices" such as
CI, "code review," and other things I've had my development speed
drastically reduced with no increase whatsoever in quality--in fact, it
probably decreased it because it was such a pain to make improvements
that I would tend to avoid making small fixes that I knew were going to
sit around for ages without being merged, and eventually grow stale.)

cjs
-- 
Curt Sampson         <cjs@example.com>         +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch