
Show HN: How to Get Started with Continuous Integration - jpdel
https://fire.ci/blog/how-to-get-started-with-continuous-integration/
======
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.

~~~
bullcitydev
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](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!

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

------
indentit
> 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.

~~~
dominotw
> 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

~~~
contravariant
>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.

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

Which CI tools do this?

------
gitgud
_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...

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

