Recommandé
Contenu connexe
Similaire à La mise en production, comment être plus efficace
Similaire à La mise en production, comment être plus efficace (20)
La mise en production, comment être plus efficace
- 1. La mise en production Comment être plus efficace ?
- 2. Qui suis-je ? ● Développeur ● Back-end, cloud
- 3. Une mise production ‘classique’ Du temps, de la sueur et des larmes...
- 4. Comment en est-on arrivé là ?
- 5. 1 Des procédures adéquates Des opérations manuelles dans une documentation : ● Risques d’erreurs ● Documentation obsolète ● Long et fastidieux
- 6. 2 On va dans le même sens ● Pas de vision partagée ● Des environnements différents suivant les équipes ● Beaucoup d'énergie perdue
- 7. 3 Tout va très vite 1. Releases peu fréquentes 2. Beaucoup de contenu 3. Gros risque de casse
- 8. Bref… On est serein ● On freine devant les évolutions ● Image de l’entreprise dégradée ● Grosse sollicitation des équipes
- 9. Comment peut-on faire autrement ?
- 10. Un changement de culture ● Un partage des responsabilités ● Des équipes autonomes ● Moins de conflits, plus de coopération
- 11. Des tests automatisés et une usine de CI ● 80 % des problèmes potentiels détectés automatiquement ● Des tests manuels plus orienté vers l’utilisateur, l’ergonomie ● Une protection contre les régressions
- 12. Refactoring, revue de code, pair programming et TDD ● Code plus lisible, homogène ● Meilleur compréhension de l’application ● Des bugs plus facile à identifier puis corriger
- 13. De l’automatisation. Partout... ● Des livraisons en continue ● Des déploiements en continu ● La configuration des serveurs, des sous-réseaux, c’est aussi du code
- 14. Aller vers un déploiement de type ‘blue green’ ● Pas de temps d’indisponibilité ● Un retour en arrière est toujours possible ● La bascule finale est faite après toutes les vérifications
- 15. En utilisant si possible des conteneurs et orchestrateurs ● Isolation des dépendances ● Surveillance, montée en charge et redondance plus facile ● Des services plus robustes
- 16. C’est la culture DevOps
- 18. Démonstration d’une mise en production sans indisponibilité entièrement automatisé avec un mécanisme de retour en arrière https://github.com/sogilis/matinal e-tech
- 21. Des questions ?
Notes de l'éditeur
- Pertes de temps, impact possible sur le temps d’indisponibilité Perte de confiance dans le processus de mise à jour Génère beaucoup de stress Impact sur la qualité de service
- => evolutivité fonctionelle et technique faible et lente (peur du changement) => taux d’indisponibilité, bugs, peu de nouvelle fonctionnalité, utilisateur peu satisfait => fatigue, stress, moins de temps pour les features
- la plupart des plateformes / langages possèdent des outils de test unitaire abouti ci : solutions saas : travis, circle-ci, teamCity,
- Objectif => faire en sorte
- deploiements : Meilleur Réactivité aux changements clients Les mises en productions deviennent banales Moins de stress, moins d’erreurs Infrastructure as Code pour : Des environnements reproductibles La doc, c’est le code outils : Vagrant, terraform, ansible, puppet, chef, salt, etc...
- Possibilité d’avoir d’ultimes vérifications directement sur l’environnement de production sans impact utilisateur Outils : docker, rkt, kubernetes, amazon ECS, docker swarm...
- Définition des conteneurs et des orchestrateur d’autres avantages comme la scalabilité plus facile, optimisation des ressources et environnement de dev Isolation des dépendances. automatisation des déploiements + faciles indépendance des services les uns des autre Outils : docker, rkt, kubernetes, amazon ECS, docker swarm...
- le presenter comme un pre-requis. Mouvement lié à l'agilité. Org (limitation des silots dev / ops), infra as code, automatisation.