La charte du développement backend chez Deepki - Partie 4 : opérabilité
Cet article est le dernier de notre série consacrée à la charte de développement backend chez Deepki. Nous y abordons des sujets liés à l’opérationnel : le déploiement, l’observabilité et la sécurité.
Sécurité
Dans le développement logiciel, la sécurité est un élément clé à ne pas négliger. Pour éviter les failles de sécurité, il est important de suivre quelques règles élémentaires.
Tout d’abord, il est essentiel de ne pas faire confiance aux données externes. Les inputs doivent être nettoyés afin d’éviter les injections de code. De plus, il est recommandé de ne pas stocker les credentials dans le repo, notamment les identifiants et mots de passe de base de données ou de service externe. Des solutions techniques existent pour éviter cela, comme Ansible Vault.
Lorsqu’on stocke des mots de passe, il est important de les chiffrer, de les saler et de les rendre lent à déchiffrer. Idéalement, on utilise un algorithme éprouvé comme bcrypt. De même, il est crucial de ne pas logger de données sensibles comme les mots de passe ou les numéros de carte de crédit.
Pour les APIs exposées sur Internet, il est indispensable d’utiliser SSL. Il est important de toujours partir du principe que le réseau est compromis et donc de prendre les mesures de sécurité nécessaires.
Enfin, il ne faut pas oublier de donner le moins de privilèges possibles à chaque produit. Si une application ne fait que des lectures dans une DB, il est inutile de lui donner un accès en écriture.
Déploiements
Nous préférons des déploiements fréquents, courts et sans interruption de service. Cela implique de gérer la rétrocompatibilité dans la mesure du possible, et lorsque ce n’est pas possible ou trop coûteux, de bien réfléchir aux impacts et de prévenir les équipes concernées.
En cas de problème suite à un déploiement, la personne qui a effectué le déploiement doit corriger le problème ou prendre la décision de revenir en arrière. Nous évitons donc les déploiements tardifs dans la journée ou avant le week-end.
Logs et métriques
Les logs sont des fichiers qui enregistrent les événements du système, tandis que les métriques sont des mesures quantitatives de divers aspects du système. Les logs sont utilisés pour le débogage et la recherche de problèmes spécifiques, tandis que les métriques servent à surveiller le système en temps réel et à détecter les problèmes avant qu’ils ne deviennent critiques.
En tant que développeurs, nous avons pour rôle de produire :
- Des logs, utilisables par des humains pour comprendre ce qu’il s’est produit dans le passé et pour diagnostiquer des problèmes qui sont déjà arrivés.
- Des métriques, utilisables pas des humains ou des automates pour surveiller le système en temps réel et détecter les problèmes avant qu’ils ne deviennent critiques.
Conclusion
Cet article clôt la série consacrée à la charte du développement backend chez Deepki. Nous espérons que cette série vous aura donné envie d’appliquer vous aussi ces principes, et qu’ils vous aideront à écrire du code maintenable et de qualité !
Cette entrée a été publiée dans programmation avec comme mot(s)-clef(s) programmation
Les articles suivant pourraient également vous intéresser :
- Comment utiliser les fixtures pytest en autouse tout en maîtrisant ses effets de bord ? par Amaury Boin
- Améliorer l'architecture d'une application Vue grâce à la composition API par Pierre Assemat
- Wrap like an Egyptian par Khaled FAYSAL
- Les fixtures de données pytest : la fausse bonne idée ? par Julia Cavicchi
- Introduction a l'éco-conception numérique par Jean-Baptiste Bergy
- La charte du développement backend chez Deepki - Partie 3, les tests automatisés par Olivier Roux
- Le duel de programmation : Python et Elixir face à face par Yahya Lazaar
- La charte du développement backend chez Deepki - Partie 2, la lisibilité par Olivier Roux
- La charte du développement backend chez Deepki - Partie 1, les grands principes par Olivier Roux
- Pourquoi et comment gérer la compatibilité ascendante ? par Olivier Roux
- Quelques techniques pour rendre un code lisible et agréable (et éliminer la charge cognitive) par Xavier Barbosa
- Débuter avec Ansible par Younes Bentalia
- TypedDict vs DataClass en Python par Pierre Assemat
- Quelques design patterns commentés en python par Vincent Valat
- Au fait, c'est quoi, un algorithme ? par Valentin Leclere
- Les design patterns en Vue3 par Juan Lozano
- This is DOP* par Xavier Barbosa
- The Clean Coder par Robert C. Martin - Être professionnel dans sa pratique du code par Quentin Mondot
- Comment manipuler facilement l'objet datetime dans MongoDB au sein d'un projet international en Python? par Muhui YU
- Introduction au Test-Driven Developement par Alex Peyrard
- Typage en python : comment utiliser le type hinting pour debugger du code par Juan Lozano
- Comment nous gérons nos configurations par Xavier Barbosa
- Domain Driven Design - Définir et modéliser un domaine métier par Younes Bentalia
- L'ETL chez Deepki par Marc Spiteri
- Comment manipuler un DataFrame Pandas avec le MultiIndex ? par Muhui YU
- The Clean Coder par Robert C. Martin - C'est quoi être professionnel quand on est développeur ? par Quentin Mondot
- Comment faire du Parsing de PDF sans utiliser les expressions régulières ? par Bo Jiang
- Dask vs Pandas : Fight ! par Juan Lozano
- Comment faire cohabiter D3 et Vue ? par Matthieu Caule
- Les outils de gestion de packages python par David Couderc
Postez votre commentaire :
Votre commentaire a bien été envoyé ! Il sera affiché une fois que nous l'aurons validé.
Vous devez activer le javascript ou avoir un navigateur récent pour pouvoir commenter sur ce site.