Manuel du CPT¶
- Table of contents
- Manuel du CPT
La documentation utile aux CPT est répartie sur plusieurs projets redmine, et quelques pages web annexes. L'objectif de ce manuel est d'offrir un index lisible vers ces différentes ressources.
L'environnement¶
Les emails¶
Assez rapidement il faut se préoccuper des emails et plus précisément de l'organisation de sa boite mail avec des filtres sieves : [[interne:Guide_du_travailleur_Entrouvert#Quest-ce-quun-mail-|une section du guide]] donne des informations à ce propos.
Accès aux serveurs avec SSH¶
Une des manière de configurer ses filtres sieve est de se connecter en SSH à leucas.entrouvert.org. [[sysadmin:Ssh_et_port_knocking#Configurer-ssh-sur-votre-poste|Une page de wiki]] explique comment utiliser la configuration SSH partagée disponible dans le repo puppet.
De chez soi¶
Le pare-feu¶
Les accès SSH aux serveurs sont filtrés par adresse IP.
Quand on travaille de chez soi et qu'on veut se connecter à un serveur en SSH, il faut d'abord ajouter son adresse IP à la « liste des IP des travailleurs », en se connectant avec ses identifiants LDAP ici : https://www.entrouvert.org/nsupdate
Au plus cinq minutes avec cet requête, les divers pare-feux sont ouverts à cette nouvelle adresse IP.
Le VPN¶
De manière plus anecdotique il est parfois utile d'utiliser l'adresse IP de sortie du VPN pour accéder à internet (typiquement pour accéder a un service filtré sur cette IP par un client).
Deux pages existent pour expliquer la configuration du VPN : [[sysadmin:OpenVPN]] et [[sysadmin:OpenVPN2]], mais il reste malgré tout conseillé de demander de l'aide à un collègue.
Tunnel Socks pour le navigateur¶
Si l'accès Web à un site client est ouvert uniquement depuis notre VPN il est possible d'ouvrir un tunnel SOCKS:
ssh leucas.entrouvert.org -D 9999
et puis configurer le proxy dans navigateur.
Ainsi l'accès Web est opérationnel, sans impacter le reste.
Les étapes d'un développement¶
Un développement commence par la création d'un ticket dans le projet redmine associé à une brique de Publik, et se termine quand le code se retrouve sur les serveurs de production.
Travailler selon le cycle de développement¶
Publik est mis à jour en continu, selon un cycle de mise à jour. Grosso modo : on développe en permanence, mais on ne pousse les nouveautés que pendant une semaine après la mise à jour, et on utilise la semaine suivante pour corriger les problème relevés sur les instances de test.
Création du ticket¶
Voir : Créer un ticket sur redmine
Installation d'un environnement de développement¶
Il est indispensable d'avoir une instance Publik locale, facile à obtenir en suivant ces instructions : https://doc-publik.entrouvert.com/dev/installation-developpeur/.
Il est conseillé de lire cette page en intégralité car elle donne aussi des informations sur l'utilisation de l'environnement, par exemple le démarrage d'un service dans une console, ou encore l'ajout de settings.
Compréhension du contexte fonctionnel¶
La documentation de Publik est très complète et permet souvent de mieux cerner le contexte d'un nouveau développement : https://doc-publik.entrouvert.com/admin-fonctionnel/.
On notera également la présence d'une documentation davantage orientée développement, avec notamment la description des API disponibles : https://doc-publik.entrouvert.com/dev/.
Travail de programmation¶
Depuis 2023, on utilise Gitea pour héberger le code de Publik.
Au moment où on se décide à travailler sur un ticket, on peut commencer par se l'assigner. La suite est documentée ici : section sur les branches git et section sur les commits.
Écriture des tests¶
On vise une couverture de tests maximale, cela implique un grand soin à apporter à l'écriture de tests : HowDoWeDoTests.
Jenkins¶
Les tests sont exécutés sur https://jenkins.entrouvert.org/, mais aussi :- La vérification du formatage imposé par pre-commit. Si échec à ce niveau, il est nécessaire d'aller voir la sortie console (bouton en barre latérale).
- La sortie pylint, qui doit être exempte d'erreur. Si échec à ce niveau, il faut cliquer sur « Pylint warnings » en barre latérale.
- Le coverage, pour le voir il faut cliquer sur « Coverage report (native) » en barre latérale. À noter qu'on a à droite d'une ligne un contexte dépliable qui indique tous les tests qui la couvre.
UI, CSS et intégration graphique¶
Pages à parcourir :Commandes utiles¶
Lors de tests « en vrai » sur son instance, il est utile d'avoir en tête certaines commandes : Commandes_utiles.
Relecture¶
Une fois le code écrit, il est nécessaire d'attendre la relecture d'un ou une collègue : HowDoWeDoCodeReviews.
Merge¶
Après validation, il faut vérifier que l'on est pas en période de « freeze » avant de merger son code dans la branche principale : Cycle_de_mises_à_jour.
Ensuite, il est conseillé de rebaser sa branche sur main et de laisser une dernière fois tourner les tests. Une fois cela fait, il n'y a plus qu'à cliquer dans Gitea pour merger.
Traduction¶
Si le code introduit des chaînes à traduire, il est recommandé de s'en occuper tout de suite après avoir mergé : HowDoWeDoTraductions.
Déploiement en recette¶
Voir : HowDoWeDoRelease.
Notes de mise à jour¶
Il est recommandé de documenter ce qui vient d'être mergé, afin de faciliter la rédaction des notes de mise à jour.
Pour ce faire, il faut aller retrouver son ticket sur la page https://scrutiny.entrouvert.org/projects/saas2/history. On y ajoute ensuite les informations nécessaires : type de ticket, attention à porter à la doc, description à reprendre dans les notes.
Suivi des traces¶
Les identifiants LDAP permettent d'accéder à https://sentry.entrouvert.org/, outil qui agrège les erreurs qui ont lieu sur les serveurs. Il est également possible de recevoir ces traces directement par mail.
Il est possible de créer un ticket redmine à partir d'une trace Sentry : il faut cliquer sur le lien « Create Redmine Task » en barre latérale. On accède ensuite au ticket créé via l'onglet « Comments » de la page. Il ne reste plus qu'à déplacer le ticket vers le bon projet technique.