Je fais la remarque pour inviter à prendre du recul sur le déploiement continu.
Les particularités qui font que ça prend si longtemps, c'est que seul un test sur la carte finale est vraiment fiable pour une livraison. Et une carte à puce, c'est lent, et communiquer avec une carte à puce, c'est lent aussi.
On fait bien sur des tests sur des simulateurs beaucoup plus rapides, mais qui ne garantissent pas l'absence d'erreurs. Seule la carte finale peut te donner confiance.
Si on compte toutes nos bases de test, on est largement au dessus des 100 000 tests sur les cartes SIM, et autour des 100 000 sur des objets plus simples comme les cartes bancaires.
Alors pourquoi c'est aussi compliqué une carte à puce, cela reste en partie un mystère pour moi. On a globalement de la crypto, de la communication, une VM Javacard, des systèmes de distributions de clés et d'applications Javacard (GlobalPlatform). Les gars du GSM ont en plus une pile TCP si je me souviens bien et un client http et un client dns.
Parmi les tests les plus longs, il y a la coupure de courant/champs en plein milieu d'une opération critique. Tu prends une opérations critique et tu répètes ton test un coupant le courant au bout de 0.001 s puis 0.002s etc et tu vérifies que la carte n'est pas corrompue après chaque test.
En pratique, on fait tourner une intégration continue avec les batteries pas trop longue (moins de 10h) toutes les nuits, et le reste le weekend.
Bien sûr, on peut toujours viser un sous-ensemble de ces tests à tourner sur chaque commit, mais extraire et maintenir ce sous-ensemble demande un savoir-faire et une expertise sur nos bases de tests qui n'est pas forcément disponible. C'est surtout l'aspect maintenance de ce type de suite qui est délicat.
Donc on fait comme on peut, en allant vers plus d'intégration continue qu'avant.
Ah oui, j'oubliais un détail comique: la flash, c'est entre 100 000 et 500 000 écritures en gros. Sur des bases de test un peu intensive (et écrites comme des cochons), on grille l'endurance de la flash en trois jours sur une carte. Ce qui se traduit quand tout va bien par un gros fail, mais plus généralement par des échecs aléatoires dans la suite de test, qu'il faut trier d'échecs légitimes générés par du code nouveau.
Bref, ca peut être la mouise. Cela dit, avec toutes ces contraintes, je trouve que ma boite s'en tire bien. On s'appuie sur des bons outils internes pour gérer la problématique globale et on va vraiment sur plus d'intégration continue et de reproductibilité des problèmes. Peut-être même qu'un outil open source verra le jour sur un sujet connexe lié à tout ça.
[^] # Re: L'opensource et maven fonctionne très bien
Posté par Philippe F (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 7.
Je fais la remarque pour inviter à prendre du recul sur le déploiement continu.
Les particularités qui font que ça prend si longtemps, c'est que seul un test sur la carte finale est vraiment fiable pour une livraison. Et une carte à puce, c'est lent, et communiquer avec une carte à puce, c'est lent aussi.
On fait bien sur des tests sur des simulateurs beaucoup plus rapides, mais qui ne garantissent pas l'absence d'erreurs. Seule la carte finale peut te donner confiance.
Si on compte toutes nos bases de test, on est largement au dessus des 100 000 tests sur les cartes SIM, et autour des 100 000 sur des objets plus simples comme les cartes bancaires.
Alors pourquoi c'est aussi compliqué une carte à puce, cela reste en partie un mystère pour moi. On a globalement de la crypto, de la communication, une VM Javacard, des systèmes de distributions de clés et d'applications Javacard (GlobalPlatform). Les gars du GSM ont en plus une pile TCP si je me souviens bien et un client http et un client dns.
Parmi les tests les plus longs, il y a la coupure de courant/champs en plein milieu d'une opération critique. Tu prends une opérations critique et tu répètes ton test un coupant le courant au bout de 0.001 s puis 0.002s etc et tu vérifies que la carte n'est pas corrompue après chaque test.
En pratique, on fait tourner une intégration continue avec les batteries pas trop longue (moins de 10h) toutes les nuits, et le reste le weekend.
Bien sûr, on peut toujours viser un sous-ensemble de ces tests à tourner sur chaque commit, mais extraire et maintenir ce sous-ensemble demande un savoir-faire et une expertise sur nos bases de tests qui n'est pas forcément disponible. C'est surtout l'aspect maintenance de ce type de suite qui est délicat.
Donc on fait comme on peut, en allant vers plus d'intégration continue qu'avant.
Ah oui, j'oubliais un détail comique: la flash, c'est entre 100 000 et 500 000 écritures en gros. Sur des bases de test un peu intensive (et écrites comme des cochons), on grille l'endurance de la flash en trois jours sur une carte. Ce qui se traduit quand tout va bien par un gros fail, mais plus généralement par des échecs aléatoires dans la suite de test, qu'il faut trier d'échecs légitimes générés par du code nouveau.
Bref, ca peut être la mouise. Cela dit, avec toutes ces contraintes, je trouve que ma boite s'en tire bien. On s'appuie sur des bons outils internes pour gérer la problématique globale et on va vraiment sur plus d'intégration continue et de reproductibilité des problèmes. Peut-être même qu'un outil open source verra le jour sur un sujet connexe lié à tout ça.