Re: [tlug] TLUG Site with Hakyll Update

[Curt Sampson <cjs@example.com>]

On 2019-03-18 01:57 +0900 (Mon), Stephen J. Turnbull wrote:

> Curt Sampson writes:
>
>  > ...and see if you can add a line to the top-level
>  > "test/build/run/setup/whatever" script instead.
>
> That said, experience with Python setup.py scripts suggests
> diminishing returns set in quickly once you start breaking out pieces
> of infrastructure into separate modules.  It becomes like learning a
> new language for everyone else (and relearning for you if you have to
> come back to it after a few months).

I'd love to hear a talk about this, formal or just over a beer.

>  > but actually the whole idea of CI started long before that
>  > (starting to come to broader attention in the late 90s, with
>  > Extreme Programming, I think)

Sadly I no longer have my copy of the first edition (1999) of Kent
Beck's _Extreme Programming Explained_, so I'm going to have to quote
from the second one (2004). But at that point the idea of DevOps was
still not widespread, AFIK (and certainly the name didn't exist yet).
>From Chapter 7, "Primary Practices":

] __Continuous Integration_
]
] Integrate and test changes after no more than a couple of hours.
] Team programming isn't a divide and conquer problem. It is a divide,
] conquer, and integrate problem. The integration step is
] unpredictable, but can easily take more time than the original
] programming. The longer you wait to integrate, the more it costs and
] the more unpredictable the cost becomes.
]
] The most common style of continuous integration is asynchronous. I
] check in my changes. Soon thereafter, the build system notices the
] change and starts to build and test. If there are problems; I am
] notified by email, text message, or (most coolly) a glowing red lava
] lamp.
]
] I prefer a synchronous model in which my partner and I integrate
] after each pair-programming episode, no more than a couple of hours.
] We wait for the build to complete and the entire test suite to run
] with no regressions before proceeding. [This practice is clearly
] dependent on the immediately preceeding practice, "Ten Minute
] Build." --cjs]
]
] Asynchronous integrations are a big improvement on daily builds
] (especially without automated tests), but they don't have the
] inherent reflection time built into the synchronous style. Waiting
] for the compiler and the tests is a natural time to talk about what
] we've just done together and how we might have done it better.
] Synchronous builds also create positive pressure for a short, clear
] feedback cycle. When I get notified of a problem half an hour after
] starting a new task; I waste a lot of time remembering what I was
] doing, fixing the problem, and then finding my place in the
] interrupted task.
]
] Integrate and build a complete product. If the goal is to burn a CD,
] burn a CD. If the goal is to deploy a web site, deploy a web site,
] even if it is to a test environment. Continuous integration should
] be complete enough that the eventual first deployment of the system
] is no big deal.

Now back to Steve:

> I'm pretty sure Microsoft "nightly builds" go back to the same era
> (at least the early 90s).

So it's debatable whether those nightly builds should really be
considered "continuous integration"; you can see that above Beck
pretty clearly thought that it wasn't: "Asynchronous integrations are
a big improvement on daily builds." No doubt a full build of MS
Windows was more than a ten minute process, and might have required
all night, but in a situation like that I'd be finding further ways to
integrate more often, such as building smaller parts (but larger than
what just one pair of developers is workign on) at least every hour or
two, and linking those smaller parts to yesterday's build of all the
rest in order to run tests on them.

> I can't speak to the "broader attention" aspect, but Lucid (of Emacs
> and Energize fame, or "historical interest" to the youngsters :-) was
> doing this in the late 80s, and the Lisp machine folks were doing it
> even earlier.

I'd imagine that a proper integration test would involve booting up a
Lisp machine from scratch with the current code. That clearly would be
an overnight thing. :-)

> On the other hand, if you mean more than just the syntax checks that
> linkers do, really I would put it much later with the "devops"
> movement, when people started putting nightly builds into production
> and claiming they passed QA. ;-)

There's pretty much no question that they passed QA, though the wise
consumer might want to ask what that QA involved. :-)

But even with no QA beyond "I turned it on and it didn't explode,"
this is a surprisingly large step for many organizations, even now. I
am still seeing teams regularly ignore deployment until the last
minute and then discover it's going to take them two weeks to set up
their "completed" software to be usable by the client. Thus the last
paragraph in the long quote above, and why in my world test-driven
development (write the test before you write the code) now has,
wrapped around it, "production-driven development" (write your
deployment system before you write the test).

That said, though it's not explicitly stated in the Beck quote above,
that everything should have automated tests is so deeply embedded in
XP makes it resonable to assume that running a real test suite (far
beyond "just the syntax checks that linkers do") would be a given.

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

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