Sessions

Jeudi 19 février

Dépendances

Normalement, vous avez déjà identifié les dépendances de vos livrables. Les dépendances systèmes (programmes et bibliothèques), les dépendances au niveau du projets (paquets NPM, crates cargo, modules PIP, etc.) et les dépendances de service (redis, postgres, mailer, etc.)

Vos dépendances au niveau du projet sont quasiment systématiquement toutes déjà dans un fichier commit dans vos dépôts et ne nécessitent pas plus d’efforts de votre part.

Les dépendances systèmes et de service, doivent elles être consignées dans un document. Il peut s’agir d’un readme.md sur votre dépôt, d’une page de wiki sur votre forge, ou d’un document de type Word, dédié aux procédures de contribution et déploiement du projet.

Votre objectif est maintenant est de faire en sorte que votre document réponde aussi aux questions suivantes.

• Pour le déploiement en condition réelles
  • Quel système d’exploitation doit être installé sur le serveur ?
  • Quelles règles d’accès doivent être mises en place ? comment doit-il être possible d’accéder au serveur pour les opérations ?
  • Comment doit être configuré le pare-feu ?
  • Quelles sont les commandes à faire pour installer les dépendances aux livrables ?
  • Quelle stratégie utiliser pour le déploiement des livrables (installation directe, installation via docker) ?
  • Quelles commandes à faire pour récupérer le code des livrables, les construire, les mettre en fonctionnement les arrêter ?
• Pour les tests unitaires et d’intégration (sur un serveur de tests ou le même serveur que l’exécution)
  • Ce sont des tests qui ne touchent qu’un seul livrable à la fois.
  • À l’instar du déploiement en conditions réelles : que faut-il installer, quelles commandes faut-il faire pour les exécuter ?
• Pour les tests fonctionnels.
  • Ce sont les tests qui s’assurent que les livrables fonctionnent les uns avec les autres.
  • Quelles configurations et commandes sont nécessaires pour déployer les services de sortes que les tests fonctionnels puissent être exécutés ?
  • Quelles commandes sont nécessaires à leur exécution ?

Toutes ces informations, vous devez les tester. La façon de s’assurer que ce que vous dites est vrai c’est de faire des machines virtuelles, et de les tester sur des machines virtuelles toutes neuves. Le plus rapidement vous pouvez configurer une machine virtuelle, le plus vos procédures sont saines et maîtrisées.

Intégration continue

L’intégration continue c’est une pratique en développement logiciel qui vise à s’assurer qu’à chaque modification d’une base de code :

• elle peut toujours être constructible ;
• ses tests unitaires et d’intégration passent toujours.

Plusieurs outils existent pour automatiser la construction et les tests d’un livrables lors que quelque chose se passe sur une remote git.

Si vous êtes sur github vous pouvez en utiliser la plupart, de bons exemples étant :

• github actions ; ou
• CircleCI.

Si vous êtes sur la forge logicielle vous pouvez utiliser les forgejo actions qui ressemblent beaucoup aux github actions.

Lors de la démonstration du 20/02/2026 nous avons construit ensemble des exemples sur le dépôt suivant github et en miroir sur forgejo 89.

Jeudi 26 février

Vendredi 27 février

Jeudi 5 mars

Vendredi 27 mars

Vendredi 3 avril

Mardi 19 mai

Compétences mentionnées dans le REAC

CP10

• identification des dépendances
• procédure et environnements d’exécution des tests d’intégration, système et d’acceptation client
  • dépendances de services aux tests ?
  • commandes à faire après un clone ?
  • comment consigner les résultats des tests, et sous quel format ?
• procédure de déploiement et scripts
  • système d’exploitation et particularités
  • quelles règles DNS à créer ?
  • paquets nécessaires au déploiement (comme docker, un pare-feu)
  • comment à faire pour préparer la machine, quelles commandes faire ?
  • comment mettre à jour le code déployé ?
• scripts de déploiement et leur documentation
  • fusion avec la procédure de déploiement

CP11

• utilisation d’un environnement collaboratif comme github, la forge logicielle
• conteneurs docker
  • pour l’intégration automatisée et continue (autrement dit la compilation et l’exécution des tests unitaires et d’intégrations)
• utilisation d’outils de qualité du code
  • en JS ce sont des outils comme prettier, eslint, biome, oxfmt, oxlint
  • en python c’est le respect de normes comme pep8
  • en rust c’est l’utilisation de cargo fmt et cargo clippy
• automatisation de l’intégration et des tests unitaires et d’intégration
  • utilisation d’un outil d’intégration continue comme github actions, forgejo actions (sur la forge logicielle), CircleCI
• procédure pour la résolution de problème en cas de dysfonctionnement
  • issues