4 ms·

You realise that everyone pushing changes to main several times a day is the definition of CI? and it's pretty much impossible to do with code review as a gate

You realise that everyone pushing changes to main several times a day is the definition of CI? and it's pretty much impossible to do with code review as a gate for pushing to main. Interesting how CI has become semantically diffused to mean literally the opposite of CI: tooling and processes that delay integration and make it easier to work in isolation. https://wiki.c2.com/?ContinuousIntegration https://wiki.c2.com/?ContinuousIntegration " The most granular unit of integration should be one step of one refactor. "

5e92cb50239222b 5y ago
CI is more than that, at least in my understanding of the term. You have to have some sort of automated testing before doing the merge. We were doing the same shit (all pushing to the same branch) and it broke constantly before we introduced some tests and merges only after a successful test run on a separate CI server. Just pushing everything into the main branch without any checks is no CI, even if it technically can be called so.
- CaveTech 5y ago
  That's `automated CI` which is now or less interchanged with just `CI`, however at face value there is no requirement that all CI be automated, it is just usually better to do so.
  - Jtsummers 5y ago
    For anything non-trivial (read: more than around 10-20k SLOC of C or equivalent; straightforward with minimal branching logic; non-critical) you cannot, in any practical sense, have CI without automation. Unless, of course, you want a garbage system. If you do the minimum things necessary to ensure the system is correct (in both verification and validation senses) and of decent quality, and you have no automation, you will not have CI because you will introduce delays between code change and deployment ranging from days (for smaller projects) to weeks or months (for significant projects). That delay means you do not have CI. And it also encourages batching many changes together so that you only have to have one test run (or a small number of test runs) which is also the opposite of CI. Now, you could bypass all those tests and reviews and just deploy it anyways. And then you'll have a shitty codebase, but you'll have CI so that's good, right?
    - CaveTech 5y ago
      I'm not advocating for this from an engineering perspective, just stating that it does meet the semantic root of `CI`, regardless of whether you believe it meets _your_ threshold of "good" CI.

5e92cb50239222b 5y ago

CI is more than that, at least in my understanding of the term. You have to have some sort of automated testing before doing the merge. We were doing the same shit (all pushing to the same branch) and it broke constantly before we introduced some tests and merges only after a successful test run on a separate CI server. Just pushing everything into the main branch without any checks is no CI, even if it technically can be called so.

CaveTech 5y ago
That's `automated CI` which is now or less interchanged with just `CI`, however at face value there is no requirement that all CI be automated, it is just usually better to do so.
- Jtsummers 5y ago
  For anything non-trivial (read: more than around 10-20k SLOC of C or equivalent; straightforward with minimal branching logic; non-critical) you cannot, in any practical sense, have CI without automation. Unless, of course, you want a garbage system. If you do the minimum things necessary to ensure the system is correct (in both verification and validation senses) and of decent quality, and you have no automation, you will not have CI because you will introduce delays between code change and deployment ranging from days (for smaller projects) to weeks or months (for significant projects). That delay means you do not have CI. And it also encourages batching many changes together so that you only have to have one test run (or a small number of test runs) which is also the opposite of CI. Now, you could bypass all those tests and reviews and just deploy it anyways. And then you'll have a shitty codebase, but you'll have CI so that's good, right?
  - CaveTech 5y ago
    I'm not advocating for this from an engineering perspective, just stating that it does meet the semantic root of `CI`, regardless of whether you believe it meets _your_ threshold of "good" CI.