Après réflexion, je pense qu'il est important qu'Alex lise et valide ça aussi (après tout ils ont longuement travaillé sur des sujets très similaires). Je crois qu'il est nécessaire que nous nous comprenions parfaitement entre DT et QA avant de diffuser aux autres services, par conséquent, et afin que je puisse être compris par tout le monde (Roumanie inclue) je vais rédiger cette réponse en anglais.
I think the mail is not specific enough about the process, I will try to write a exhaustive list of all possible cases.
We chose to have merges and releases done at specific dates. Here is a diagram representing this ideal situation:
This seems nice and clean but it assumes that the number of features the dev team can produce in one month corresponds exactly to the number of feature the QA can test. What happen if it's not the case? Two situations are possible (regardless of the reasons):
- QA is late
- QA is early
In that case we get the following diagram:
We clearly see that when the monthly merge from develop to release happens, QA is not yet done with its testing session (this is represented with a red part called "lateness"). Consequently, QA has to deal with both the remaining features from last cycle and those coming from the next one. Lateness accumulates and there is little to no chance for the next release not to be aborted again.
In that case we have no way to adapt QA's workload which is the opposite of what we want.
In that case we should adjust the next batch of feature accordingly to the past performances. Doing this ensure that everything is tested but each time we do this, we increase the gap between a feature development and a release. For example, in the previous diagram we clearly see that the gap between n+1 development and n+1 release is approximately 80 days long.
This solution ensure that the QA has a adaptable cycle but it limit our capacity to ship quickly.
This situation is very similar to the previous one but the gaps can shrink if the QA goes faster than the dev team or grow if not.
This case is less problematic than the previous one but we still have to consider each case.
In this scenario, the QA is idle a fraction of each month because the dev team does not deliver enough feature to test. We could use this time to do other things like A/B testing or limit testing or even developing QA related projects.
This scenario is the same as when QA is late but in reverse. We just release whatever we have when it's ready. In this situation, if the QA stays quicker than the dev team we end up doing continuous delivery since that when the dev team delivers a new feature, the QA can test it immediately.
Having said that, I think we should be clear about which scenario we decide to use before communicating with anyone.
La branche release sera alimentée à partir de la branche develop en fin de mois (n jours ouvrés minimum avant la livraison en recette).
I don't think that it should be the case. As Xavier said, I think we should feed release on QA's demands and not at the end of the month. Moreover I think that QA should merge the features themselves, no need for them to ask us to do it, it will only slows down the process for no reason.
La demande de création sera faite par la QA : demande de merge develop => release
I don't think that we need a "creation request" from the QA. We will only create the release branch once, after that release will be fed from develop with merges.
La date de livraison étant fixe, le contenu d’une release correspond aux chantiers mergés sur develop en fin de mois.
I'm not sure I understand this correctly. The next release content should contain any number of features which are at least after the last merge of release into master.
Ne pas déployer la release, développer/tester le hotfix, refaire une release et la déployer
I don't understand this option.
Finally, I think that there is an error in the gitflow diagram. The last release commit is a merge of develop and is merged directly into master.
Voilà, désolé pour le pavé mais je pense qu'il est important qu'on soit tous synchronisés sur ce qu'on va faire.