Un simple outils Python en ligne de commande qui reste la taille d'une image Docker et retourne une erreur si celle ci dépasse une taille donnée. A intégrer dans les CI pour s'assurer que les images Docker ne grossissent pas exponentiellement au fil du temps.

Terratest est un framework de test en Go pour automatiser les tests d'infrastructure Terraform, mais aussi Packer et Docker build.

Comment mettre en place des tests unitaires sur les images Docker à l'aide de RSpec et ServerSpec

Un framework de test unitaire pour les scripts bash

Dans la 3ème partie, l'article explique comment Taurus permet d'automatiser l’exécution de tests de performances dans un contexte d'intégration continue en permettant l'éxecution de commandes shell (module shellexec) avant ou après le test et la collection de métriques de monitoring (module monitoring et agent ServerAgent)

Bees crée des instances EC2 à la volée et lance des tests de charge distribués

Playbook pour tester des plays ansible dans un container Docker:

ansible-playbook main.yml --extra-vars '{"tasks":["./task_file1.yml","./task_file2.yml","other_var":"value"]}'

A performance budget is just what it sounds like: you set a “budget” on your page and do not allow the page to exceed that. This may be a specific load time, but it is usually an easier conversation to have when you break the budget down into the number of requests or size of the page.
(...)
Once those goals are set, you stick to them. Anytime you want to add something to a page, you need to ensure it stays within budget. Steve Souders talked about the three options you have if something does not fit within the budget:

1. Optimize an existing feature or asset on the page.
2. Remove an existing feature or asset from the page.
3. Don’t add the new feature or asset.

Le budget performance correspond à la valeur max autorisée pour une métrique de performance (temps de chargement, nombre de requêtes ou poids de la page). On peut ensuite tester le "budget" au cours de l'intégration continue avec un outils comme SiteSpeed.io et remonter une alerte en cas de dépassement.

Les métriques à mesurer pendant un test de performance:

1. Errors over load (“results valid?”)
2. Bandwidth throughput over load (“system bottleneck?”)
3. Response time over load (“how does system scale?”)
   • Business process end-to-end
   • Page level (min-avg-max-SD-90th percentile)
4. System resources (“how’s the infrastructure capacity?”)
   • Server cpu over load
   • JVM heap memory/GC
   • DB lock contention, I/O Latency

Pour analyser la performance d'un site web. Pas mal de fonctionnalités intéressantes:

• Dashboard Graphite/Grafana (procédure avec Docker incluse)
• Check Performance Budget
• Intégration WebPageTest et Google PageSpeed Insights
• Intégration CI avec Jenkins & Travis

Comment utiliser Apache JMeter pour créer des tests de charge

Un exemple d'utilisation de docker pour automatiser des tests unitaires et d'intégrations avec maven/jenkins et selenium

Un tuto pour utiliser Jmeter pour lancer des tests de charges

Le Feature Flipping permet de livrer en production des fonctions désactivées qui pourront ensuite être activé pour tout ou partie des utilisateurs.

Les cas d'utilisation sont multiples:

• livraison en prod de fonctionnalités non terminées lorsque les développeurs commitent sur le trunk (best practices pour le continuous deployment)
• rollback plus rapide (en cas de bug sur une nouvelle fonctionnalité, il suffit de la désactiver sans relivrer)
• tests sur des sous-population (A/B testing)
• proposer des fonctionnalités payantes
• Passer en mode dégradé en cas de problèmes de perfs (en desactivant les fonctions - critique mais + gourmandes en ressources)

3 tips for DevOps teams:

• Try to go from commit to live in production automatically.
• Use feature flags or flippers instead of branching
• Run a bunch of really small production tests, performing real interactions with your live site, such as creating new user accounts, using Selenium, or just curling some URLs. Then add them to your deployment pipeline. If any of the tests fail, just deploy the old version.

L'article de référence sur l'intégration continue.

Workflow:

1. Checkout code from source control in working copy
2. Write code
3. Write tests (XUnit)
4. Run automated build in dev machine
5. Update working copy from source control
6. Run automated build again on updated workin copy
7. Fix & rebuild if KO
8. Commit to the mainline
9. Build on CI server
10. Fix immediatly if KO on CI server

Description des différents de testing utilisable avec Chef (test unitaires, tests d'integration, ...)

Les différents types de tests à effectuer avant de mettre en production

P stands for performance testing.
U covers unitary testing.
R deals with non-regression tests.
I represents integration testing.
F is for functional tests.
F covers non-functional tests.