Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: How to Get Started with Continuous Integration

fire.ci

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Show HN: How to Get Started with Continuous Integration

#11

Post by mig4ng »

> 15 minutes later you get a failed build notification. You need to switch back to the previous task, try to fix the issue … and go for another 15 minutes loop …

The 3 minute rule is probably one of the most important in the article in my opinion. I have worked with workflows that were longer than 3 minutes (10min+-) and I find that I either went do something unproductive or I started another task. The times when I started another feature and later got interrupted by the previous one because of this were probably 90% of them. This had major impact in my productivity.

Therefore I agree that the workflow should be as quick as possible in order for developers not to lose focus and the flow. The flow state boosts productivity by more than double for myself. And these notifications to go into the previous task break that flow more often than not.

Regarding working on a feature toggle oriented workflow I never had the privilege of working in such environment, but from what I read in this and other articles/books it provides a better work environment for the developers. If anyone has a project like this I would love to experience that and learn more about it.

Re: Show HN: How to Get Started with Continuous Integration

#12

Post by dominotw »

jpdel wrote: post #8
dominotw wrote: post #6

Earlier quoted context omitted.

> ci runs tests on merged code and says its ok > main branch moves ahead now merged code doesn't pass tests. > ci still says merged code is good to go > user performs merge > main branch is broken

4th step should not happen. A cool feature I am implementing into fire.ci now is that it will trigger a new build every time the main branch moves forward until the safe merge happens. If you have fast builds I don't expect this to take more than 2 builds each time (or you have a huuuuge team working on the repo). What do you think?

Main branch on the repo I am working on now has 23 PRs. Every merge would trigger 24 builds ?

Our build is ~30 mins ( not ideal but not uncommon either)

Re: Show HN: How to Get Started with Continuous Integration

#13

Post by chusk3 »

dominotw wrote: post #7
chusk3 wrote: post #5

Earlier quoted context omitted.

For me the right way is never to allow non-ff merges and instead require all changes to be integrated into your branch (either via rebase or merge from base into your branch) before merging. GitLab supports this flow nicely and it has been wonderful for ensuring that the resulting product passes tests.

what happens if I am waiting for my PR to merged. I have to keep merging upstream whenever upstream changes? Some PRs are open for days.

Right now I have a one button rebase operation in gitlab, and if that does work (due to conflicts) then I'm at a situation I want to be in: verifying that my changes integrate cleanly.

Re: Show HN: How to Get Started with Continuous Integration

#14

Post by jpdel »

dominotw wrote: post #12
jpdel wrote: post #8

Earlier quoted context omitted.

4th step should not happen. A cool feature I am implementing into fire.ci now is that it will trigger a new build every time the main branch moves forward until the safe merge happens. If you have fast builds I don't expect this to take more than 2 builds each time (or you have a huuuuge team working on the repo). What do you think?

Main branch on the repo I am working on now has 23 PRs. Every merge would trigger 24 builds ? Our build is ~30 mins ( not ideal but not uncommon either)

Nope.

* PR1 is merged with main branch commit N: build OK. PR1 is merged creating main branch commit N+1 * PR2 is merged the same way creating commit N+2 * PR3 build started at the same time as PR2 build, so using main branch commit N+1 * By the time PR3 build is finished and green, head of main branch is commit N+2. So it's not safe to merge * A new build is automatically started for the merge of PR3 and main branch commit N+2. If it's green, it is merged, created main branch commit N+3.

See what I mean? (and obviously I can't figure out how to make bullets in this editor sorry ...)

With a build lasting 30 minutes, cases like PR3 above are more likely to happen. But then it doesn't really matter: the build tool will just run builds until it merges. The real issue here is the delayed feedback for the developers: if you are interrupted every 30 minutes with some build status (green or red), it's quite a waste of time daily in terms of context switching.

What CI tool and Git provider are you using? Lately I've worked with a team with a build of 28 minutes using TFS VSTS. We got the build down under 10 minutes using conditional builds (tests ran only if some folders have changed).

Re: Show HN: How to Get Started with Continuous Integration

#15

Post by jpdel »

dominotw wrote: post #12
jpdel wrote: post #8

Earlier quoted context omitted.

4th step should not happen. A cool feature I am implementing into fire.ci now is that it will trigger a new build every time the main branch moves forward until the safe merge happens. If you have fast builds I don't expect this to take more than 2 builds each time (or you have a huuuuge team working on the repo). What do you think?

Main branch on the repo I am working on now has 23 PRs. Every merge would trigger 24 builds ? Our build is ~30 mins ( not ideal but not uncommon either)

And now that I look at your question again: yes. If all 23 builds were green and one person merges, then it would trigger a build on the remaining 22. The thing being that you probably shouldn't have 23 PRs lying around (probably waiting for code review).

Re: Show HN: How to Get Started with Continuous Integration

#16

Post by paulddraper »

contravariant wrote: post #10
dominotw wrote: post #6

Earlier quoted context omitted.

> ci runs tests on merged code and says its ok > main branch moves ahead now merged code doesn't pass tests. > ci still says merged code is good to go > user performs merge > main branch is broken

>Your CI tool should perform a local merge of your branch to the main branch and run the build and tests against that. Your branch can then be automatically merged if the main branch does not change in the meantime. If it does change, the CI checks should be run again until your code can be safely merged. If your CI tools does not support this kind of workflow, change your tool.

> If your CI tools does not support this kind of workflow, change your tool

Which CI tools do this?

Re: Show HN: How to Get Started with Continuous Integration

#17

Post by dominotw »

jpdel wrote: post #15
dominotw wrote: post #12

Earlier quoted context omitted.

Main branch on the repo I am working on now has 23 PRs. Every merge would trigger 24 builds ? Our build is ~30 mins ( not ideal but not uncommon either)

And now that I look at your question again: yes. If all 23 builds were green and one person merges, then it would trigger a build on the remaining 22. The thing being that you probably shouldn't have 23 PRs lying around (probably waiting for code review).

Yeah I think what you are suggesting might work if team follows * merge PR asap * keep build time down to n mins.

But its extremely common in big projects to have atleast 20 prs open with long build.

kubernetes has like 1100 open prs atm ( each pr with 5 25 min builds). What should a project like k8s do for CI ? would require insane computing power to launch 5000 builds for every merge.

Re: Show HN: How to Get Started with Continuous Integration

#18

Post by dominotw »

chusk3 wrote: post #13
dominotw wrote: post #7

Earlier quoted context omitted.

what happens if I am waiting for my PR to merged. I have to keep merging upstream whenever upstream changes? Some PRs are open for days.

Right now I have a one button rebase operation in gitlab, and if that does work (due to conflicts) then I'm at a situation I want to be in: verifying that my changes integrate cleanly.

I am not too familar with gitlab. But I am assuming that button click triggers another build ?

So its not just 'one button rebase operation' its 'one button rebase and wait for build to finish operation' before it can be reviewed again.

Re: Show HN: How to Get Started with Continuous Integration

#19

Post by bullcitydev »

mig4ng wrote: post #11

> 15 minutes later you get a failed build notification. You need to switch back to the previous task, try to fix the issue … and go for another 15 minutes loop … The 3 minute rule is probably one of the most important in the article in my opinion. I have worked with workflows that were longer than 3 minutes (10min+-) and I find that I either went do something unproductive or I started another task. The times when I s…

Not to hijack the OPs post, Fire CI looks like a great tool! I recently released my open source feature toggle project, Flipt (https://github.com/markphelps/flipt), that allows you to implement feature flags in your existing environment.

Would love for you to check it out and give any feedback that you can!

Re: Show HN: How to Get Started with Continuous Integration

#20

Post by chusk3 »

dominotw wrote: post #18
chusk3 wrote: post #13

Earlier quoted context omitted.

Right now I have a one button rebase operation in gitlab, and if that does work (due to conflicts) then I'm at a situation I want to be in: verifying that my changes integrate cleanly.

I am not too familar with gitlab. But I am assuming that button click triggers another build ? So its not just 'one button rebase operation' its 'one button rebase and wait for build to finish operation' before it can be reviewed again.

Yes, that's the case. However there's also the 'merge this when the build successfully completes' that means you can push one button and walk away. They are also developing features around MRs that 'ripple' in this way, so that when you have several going the rest will continue rebasing+building until they either fail the build (due to changes that are no longer correct), can't be rebased (due to a need for conflict resolution), or finally merge successfully.
Post reply on HN