12:59 p.m.
I am not sure weekly or even daily releases will help us get work done.
The main reason for this is that we are spread very thin - 1 or 2 people per
component (with the exception of metrics that has whopping 4 devs).
The devs need to split their time between developing new stuff, integrating
with the changes in other components their components depend on and integrate
their changes into hawkular proper and/or any glue component (agent for
example) (and yes, component owners should be doing that, because we develop
Hawkular, not the individual components).
I don't share Stefan's need for a "release engineer" - release takes up
to 1
minute on commandline + a minute in Nexus + maybe 5mins on writing release
notes. I am willing to do that twice a week no problem.
But I don't think it will help much.
The dev/inventory-0.2.0.Alpha1 branch has been open for I think 2 weeks now
but that is not because there were so many little changes to accommodate. It
was rather that agent + UI + pinger need to accommodate to 1 huge refactoring
that has taken place in inventory.
The problem with inventory (and I am not sure about the rest of the
components) is that such refactorings are quite common nowadays exactly
because of the release early release often paradigm - we introduce new
features while we KNOW they will need to be refactored in the future when
another feature catches up and requires that change to happen.
This happens with the agent, too. Because it usually waits for features in inv
and metrics, it just starts to use what's available at given moment to get a
job done, while we know it will have to be reworked once the rest of the
components catch up - think resource hierarchy, operations, etc.
I can't say I have a recipe to help with that situation.
The only thing I think can at least partially work is to allow enough time for
the integration to happen - i.e. the version of the component to be included
in the next milestone needs to be released at least 2 week before the
milestone release.
But that has the problem of interdependent components making breaking changes
and trying to go forward in a lockstep - how can one component be sure the
other component will be released in time so that they both can go into the
next milestone? Beats me, I just can't say.
The release-per-week is akin to the agile "release-train" approach, IMHO,
which implies varying scope of the releases - something I agree with in
Stefan's email - the arbitrary features being required of the milestones are,
well, arbitrary and generally cannot be fulfilled with a time-bound release
policy (we work towards them but there cannot be a guarantee they will be
finished in time).
All in all, I think the struggle we are currently going through is just the
process of finding the balance between agility and stability. I am not sure it
can be simplified in a world of distributed semi-independent components - it
just has to be found ;)
We can try weekly releases, we can try giving the milestone integration two
weeks to settle, we can try release per commit.
We will either find the balance or find that balance itself is a moving target
;)
On Tuesday, July 21, 2015 11:38:58 Heiko W.Rupp wrote:
Hey
I have observed that our current Hawkular cadence of 4 weeks
with similar cadences of components makes us end up with
long living integration branches and a larger rush near the
end to integrate them, get them for the first time tested in CI
and even for the first time tested in real world.
In one of the last releases there was a changed implementation
in one component, that basically turned out as a no-op and
still returned a "200 OK" code, so clients thought everything is
happy, but it was not. We found the issue (through ppl looking
at the UI) and solved it, but it was in a rush.
This certainly goes against all the ideas of "release early, release
often", "cut small slices", "changes go into CI/CD and go live
quickly".
Remember the coin flipping ?
Ideally we would always be able to integrate changes from
components into Hawkular (main), but I understand that with the
way maven and its release process to central works, it is also not
ideal to release many versions per day.
With all of the above in mind, I propose that we move to a
"at least once per week" model, where we do a component release
at least once per week(*), which then in the four week stream form
a new Alpha release. The smaller releases do not need release notes,
I don't care if we use the micro number or a .AlphaY designator on
them, but they should be a release, that is not a (named) snapshot.
This will allow us to still have less efforts to do releases, but
keep being (more) agile and have earlier integrations and thus
less long living integration branches.
On top of that, we need to provide new and/or changed apis(**)
early on in the 4 weeks cadence so that other components can
already start calling them, even if they are not yet functionally
complete.
*) Of course only if a change to the component has been made.
**) Ideally with changed apis, we keep the old version around for
a bit and offer the new version on top. Remember, that especially
with non-compiletime bindings, we can not know which client is
at what api version.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev