Tu veux dire que tu as migré vers l'un des sus-nommé ou vers
Stream ?
Vers Stream
Je serais intéressé d'un retour d'expérience d'une entreprise
qui utilise une rolling release en prod, chaque fois que j'ai
suggéré l'idée dans mes employeurs précédent j'ai assisté à
une grande levée de boucliée mais sans réel argument
pertinent. Il est facile de séparer OS de base et applis
critiques , de faire
pointer des environnements différents sur des snapshots
différents des repos, d'automatiser des suites de tests.
Alors vu mon employeur, le mandat de mon équipe et surtout la taille du parc et de l'équipe que je soit un bon exemple.
Mais je pense aussi qu'appeler Centos 8 une "rolling release", c'est comme dire qu'un avion est une automobile parce que ça peut se déplacer sur une route.
Centos 8 a des tests de QA automatisé, une promesse de compatibilité binaire via RHEL, et une politique de ne pas mettre à jour de façon disruptive. C'est ni Rawhide, ni Debian Unstable ou les devs vont mettre à jour sur la derniére version d'upstream, dont le but est de preparer la prochaine stable, etc.
Centos 8 stream est déjà stable (au sens figé), et la seule différence avec avant, c'est d'avoir les mises à jours de sécurité et de bugfix au fil de l'eau, donc de ne pas attendre que RHEL fasse une release, ce qui est pour moi un bonus.
Si un bug passe dans Centos Stream 8, le bug aurait fini par arriver dans la version stable mais plus tard, il y a pas de magie. Et vu que Centos n'a pas de support pour les versions mineurs autre que la dernière, tu es quand même obligé de mettre à jour pour la sécurité. Prendre une version mineur et appliquer les correctifs 1 par 1, c'est ni supporté, ni supportable, vu que tout est construit en visant les derniers RPMs. Ça marche sans doute plus parce que les paquets ont des modifs minimums plus que par un design particulier de la distro.
Ensuite, la ou je peux imaginer qu'une rolling release importen, c'est ce qui est hors de la distribution. Par exemple, le kernel ne garanti pas son ABI (même dans les LTS, etc), donc les gens qui dépendent de drivers externes ont sans doute peur de soucis (souci qui existe deja de base avec une mise à jour de sécurité avant, vu que l'ABI est toujours non garanti).
De même, Centos ne va tester que la distribution, si un produit proprio externe dépend d'un truc non documenté, ça peut casser. Mais pareil, ça aurait fini par casser à tout moment lors d'une mise à jour de sécurité.
Donc moi, j'ai ni l'un, ni l'autre, donc quand on m'a dit "tu vpeux avoir des bugfixes plus vite, et faire des PR plutot que d'aller faire chier les products managers/owners", j'ai dit "banco".
[^] # Re: Et toujours LA question
Posté par Misc (site web personnel) . En réponse au lien Goodbye CentOS 8 and Thanks for Everything!. Évalué à 3.
Vers Stream
Alors vu mon employeur, le mandat de mon équipe et surtout la taille du parc et de l'équipe que je soit un bon exemple.
Mais je pense aussi qu'appeler Centos 8 une "rolling release", c'est comme dire qu'un avion est une automobile parce que ça peut se déplacer sur une route.
Centos 8 a des tests de QA automatisé, une promesse de compatibilité binaire via RHEL, et une politique de ne pas mettre à jour de façon disruptive. C'est ni Rawhide, ni Debian Unstable ou les devs vont mettre à jour sur la derniére version d'upstream, dont le but est de preparer la prochaine stable, etc.
Centos 8 stream est déjà stable (au sens figé), et la seule différence avec avant, c'est d'avoir les mises à jours de sécurité et de bugfix au fil de l'eau, donc de ne pas attendre que RHEL fasse une release, ce qui est pour moi un bonus.
Si un bug passe dans Centos Stream 8, le bug aurait fini par arriver dans la version stable mais plus tard, il y a pas de magie. Et vu que Centos n'a pas de support pour les versions mineurs autre que la dernière, tu es quand même obligé de mettre à jour pour la sécurité. Prendre une version mineur et appliquer les correctifs 1 par 1, c'est ni supporté, ni supportable, vu que tout est construit en visant les derniers RPMs. Ça marche sans doute plus parce que les paquets ont des modifs minimums plus que par un design particulier de la distro.
Ensuite, la ou je peux imaginer qu'une rolling release importen, c'est ce qui est hors de la distribution. Par exemple, le kernel ne garanti pas son ABI (même dans les LTS, etc), donc les gens qui dépendent de drivers externes ont sans doute peur de soucis (souci qui existe deja de base avec une mise à jour de sécurité avant, vu que l'ABI est toujours non garanti).
De même, Centos ne va tester que la distribution, si un produit proprio externe dépend d'un truc non documenté, ça peut casser. Mais pareil, ça aurait fini par casser à tout moment lors d'une mise à jour de sécurité.
Donc moi, j'ai ni l'un, ni l'autre, donc quand on m'a dit "tu vpeux avoir des bugfixes plus vite, et faire des PR plutot que d'aller faire chier les products managers/owners", j'ai dit "banco".