Am 25.11.2014 um 20:28 schrieb mike thompson
<mithomps(a)redhat.com>:
I guess I was making more of a distinction that we are dev mode right now. Start of a new
project(s). Nothing has been QE’d. Right now, we are releasing about about every 4 weeks
(but no real schedule).
If you have something to commit in that 2 week window then it will become part of the
release. If not, add it to another 2 week window.
This will only work if we stick to a "green master" policy.
See e.g.
http://www.yegor256.com/2014/10/08/continuous-integration-is-dead.html#ho...
and linked blog(s).
There may be technical issues like jenkins / nexus / ... not available that prevent a
green build. But if we take those
aside, but let's put those aside for a moment.
I have seen/done myself commits where I accidentally forgot to commit a new or changed
file and the built failed.
If that goes to master, we have a situation, where basically everyone is blocked as they
can not rebase from master,
the release can not be cut and so on.
So when all development happens on branches / personal repos and requests to include in
master are done as pull-requests,
the CI machinery can build the pull-request (which we have in RHQ and rhq-metrics
already).
And only if this build succeeds a "gatekeeper" (*1) may merge that to master.
There may be situations e.g. if 2 developers work in the same area where a 2nd PR needs to
be re-CI'd and may fail after master + 1st PR, but that still allows to keep master
green.
Luckily with a much more modular overall project (metrics, alerts, msg, .... ) the chance
that people are stepping on the toes are smaller.
Working in a branch / PR fashion does not automatically imply long running branches with
all the potential merge conflicts, but can be still done in small chunks.
In fact we may just live that with breaking features into smaller chunks, one per
"sprint" (there it is :-).
Take alerting for as an example: in RHQ we have probably 8 classes of comparators. We can
develop all 8 in one go in a long run or just have one comparator class per PR. When the
sprint it over, we deploy the result(*2) to a SaaS (*3) and the user can use that first
comparator class. We can get feedback (e.g. on usability) and after the next sprint, the
user can use one or two more and so on.
And if a comparator class takes more than 2 weeks of the sprint to implement it is no
issue, as there are no partial artifacts in master that need "fixing" before
release.
Heiko
*1) this may be mechanical by a script or a human (other than the committer) or ...
*2) In fact there are good number of projects out there that deploy daily or on every
commit or so
*3) while the end goal is of course to have some downloadable .zip to run, deploying to a
well-known place is still appealing