3 ms·

"Passing CI" is a low bar -- it is only a single layer of defense. Moreover, code has syntactic properties that aren't necessarily evaluated by CI. My comment c

by rvrs 3y ago

"Passing CI" is a low bar -- it is only a single layer of defense. Moreover, code has syntactic properties that aren't necessarily evaluated by CI. My comment claimed that there are readability and usability concerns with unfinished code. This is why we have code review. CI is a signal that the code is good to merge, but as a code reviewer, I have the final say. I don't merge unfinished code. If CI passes on your branch but later fails due to lagging behind master, it is on you to get it working before re-requesting review. PS: The HN guidelines clearly state "Be kind. Don't be snarky." (:

gizmo686 3y ago
Continous Integration is a development methodology, not an automated process. The idea is that developers continuously merge their changes into a shared integration branch. Having long running feature branches that get merged when they are done is a valid methodology, but it is not continuous integration; no matter what your automated build and test pipeline calls it. In practice, I have typically seen CI done with either feature freezes, or release branches to allow creating versions where everything is complete.
hinkley 3y ago
> If CI passes on your branch but later fails due to lagging behind master, That’s the problem, which I already stated before the question. That’s not integration, that’s a build. Integration is testing your changes with all the code around it. Specifically, it’s about testing your changes with changes that started after you began writing your code. Only small changes land in anything like chronological order. On real codebases, even with low to moderate coupling, the rug can get pulled out from underneath of you without you even noticing until something bad starts happening. CI is about exposing your code to feedback at the earliest possible moment, so you 1) don’t continue to build on violated assumptions, 2) you do lots of small merge operations instead of one big one and 3) the thoughts that began the trouble are still fresh in your head. Consequences of decisions become abstract over time. Nobody changes their behavior based on 1 year old bugs found in their code. Long lived branches are a crutch. It’s avoidant behavior. If you can’t figure out how to make your code work with everyone else’s, why do you think waiting longer will make things better? It doesn’t. The mess just gets bigger. I’ve seen it over and over again. The guys who won’t merge early are full of delusions about their own work that doesn’t match up with the bug and incident count. They call it bad luck.

by rvrs 3y ago

gizmo686 3y ago

Continous Integration is a development methodology, not an automated process. The idea is that developers continuously merge their changes into a shared integration branch. Having long running feature branches that get merged when they are done is a valid methodology, but it is not continuous integration; no matter what your automated build and test pipeline calls it. In practice, I have typically seen CI done with either feature freezes, or release branches to allow creating versions where everything is complete.

hinkley 3y ago

> If CI passes on your branch but later fails due to lagging behind master, That’s the problem, which I already stated before the question. That’s not integration, that’s a build. Integration is testing your changes with all the code around it. Specifically, it’s about testing your changes with changes that started after you began writing your code. Only small changes land in anything like chronological order. On real codebases, even with low to moderate coupling, the rug can get pulled out from underneath of you without you even noticing until something bad starts happening. CI is about exposing your code to feedback at the earliest possible moment, so you 1) don’t continue to build on violated assumptions, 2) you do lots of small merge operations instead of one big one and 3) the thoughts that began the trouble are still fresh in your head. Consequences of decisions become abstract over time. Nobody changes their behavior based on 1 year old bugs found in their code. Long lived branches are a crutch. It’s avoidant behavior. If you can’t figure out how to make your code work with everyone else’s, why do you think waiting longer will make things better? It doesn’t. The mess just gets bigger. I’ve seen it over and over again. The guys who won’t merge early are full of delusions about their own work that doesn’t match up with the bug and incident count. They call it bad luck.