Comment by cottonseed | Hacker News Reader

Comment by cottonseed | Hacker News Reader

Parent Full thread

3m seems aggressive to do builds and spin up infrastructure for anything non-trivial.

Reading a bit closer, I see the author describes CI as a sanity check, "ensur[ing] the bare minimum" and doesn't consider deploying on every commit. Maybe 3-7m is more realistic then.

However, I'm slightly surprised by this definition of CI. According to Fowler [0], "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time. ... The key test is that a business sponsor could request that the current development version of the software can be deployed into production at a moment's notice." So having CI gates on the development version that are weaker than the release tests would not seem to be continuous delivery according to his definition.

We're currently releasing on every commit and our CI build (which implements continuous delivery) takes about 15m.

[0] https://martinfowler.com/bliki/ContinuousDelivery.html

> the author describes CI as a sanity check

Which is a nonsense, since CI is the practice of merging to master frequently, in a state that can be released if need be.

We won't understand it unless we distinguish the practice from the supporting tools that help us do it safely:

in this case, the practice is frequent merge to shared trunk, and the supporting tools are as many automated checks before and after that merge as can be done quickly.

A "CI build" of a branch is a tool to help you do CI, but unless you merge that branch when it's green, you're not _doing_ CI.

Misunderstanding this and doing "CI on a branch" means that you are mistaking the tool for the practice, and not doing the practice: by delaying integration, you will be accomplishing the opposite of CI.

Yeah, I totally agree with Fowler’s definition of CI more than I do this article.

In my case it wasn’t a need to spin up infrastructure as much as it was just pulling a few container images and starting them, the longest of the CI builds were if you were say loading and indexing test data from a database (container) into ElasticSearch etc... but overall moving images around and starting containers to build and test some ruby / python was usually around 1-3 minutes or there abouts.

Hey, I've been working on a CI tool that skips the "non-trivial" bits for arbitrary Linux workflows, would love your feedback: https://layerci.com

Is this doing anything else than leveraging Docker multi layers caching?

Agree. CI=3-7 minutes. CD can be 30-60 if needed.

Reply on news.ycombinator.com