Release management

[DylanVerstraete]

I wanted to post an idea on how we can improve release management of TF grid. Currently, before each release an operational ticket is created, something like: https://github.com/threefoldtech/tf_operations/issues/1489

There are already several issues with this process alone, I'll try to sum them up:

1. Naming convention of this issue is wrong, since we are not only updating tfchain but we are rolling out an entire grid release
2. Every component owner is expected to fill in the version for the component that needs to go live
3. Operations cannot coordinate who does what based on this issue alone
4. Once this upgrade goes live and changes are made to some components, the new version for that component is not tracked

Knowing this, I think we can come up with a better process. Here are some suggestions:

Asign component owners and create a list for internal members

Every component should be listed somewhere with it's respective owner. If a new component is created, it should be added to this list.

Gather information of components before releasing

Before releasing, someone should contact the component owners and gather all versions for all components. From that moment on, we make it clear to everyone that if a new version is created before the release, this person gets notified. This person, pours all this information into an operational issue (an issue for each component) and a tracker issue which links all individual components.

By having an issue for each component, operational team members can assign themself to an issue to let other operational members know that they are in charge of this specific component.

Stop deploying RC versions to testnet

Since testnet is not actually a "real" testnet (this network holds real value) I suggest we stop deploying RC versions to testnet. The problem we faced at 23/03/2023 is that RC versions needed to be deployed but here: https://github.com/threefoldtech/home/blob/master/wiki/products/v3/tfgrid_3.9.0.md only major versions were declared. Then we aksed team members to fill in the right RC version on one operational ticket but not everyone either saw this message or had a version.

Make a list of deployed versions for each network

I think we have a list of deployed versions for each component for each network but this needs to be maintained more actively. This will be the task of the person that also gathers versions for each component before a release.

Define component upgrade order

Now, components are not upgraded in order to minimize downtime, some components can be upgraded before others so we can define this.

Changelogs for each component

With a major release, a descriptive changelog should be written by the component owner so that the person that gathers all versions can write a definite changelog for a specific grid release.

[robvanmieghem]

I can not agree more with the fact that we have to stop releasing rc versions to testnet. There should also not be qa versions on qanet imho, yes, you can have alpha, beta and rc versions on devnet and qanet but before a release goes to testnet, qanet should also have final versions.
I also agree with the rest of your proposal.
Another thing I would like to see is having a toml file ( so it's machine readable) for every grid release with all component versions.
If operations wants to maintain a list of deployed component versions for each network, that's fine but from a release mgmt perspective, it should just be a grid release version.

[PeterNashaat]

• I fully support that someone should get in touch with component owners. and provide versions list even if it was in something simple like excel sheet!.
• Components owner should give the go-ahead with a full list of "deployment changes", such as what is new and how to use it, and what is no longer required.
• It would be even better if we could unify all component versions so that, for example, if we update to 3.9, all components will also be at 3.9, We have too many versions to follow.
• No update requests just prior to the weekend as some component owners may not be available during the update.

[sabrinasadik]

@xmonader @rkhamis pls look into this and lets discuss