5 ms·

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, "e

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 https://martinfowler.com/bliki/ContinuousDelivery.html

colinchartier 7y ago
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 https://layerci.com
- jpdel 7y ago
  Is this doing anything else than leveraging Docker multi layers caching?
jpdel 7y ago
Agree. CI=3-7 minutes. CD can be 30-60 if needed.
smcleod 7y ago
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.
SideburnsOfDoom 7y ago
> 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.

colinchartier 7y ago

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 https://layerci.com

jpdel 7y ago
Is this doing anything else than leveraging Docker multi layers caching?

jpdel 7y ago

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

smcleod 7y ago

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.

SideburnsOfDoom 7y ago

> 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.