ils nomment, comme moi, leurs fichiers de backups avec une HORADATAGE à la senconde, et depuis un certain temps, ils lui associent le numéro de version exaact de gitlab.
MAIS ON ASSOCIE JAMAIS une procédure de backup, à une version de logiciel, NON. On doit associer une procédure de backup à un numéro de recette de provision, qui comprend BEAUCOUP PLUS D'INFORMATION que le simple numéro de version du logiciel gitlab.
(et ce à cause du diagramme commutatif au sens de l'algèbre homolgique de l'historique des opérations) => backup et restore sont versionnés, et leur numéro de version esty associé à un numéro de version de recette de provision de gitlab, et non à une version de gitlab.
Ainsi, je dois à l'avenir, nommer mes fichiers de backup à l'aide d'un numéro de version clair, de ma recette provision de l'infrastructure kytes.io , ainsi que nous l'a enseigné le montage des tests pour l'issue conernant la restauration
Le diagamme commutatif de la catégorie des 'exploitations' d'une infrastructure
On suppose que l'on a faut une provision de l'infrastructure, avec le recette de provision en version N.
Une fois la provision en version N, on ne peux effectuer des opérations sur l'infrastructure que si elles sont versionnées, et testées. Chaque opération effectuée, peut-être de n'importe quelle nature.
mais: DES TESTS OBLIGATOIRES DOIVENT ETRE FOURNI :+1:
une oipération n'a le droit d'être menée quie si, et seulement si, une procédure compléte de backup et de restore, permettent de rétablir l'état FINAL, de l'opération. Alors, pour peu que la provision initial de l'infrastructure fournisse :
une procédure de backup et restore de l'état courant d'utilisation, SANS AUCUNE autre operation devops QUE LA PROVISION INITIALE : seules ont été exécutées, des opérations correspondant aux cas d'utilisation au niveau logiciel. Ce sont des opérations connues des concepteurs du logiciel, et sont imprévisibles et non-versionnées....
donc le requirement pour que tout le reste de la suite soit convergente, repose sur le fait QUE LA PREMIERE VERSION DE RECETTE DE PROVISION, SUPPORTE UN NOMBRE FINI, DETERMINANT/DEFINISSANT LA GARANTIE QU'APPORTE LES BACUP RESTORE, D'OPERATIONS LOGICIELLES CORRESPONDANT AUX USE CASES LEGITIMES DES LOGICIELS UTILISES DANS L INFRA. ( SUPPORT CASES? ) . DONC IL FAUT AUTOMATISER DES TESTS DE bdd OBLIGATOIRES POUR CHAQUE RESTORE BACKUP, ECRIS A CHAQUE OPERATION SUR INFRA. PAS DE TEST AUTOMATISE OK SUR UN PERIMETRE USE CASES BUSINESS (APPPELEE GARANTIE METIER) , PAS D'AUTORISATION D'EXECUTION EN PROD; lÀ IL FAUT LES SIGNATURES DIGITALES ENGAGEANT LES MANAGERS
Le diagamme commutatif de la catégorie des 'exploitations' d'une infrastructure, consiste en l'égalité des deux compositions équatoriales décrites ci-après :
effectuer une operation (migration?), de la version N de l'infrastructure, à une version N+1,
Oh oui!
Voilà l'erreur qu'ils ont commise :
Ainsi, je dois à l'avenir, nommer mes fichiers de backup à l'aide d'un numéro de version clair, de ma recette provision de l'infrastructure kytes.io , ainsi que nous l'a enseigné le montage des tests pour l'issue conernant la restauration
Le diagamme commutatif de la catégorie des 'exploitations' d'une infrastructure
On suppose que l'on a faut une provision de l'infrastructure, avec le recette de provision en version
N. Une fois la provision en versionN, on ne peux effectuer des opérations sur l'infrastructure que si elles sont versionnées, et testées. Chaque opération effectuée, peut-être de n'importe quelle nature. mais: DES TESTS OBLIGATOIRES DOIVENT ETRE FOURNI :+1:Le diagamme commutatif de la catégorie des 'exploitations' d'une infrastructure, consiste en l'égalité des deux compositions équatoriales décrites ci-après :