Alex Karasulu wrote:
> - - How often shall a build be done (compile/test, sitegeneration)
We have many possible options. We tried something like kicking CI
after each commit, but it leads to issues (usually, we don't commit
code in one big shot,
Yes this does happen but it's bad practice on our part.
I don't think so. First because when you commit, you usually have
already checked locally that the server is ok (_usually_ => sometime,
this is not the case ;). Second, because doing more than one commit
allows you to comment more precisely what kind of modification you have
done.
I personnally don't really like to commit a big shot of code, unless it
is really closely connected. But as I also fix some javadoc, bugs,
warnings while browsing the code, I like to commit in smaller blocks.
I prefer a build on each commit so it's easier to catch the offending
commit and isolate it to a user who can be informed immediately while
they still have a mental stack in memory.
If you kick a build after each commit, you may have many builds kicked
when a lot of commits are done. I also think that it's quite rare that a
commit break the build (it happens, say, every sic months ...), and when
it does, being able to point the offending commit does not really helps
to fix the breakage, because the offender is generally already sleeping :)
I personally would like to know immediately when I goofed something
while that something is still in my head.
Well, run the tests before committing should be enough, isn't it ?
Don't get me wrong : I don't say that we should fragment commits as much
as possible, nor I say that knowing which commit has broke a build is
useless, I just say that a CI should be an airbag, when the integration
is the safety belt. never commit without fasten your safety belt
(-Dintegration test), and in case you crash the server, the the airbac
(CI) may save your life !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
