[Hawkular-dev] Release cadence

[Lukas Krejci]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev