Show HN: How to Get Started with Continuous Integration
fire.ci
fire.ci
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.
Would love for you to check it out and give any feedback that you can!
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.
I have to keep merging upstream whenever upstream changes?
Some PRs are open for days.
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.
> 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
Our build is ~30 mins ( not ideal but not uncommon either)
* 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).
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.
Getting from here to there probably requires a transition phase. In the long run though, if the time spared/lost waiting for PRs, developers context switching, resolving conflicts and dealing with errors (that will appear anyway) is invested into improving the quality and speed of automated tests, you end up in a much better place.
I'm not saying it's an easy thing, but in my opinion this is what development teams should strive for.
Which CI tools do this?
A great explanation of how hard feature branches are to manage. But surely better architecture would alleviate that pain...