Release strategy discussion - summary

[mwalker5000]

On Feb 7 2023, @springdo @ckavili @oybed @bchardim Michael Phillips, Roberto Barajas and @mwalker5000 met to discuss the release strategy to support Learning-led runs of DevOps Culture and Practice Enablement globally.

The team recognized we need to:

1. Have a way to identify a release that is stable and repeatably run globally for 6-12 months without requiring changes, maintenance, or re-training of facilitators.
2. Have a way to create new releases from time to time to get the most up-to-date content. This might occur every 6 to 12 months in 2023, and maybe much more frequently in the future.
3. Avoid creating and maintaining repository forks that might introduce breaking changes that prevent us from using the newest and best upstream content in the future.

The team decided that for each GLS-supported release, we will:

1. Create a release tag that will be used by our Learning team to identify stable, tested releases that have passed GLS QA as well as all the nightly build tests, and are deemed fit for the GLS environment and fit for global delivery, by the GLS team.

When problems are found with the release, the GLS team will:

1. Create a fix in main (not in a branch)
2. Put a new release through testing and QA, which may incorporate additional changes that have been made since the release was tagged
3. Go through the release process, performing necessary changes to GLS infrastructure, books, etc required to support the new release
4. Tag a new release

Going forward:

• We will use this strategy and reconnect as a team in 6 months to see how it's going.
• We will meet sooner, ad-hoc, if we find problems.

Please edit/update/correct anything that is off on my notes, thanks.
Please share with teams as needed, thanks.