Post

SF : DevOps

Posted
Preview Image
By Roald Brunell 2 min read

Ma première vraie découverte du concept DevOps a été faite lors de cette SF sur le sujet. J’ai pu comprendre l’importance et la puissance de ce dernier lorsqu’il est proprement implémenté dans un environnement propice à son utilisation. Similairement à notre première expérience avec la méthode SCRUM, cette session nous a principalement servi à titiller notre intérêt, à nous orienter pour poursuivre notre approfondissement du sujet, à nous faire comprendre le but et l’impact du DevOps. Ensuite j’ai pu continuer l’exploration du sujet à l’aide de mon propre AR, celui de Hugo à propos des pipelines ou encore celle de Flavio à propose du choix de VCS pour des projets Devops

Dans notre première SF avec David Wannier autour du DevOps nous avons abordé les points ci-dessous.

Les différences entre DevOps / DevSecOps au niveau des étapes principales

  • Plan : … / security requirements, GDPR compliance
  • Code : faire unit tests avant les commit / séparation des rôles, check saisie utilisateur, SAST (ex. OASP dependency check)
  • Test : test d’intégration, tests fonctionnels, tests de charge, tests de régression / SCA + DAST
  • Monitor : toujours up, analyse des logs, peak de connexions, data bandwidth, monitoring CPU + RAM / origine des connexions IP, gestion flux des connexions

En résumé, DevSecOps est la suite logique de DevOps où l’on va incorporer la sécurité

Qu’est-ce que l’intégration continue?

  • DevOps sans le monitoring de la solution une fois déployée
  • Ancêtre du DevOps

Quels types de tests principaux existe-t-il?

  • Test unitaire de niveau “atomique”, tests de calculs, de paramètres et “returns”
  • Tests d’intégration de type test API (Fonction createPerson créé vraiment une personne)
  • Tests fonctionnels, tests en prod de ce que l’utilisateur pourrait faire (avec Selenium par exemple)

Quels principaux types de builds existe-t-il?

Les étapes “security checks” et “deploy” sont souvent en “nightly build” et ne sont pas fait en continuous integration build car ils prennent plus de temps et n’ont pas besoin d’être fait à chaque commit. Il y a aussi les “milestone builds” qui sont faits par exemple à chaque fin de sprint. On trouvera également les “release builds”, des tests manuels qui prennent du temps et sont coûteux (usability test, registration/signup test).

SF
B2 M8 Semestre 4
This post is licensed under CC BY 4.0 by the author.