Define release process improvement process

ghost commented 5 years ago

Created on 2019-05-22 by José Cortina (@jose-cortina).

Decision log

Name	Description
Title	Define release process improvement process
Ultimate decision maker(s)	Kyma Council
Due date	2019-05-31
Status	Proposed on 2019-05-22
Input provider(s)	Jose Cortina (@jose-cortina)
Group(s) affected by the decision	Kyma teams
Decision type	Binary
Earliest date to revisit the decision	2019-08-01
Affected decisions

Context

Everyone involved with Kyma is also involved in the releases, depending on their role, with more or less involvement. For each release, one of the Kyma teams is designated as the Release Master meaning that the responsibility of creating the release (i.e. the release execution) is in their hands for a particular release.

The release execution is understood as the process starting with the creation of a release branch and completing with the publication of the final (stable) release in GitHub, following the release process documented in the release guidelines.

During the release execution the release master identifies potential improvements and for further automation in this process, but there is not yet a formal way of dealing with their feedback and improvement ideas. This was raised in a retrospective, suggesting then to formalize this, resulting in this decision.

The ultimate goal is to reduce the time it takes to execute each release, to the extent that it is possible to do a release with a single click. At the time of writing this proposal, there are a number of steps to follow (and at least 10 must be completed manually).

Decision

During the release execution, the release master will raise and document issues (labeled under quality/release) about potential improvements to the release process. Once the release has been completed, the team executing the release will then refine the Backlog and then work on implementing issues from the top of the priorities.

Within the refinement of the Release Backlog, the team should consider the implementation estimation as well as the estimated time save on manual work after the implementation, and make a decision (together with the Release Manager and the previous release master) of the issue(s) bringing the most value to be prioritized.

The team will invest time in the implementation of a release improvement. It will be ensured that the implementation is done before the next release execution starts.

With this, the release process will always be better than on the previous release, and the responsibility (and workload) of these improvements will be distributed among the teams avoiding to have this laying on a single person, team or SIG.

Consequences

The team assuming the responsibility of release master already plans the effort required to execute the release, and will add time for release improvements to this estimation.
Improvements to the release will be documented as GitHub issues labeled under quality/release and maintained in the release Backlog.
The release master team ensures that at least one issue is done and available for the following release. This includes not only the implementation, but also corresponding testing and documentation as applicable.

uschulle18 commented 5 years ago

Can we please do in addition 2 things: make a dashboard were we show for each release:

nr. of days we needed for executing the release
effort needed to finish the release

uschulle18 commented 5 years ago

How do we bring together the documentation of the release strategy in Wiki with the documentation in this proposal?

ghost commented 5 years ago

@uschulle18 If the proposal is accepted, the release strategy and release process will be adjusted accordingly. For now, this is only a proposal ;-)

derberg commented 5 years ago

to summarize, this proposal is about agreeing that release master is taking care for release improvements prioritization, right? and that current release team respects that?

ghost commented 5 years ago

@derberg Priorization is decided between the current release team/master, the previous release team/master and the Release Manager. The idea is also to have a level of consistency or direction and not necessarily going in completely different directions every time (or at least to make this a conscious decision).

mareknawa commented 5 years ago

@jose-cortina are you going to extend release process document with the additional activities required from release master? I think Release process is the main instruction which takes each team to implement release. If we want them to respect the above requirements they must be able to find the requirements in that instruction.

stale[bot] commented 5 years ago

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

kyma-project / community