Show HN: How to Get Started with Continuous Integration

https://fire.ci/blog/how-to-get-started-with-continuous-integration/

by jpdel • 7 years ago

49 22 7 years ago

indentit• 7 years ago

Most Continuous Integration tools run the CI build on your branch to say if it can be merged or not. But that is not what is of interest here. If you know what you’re doing there is a pretty good chance that the code you have just pushed is working already! Your CI tool should perform a local merge of your branch to the main branch and run the build and tests against that.

100% this - I've never seen it written down anywhere so concisely before! What's the point in CI running automated tests on only your changes, when you have already done so locally? If you are pushing your changes just to get your unit test results (and code formatting checks etc), you are doing it wrong! :) merging it first makes much more sense / has much more value.

comprev• 7 years ago

Our CI is setup to merge into a local copy the source branch and then build. Devs are encouraged to regularly pull & the latest source branch changes to reduce the chance of their own integration failing.

chusk33• 7 years ago

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.

dominotw5• 7 years ago

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.

dominotw5• 7 years ago

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

jpdel6• 7 years ago

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?

contravariant• 7 years ago

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.

yassinatra• 7 years ago

Really well said, fire.ci looks lit as well!!! Could definitely use it

mig4ng• 7 years ago

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.

bullcitydev• 7 years ago

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!

jpdel6• 7 years ago

Flipt is an interesting concept! I've tracked you down on Twitter. Let's talk when you have time ;)

gitgud• 7 years ago

Long lived feature branches create a false sense of safety and comfort for each developer individually. As the branches drift apart for a long period of time, there is no way to measure how hard it will be to merge it all

A great explanation of how hard feature branches are to manage. But surely better architecture would alleviate that pain...

Show HN: How to Get Started with Continuous Integration

Related Stories