This work is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.
→ integration testing
→ components interaction
many new features, many new tests
automated tests, local retries
automatic → semi automatic testing
|probability false negative single test||3%|
|number of tests||100|
|probability "success" whole suite|
→ only one out of 20 will pass as it should
"succes" = true positive
let number of independent retries per test
Expected successful outcome for and
more tests → exponential increase of likeliness for false negatives
compensate by retrying single tests just a few times
→ retrying is not an anti-pattern
→ it can be a necessity
→ it worked
frequent code pushes interfere
"REST-like style API" → not much like REST
considerable effort and maintenance
→ Jenkins and "CI-X" just aren't made for this
homegrown solution, started in spring 2013
ready to use in fall 2013, never looked back
jobs can be triggered and can depend on each other
cider-ci.yml file in the project
jobs: deploy_test: name: Deploy to test depends-on: - type: job job: integration-tests states: [passed] run-on: - type: branch include-match: ^master$ # specify tasks etc
The source is the truth.
configuration: reproducible, reviews, audits ???
Cider-CI "knows" about commits, branches, submodules,…
tree-id: fingerprint of your source code
job: container and state aggregate for tasks
Retrying randomized tests can hide problems!
"Generative Testing" e.g.
task specifies required traits, e.g: [
executors advertise available traites, e.g. [
Cider-CI will determine a suitable executor.
it is about making the hard possible, and not not about making the simple easy*
→ swiss army knife for devops
*see "Simple Made Easy" by Rich Hickey