DeveloppementBonnesPratiques » Historique » Version 14
Lionel Morin, 22/09/2016 12:05
1 | 7 | Lionel Morin | h1. EOLE - Étude prospective pour les futurs développements |
---|---|---|---|
2 | 7 | Lionel Morin | |
3 | 7 | Lionel Morin | h2. Objectif du document |
4 | 7 | Lionel Morin | |
5 | 7 | Lionel Morin | * Établir un état des lieux des applicatifs et des méthodologies existants dans l'environnement EOLE actuel |
6 | 7 | Lionel Morin | * Définir un référentiel commun pour réaliser un comparatif « objectif » de solutions techniques pour les futurs développements |
7 | 7 | Lionel Morin | * Énumérer les bonnes pratiques méthodologiques et prioriser leur mise en place afin d'améliorer les processus de développement, indépendamment des solutions techniques sélectionnées |
8 | 7 | Lionel Morin | |
9 | 7 | Lionel Morin | h2. État des lieux |
10 | 7 | Lionel Morin | |
11 | 7 | Lionel Morin | h3. Applicatif |
12 | 7 | Lionel Morin | |
13 | 7 | Lionel Morin | > EAD |
14 | 7 | Lionel Morin | > * Gestion de profil / autorisation d'utilisateur (bdd) |
15 | 7 | Lionel Morin | > * Gestion de ressources (imprimantes, partage, utilisateurs, ACL, ...) |
16 | 7 | Lionel Morin | > * Exécution de script sur le serveur |
17 | 7 | Lionel Morin | > * Intégration d'applications distantes |
18 | 7 | Lionel Morin | > * Observation de poste à distance |
19 | 7 | Lionel Morin | > * Configuration du serveur (vnc, proxy, règles optionnelles d'ERA, cron, ...) |
20 | 7 | Lionel Morin | > * Accès SSH à distance |
21 | 7 | Lionel Morin | |
22 | 7 | Lionel Morin | > Genconfig |
23 | 7 | Lionel Morin | > * Gestion de la configuration EOLE |
24 | 7 | Lionel Morin | > * Génération automatique de formulaire à partir d'un fichier de description en XML |
25 | 7 | Lionel Morin | |
26 | 7 | Lionel Morin | > Zéphir |
27 | 7 | Lionel Morin | > * Fonctionnalités actuelles |
28 | 7 | Lionel Morin | > ** Gestion d'une base de serveurs/modules EOLE |
29 | 7 | Lionel Morin | > ** Authentification/autorisation avec contrôle des ressources par profil |
30 | 7 | Lionel Morin | > ** Gestion de statistiques système / logs / reporting d'état (mail/appli) |
31 | 7 | Lionel Morin | > ** Gestion de configurations /variantes de configuration (saisie/déploiement) |
32 | 7 | Lionel Morin | > ** API de récupération des informations (utilisé par ARV/ERA/scripts utilisateur...) |
33 | 7 | Lionel Morin | > ** Enrôlement des serveurs |
34 | 7 | Lionel Morin | > ** Exécution d'actions et transfert de fichiers à distance (sécurisé) |
35 | 7 | Lionel Morin | > * Évolutions bloquées |
36 | 7 | Lionel Morin | > ** Plusieurs serveurs Zéphir en 'cascade' (hiérarchie de backends. par ex: national/académique/établissement) |
37 | 7 | Lionel Morin | > ** Utilisation de plusieurs processeurs / backend séparés en plusieurs processus (pb lié à twisted/python) |
38 | 7 | Lionel Morin | > ** Interface plus dynamique (carte avec Géolocalisation des serveurs, ...) |
39 | 7 | Lionel Morin | |
40 | 7 | Lionel Morin | > EoleSSO |
41 | 7 | Lionel Morin | > * Support de protocoles spécifiques (CAS, SAML, OpenID, ...) |
42 | 7 | Lionel Morin | > * Gestion session |
43 | 7 | Lionel Morin | > * Envoi d'attributs utilisateur avec filtre en fonction de la destination |
44 | 7 | Lionel Morin | |
45 | 7 | Lionel Morin | > ARV |
46 | 7 | Lionel Morin | > * Gestion de ressources (serveurs, tunnels, bdd, ...) |
47 | 7 | Lionel Morin | > * Envoi d'archive de configuration à Zéphir |
48 | 7 | Lionel Morin | |
49 | 7 | Lionel Morin | h3. Domaines techniques et fonctionnels récurrents |
50 | 7 | Lionel Morin | |
51 | 7 | Lionel Morin | La liste ci dessous doit servir de référentiel afin d'effectuer le comparatif des solutions proposées dans la section suivante. |
52 | 7 | Lionel Morin | |
53 | 7 | Lionel Morin | * Opérations de gestion du cycle de vie d'un compte utilisateur système ou LDAP (CRUD, changement de mot de passe...) |
54 | 7 | Lionel Morin | * Interaction avec le système de fichier |
55 | 7 | Lionel Morin | * Import/export de données au format CSV, XML |
56 | 7 | Lionel Morin | * Stockage de données et recherche/filtrage de ces données |
57 | 7 | Lionel Morin | * Exécution de commandes systèmes et gestion des entrées/sorties |
58 | 7 | Lionel Morin | * Rapports sur l'état du système hôte |
59 | 7 | Lionel Morin | * Envoi de courriel |
60 | 7 | Lionel Morin | * Authentification CAS / LDAP / Système |
61 | 7 | Lionel Morin | * Gestion des droits d'accès en fonction du profil utilisateur |
62 | 7 | Lionel Morin | |
63 | 7 | Lionel Morin | h3. Méthodologique |
64 | 7 | Lionel Morin | |
65 | 7 | Lionel Morin | > Ce qui existe |
66 | 7 | Lionel Morin | > * Séparation du code et de l’empaquetage |
67 | 7 | Lionel Morin | > * Versionning des applications avec une branche par distribution EOLE |
68 | 7 | Lionel Morin | > * Coding standard (syntaxe python) |
69 | 7 | Lionel Morin | |
70 | 7 | Lionel Morin | > Éléments bloquants rencontrés |
71 | 7 | Lionel Morin | > * Manque de référentiel technique (cadre à respecter) |
72 | 7 | Lionel Morin | > * Absence de revue de code |
73 | 7 | Lionel Morin | > * Pas de refactoring de code |
74 | 7 | Lionel Morin | > * Manque de tests unitaires / fonctionnels |
75 | 7 | Lionel Morin | > * Exécution automatique des tests |
76 | 7 | Lionel Morin | > * Pas de documentation technique |
77 | 7 | Lionel Morin | > * Recherche dans l’historique du code très complexe, impossible d’utiliser **git bisect** |
78 | 7 | Lionel Morin | |
79 | 7 | Lionel Morin | h3. Exigences particulières |
80 | 7 | Lionel Morin | |
81 | 7 | Lionel Morin | * Réutilisabilité du code (composant, éléments d'application, ...) |
82 | 7 | Lionel Morin | * Facilités de création des formulaires |
83 | 7 | Lionel Morin | * Automatisation de la validation des entrées |
84 | 7 | Lionel Morin | * Séparation / indépendance des différents services |
85 | 7 | Lionel Morin | * Appel à distance (gateway) |
86 | 7 | Lionel Morin | |
87 | 7 | Lionel Morin | h2. Étude comparative des langages/pile web "backend" |
88 | 7 | Lionel Morin | |
89 | 7 | Lionel Morin | La définition des pours et contres de chaque proposition doit s'effectuer en prenant compte: |
90 | 7 | Lionel Morin | |
91 | 7 | Lionel Morin | * De l'état actuel de la base de code des applicatifs |
92 | 7 | Lionel Morin | * Des compétences disponibles dans l'équipe |
93 | 7 | Lionel Morin | * De l'écosystème technique EOLE existant |
94 | 7 | Lionel Morin | |
95 | 7 | Lionel Morin | h3. NodeJS / Express |
96 | 7 | Lionel Morin | |
97 | 7 | Lionel Morin | https://nodejs.org/en/ |
98 | 7 | Lionel Morin | http://expressjs.com/ |
99 | 7 | Lionel Morin | |
100 | 11 | Lionel Morin | > Pour |
101 | 7 | Lionel Morin | > * Communauté très active, couverture fonctionnelle très importante |
102 | 7 | Lionel Morin | > * Très performant pour les usages courant du web |
103 | 7 | Lionel Morin | > * Ubiquité du langage (backend, frontend, desktop, mobile) |
104 | 7 | Lionel Morin | > * Version LTS de 5 ans (3 ans + 2 ans maintenance) |
105 | 7 | Lionel Morin | > * Outillage avancé |
106 | 7 | Lionel Morin | |
107 | 11 | Lionel Morin | > Contre |
108 | 7 | Lionel Morin | > * Technologie "jeune" avec rythme d'évolution très rapide |
109 | 7 | Lionel Morin | > * Hyper-modularisation (risque de multiplication des dépendances) |
110 | 7 | Lionel Morin | > * Stabilité erratique des modules communautaires |
111 | 7 | Lionel Morin | > * Fonctionnalités du langage restreintes |
112 | 7 | Lionel Morin | > * Gestion de l'asynchrone parfois complexe ("callback hell", Promise ou Callbacks ?) |
113 | 7 | Lionel Morin | > * Nécessite des formations, une phase d'amorçage et des intervenants externes pour un démarrage dans de bonnes conditions |
114 | 7 | Lionel Morin | |
115 | 7 | Lionel Morin | h3. Flask (Python) |
116 | 7 | Lionel Morin | |
117 | 7 | Lionel Morin | Flask est un micro-framework de développement web pour Python. |
118 | 7 | Lionel Morin | http://flask.pocoo.org/ |
119 | 7 | Lionel Morin | |
120 | 11 | Lionel Morin | > Pour |
121 | 7 | Lionel Morin | > * Framework léger et robuste, facile à appréhender |
122 | 7 | Lionel Morin | > * API minimaliste et stable |
123 | 7 | Lionel Morin | > * Nombreuses extensions référencées et documentées |
124 | 7 | Lionel Morin | > * Client spécifique destiné aux tests |
125 | 7 | Lionel Morin | > * Base de code existante en python (lib EOLE et eole-flask) |
126 | 7 | Lionel Morin | > * Librairies facilitant les interactions avec le système (couches métier EOLE) |
127 | 7 | Lionel Morin | > * Langage Python déjà utilisé au quotidien par l'équipe |
128 | 7 | Lionel Morin | |
129 | 11 | Lionel Morin | > Contre |
130 | 7 | Lionel Morin | > * Envisager le passage à Python 3 |
131 | 7 | Lionel Morin | > * Pas de code commun entre backend et frontend |
132 | 7 | Lionel Morin | |
133 | 7 | Lionel Morin | h3. Perl / Dancer2 |
134 | 7 | Lionel Morin | |
135 | 7 | Lionel Morin | Perl a bien évolué depuis les années 90 où il était **le** langage du Web (http://techbeacon.com/perl-not-dead-it-was-early-web-novices-gave-it-bad-name et https://dzone.com/articles/perl-language-community-and-the-future) |
136 | 7 | Lionel Morin | |
137 | 11 | Lionel Morin | > Pour |
138 | 7 | Lionel Morin | > * Langage mature et évoluant (une nouvelle release par an) |
139 | 7 | Lionel Morin | > * Très grande culture du test |
140 | 7 | Lionel Morin | > * Très grande culture de la documentation (POD) |
141 | 8 | Lionel Morin | > * Coding standard modernes ("Modern Perl":http://onyxneon.com/books/modern_perl/) |
142 | 7 | Lionel Morin | > * Mode d’opération simple en serveur d’application (type FCGI) |
143 | 7 | Lionel Morin | > * Écosystème gigantesque (MetaCPAN.org) avec un soucis de gestion des compatibilités/changements |
144 | 8 | Lionel Morin | > * Utilisé sur des grosses productions (Booking.com, IMDb, DuckDuckGo, Slashdot, Ticketmaster https://en.wikipedia.org/wiki/Perl_language#Applications) |
145 | 7 | Lionel Morin | |
146 | 11 | Lionel Morin | > Contre |
147 | 7 | Lionel Morin | > * Nécessite des formations, une phase d’amorçage et des intervenants externes pour un démarrage dans de bonnes conditions |
148 | 7 | Lionel Morin | |
149 | 7 | Lionel Morin | h3. PHP / ?? |
150 | 1 | Lionel Morin | |
151 | 8 | Lionel Morin | http://www.php.net/ |
152 | 1 | Lionel Morin | |
153 | 11 | Lionel Morin | > Pour |
154 | 8 | Lionel Morin | > * Mode d'opération/déploiement simple (modèle CGI, pas de processus avec un long temps de vie, ou FCGI avec php-fpm) |
155 | 8 | Lionel Morin | > * Gestion de la pile HTTP déportée dans un serveur hôte (Nginx, Apache2, lighttpd...) |
156 | 8 | Lionel Morin | > * Fonctionnalités du langage avancées (namespace, classes, interfaces, mixins...) |
157 | 1 | Lionel Morin | |
158 | 11 | Lionel Morin | > Contre |
159 | 8 | Lionel Morin | > * Relativement moins performant comparativement aux autres solutions (moins vrai avec l'arrivée de PHP 7) |
160 | 8 | Lionel Morin | > * API native surchargée (plusieurs manières de faire la même chose) |
161 | 8 | Lionel Morin | > * Généralisation de l'usage de NodeJS dans les pipelines d'intégration des ressources statiques dans les frameworks |
162 | 8 | Lionel Morin | > * Gestion synchrone des entrées/sorties |
163 | 8 | Lionel Morin | > * Principalement orienté web, moins bonne couverture fonctionnelle que les autres solutions en dehors de ce cas d'usage |
164 | 8 | Lionel Morin | > * Quelques compétences en interne mais nécessite tout de même des formations et de l'accompagnement pour le lancement |
165 | 1 | Lionel Morin | |
166 | 7 | Lionel Morin | h3. NodeJS/Meteor |
167 | 1 | Lionel Morin | |
168 | 1 | Lionel Morin | h2. Étude comparative des piles web "frontend" |
169 | 1 | Lionel Morin | |
170 | 1 | Lionel Morin | h3. Angular 1 |
171 | 1 | Lionel Morin | |
172 | 8 | Lionel Morin | https://angularjs.org/ |
173 | 1 | Lionel Morin | |
174 | 11 | Lionel Morin | > Pour |
175 | 8 | Lionel Morin | > * Double data-binding (rapidité de développement) |
176 | 8 | Lionel Morin | > * Multiples modules communautaires (routage, gestion des formulaires, etc) |
177 | 8 | Lionel Morin | > * Formation déjà effectuée et compétences internes |
178 | 7 | Lionel Morin | |
179 | 11 | Lionel Morin | > Contre |
180 | 8 | Lionel Morin | > * Version 2 d'Angular en phase de release (temps de support restant ?) |
181 | 8 | Lionel Morin | > * Framework non dirigiste (risque de code spaghetti), nécessite une bonne discipline |
182 | 7 | Lionel Morin | |
183 | 7 | Lionel Morin | h3. Angular 2 |
184 | 7 | Lionel Morin | |
185 | 8 | Lionel Morin | https://angular.io |
186 | 7 | Lionel Morin | |
187 | 11 | Lionel Morin | > Pour |
188 | 13 | Lionel Morin | > * Version améliorée d'Angular 2 |
189 | 13 | Lionel Morin | > * Approche orientée composant et relativement guidée |
190 | 1 | Lionel Morin | |
191 | 13 | Lionel Morin | > Contre |
192 | 13 | Lionel Morin | > * Écriture en typescript (apprentissage nécessaire) |
193 | 13 | Lionel Morin | > * Transpilage nécessaire |
194 | 13 | Lionel Morin | > * Architecture plus complexe (découpage en services/composants) |
195 | 13 | Lionel Morin | > * Moins de ressources communautaires qu'Angular 1 |
196 | 7 | Lionel Morin | |
197 | 7 | Lionel Morin | h3. Mithril |
198 | 7 | Lionel Morin | |
199 | 8 | Lionel Morin | http://mithril.js.org/ |
200 | 7 | Lionel Morin | |
201 | 11 | Lionel Morin | > Pour |
202 | 8 | Lionel Morin | > * Framework léger et facile à appréhender |
203 | 8 | Lionel Morin | > * utilise uniquement javascript (facilité de debuggage/mise en place de tests) |
204 | 8 | Lionel Morin | > * Wiki communautaire (projets/outils/bonnes partiques) \url{https://github.com/lhorie/mithril.js/wiki} |
205 | 8 | Lionel Morin | > * rendu rapide comparé aux librairies angular/react... |
206 | 8 | Lionel Morin | > * Solution clé en main (gestion Ajax, St Marc et canard WC) |
207 | 8 | Lionel Morin | > * Bonne documentation |
208 | 7 | Lionel Morin | |
209 | 11 | Lionel Morin | > Contre |
210 | 8 | Lionel Morin | > * Nécessite une certaine connaissance de javacript (pas de templates html, mais des libs existent pour contourner) |
211 | 8 | Lionel Morin | > * Framework non dirigiste (plusieurs approches dans l'organisation des modèles/vues/contrôleur, pas d'outils de tests intégrés) |
212 | 8 | Lionel Morin | > * prévu seulement pour le côté client |
213 | 7 | Lionel Morin | |
214 | 7 | Lionel Morin | h3. Riot |
215 | 7 | Lionel Morin | |
216 | 7 | Lionel Morin | Micro-librairie de construction d'interface web à la manière de React |
217 | 8 | Lionel Morin | http://riotjs.com/ |
218 | 7 | Lionel Morin | |
219 | 11 | Lionel Morin | > Pour |
220 | 8 | Lionel Morin | > * Utilisation de tags HTML personnalisés |
221 | 8 | Lionel Morin | > * Syntaxe simple et puissante |
222 | 8 | Lionel Morin | > * DOM Virtuel |
223 | 8 | Lionel Morin | > * Faible poids par rapport à React ou Angular |
224 | 7 | Lionel Morin | |
225 | 11 | Lionel Morin | > Contre |
226 | 8 | Lionel Morin | > * Librairie ne gérant pas les requêtes XHR |
227 | 8 | Lionel Morin | > * Nécessité de compiler le code |
228 | 7 | Lionel Morin | |
229 | 7 | Lionel Morin | h3. WebComponents (Polymer / X-Tag) |
230 | 7 | Lionel Morin | |
231 | 8 | Lionel Morin | https://github.com/x-tag/core |
232 | 8 | Lionel Morin | https://www.polymer-project.org/1.0/ |
233 | 7 | Lionel Morin | |
234 | 11 | Lionel Morin | > Pour |
235 | 8 | Lionel Morin | > * Définition de tags HTML personnalisés |
236 | 8 | Lionel Morin | > * Construction de composants d’interfaces par composition |
237 | 8 | Lionel Morin | > * Composants utilisables indépendamment des frameworks |
238 | 8 | Lionel Morin | > * Bibliothèque de composants prêts à l'emploi (https://elements.polymer-project.org) |
239 | 7 | Lionel Morin | |
240 | 11 | Lionel Morin | > Contre |
241 | 8 | Lionel Morin | > * Framework non dirigiste |
242 | 14 | Lionel Morin | > * Pas d'automatisation des appels Ajax (voir "librairie fetch":https://github.com/github/fetch) |
243 | 14 | Lionel Morin | > * Spécifications WebComponents susceptible d'évoluer (lissé par Polymer) |
244 | 7 | Lionel Morin | |
245 | 7 | Lionel Morin | h2. Méthodologie de développement |
246 | 7 | Lionel Morin | |
247 | 7 | Lionel Morin | h3. Style de code commun |
248 | 7 | Lionel Morin | |
249 | 9 | Lionel Morin | * Établir un standard de code par langage de programmation |
250 | 9 | Lionel Morin | * Éditor config : définir la configuration des éditeurs de texte, une configuration pour tous les éditeurs |
251 | 1 | Lionel Morin | |
252 | 9 | Lionel Morin | Priorisation : |
253 | 9 | Lionel Morin | |
254 | 9 | Lionel Morin | # Écrire le document style de code |
255 | 9 | Lionel Morin | # Automatiser la vérification (côté développeur / côté serveur) |
256 | 9 | Lionel Morin | |
257 | 1 | Lionel Morin | h3. Développement piloté par les tests |
258 | 1 | Lionel Morin | |
259 | 9 | Lionel Morin | Le "Test Driven Development":https://fr.wikipedia.org/wiki/Test_Driven_Development préconise d’écrire les tests unitaires avant d’écrire le code source : |
260 | 7 | Lionel Morin | |
261 | 9 | Lionel Morin | # Écrire un premier test |
262 | 9 | Lionel Morin | # Vérifier qu'il échoue (car le code qu'il teste n'existe pas), afin de vérifier que le test est valide |
263 | 9 | Lionel Morin | # Écrire juste le code suffisant pour passer le test |
264 | 9 | Lionel Morin | # Vérifier que le test passe |
265 | 9 | Lionel Morin | # Puis réusiner le code, c'est-à-dire l'améliorer tout en gardant les mêmes fonctionnalités |
266 | 7 | Lionel Morin | |
267 | 9 | Lionel Morin | Priorisation : |
268 | 1 | Lionel Morin | |
269 | 9 | Lionel Morin | # Définir les frameworks de test et la couverture de test |
270 | 9 | Lionel Morin | # Automatisation côté développeur |
271 | 9 | Lionel Morin | # Automatisation côté serveur |
272 | 9 | Lionel Morin | |
273 | 1 | Lionel Morin | h3. Développement piloté par les fonctionnalités |
274 | 1 | Lionel Morin | |
275 | 7 | Lionel Morin | L’utilisation de la méthode agile SCRUM permet : |
276 | 7 | Lionel Morin | |
277 | 9 | Lionel Morin | * de se focaliser sur les fonctionnalités demandées par l’utilisateur final |
278 | 9 | Lionel Morin | * d’avoir des retours rapides de l’utilisateur sur les fonctionnalités implémentées |
279 | 1 | Lionel Morin | |
280 | 1 | Lionel Morin | Priorisation: |
281 | 1 | Lionel Morin | |
282 | 9 | Lionel Morin | # Réviser l'écriture des scénarios (une fonctionnalité = un scénario) |
283 | 9 | Lionel Morin | |
284 | 1 | Lionel Morin | h3. Documentation d’API automatique |
285 | 1 | Lionel Morin | |
286 | 9 | Lionel Morin | * Génération de la documentation d'API depuis le code |
287 | 9 | Lionel Morin | ** API Métier (librairies) |
288 | 9 | Lionel Morin | ** API REST |
289 | 9 | Lionel Morin | ** API Frontend (composants / services) |
290 | 9 | Lionel Morin | * Cette génération doit être faite de façon automatique dans le processus de livraison/compilation |
291 | 9 | Lionel Morin | * Cette documentation doit être mise à disposition de la communauté (paquet *-doc* et site en ligne) |
292 | 7 | Lionel Morin | |
293 | 7 | Lionel Morin | Priorisation: |
294 | 7 | Lionel Morin | |
295 | 9 | Lionel Morin | # Définir les frameworks de documentation |
296 | 9 | Lionel Morin | # Automatiser la génération (côté développeur) |
297 | 9 | Lionel Morin | # Automatiser la génération (coté serveur, phase release + diffusion) |
298 | 9 | Lionel Morin | |
299 | 7 | Lionel Morin | h3. Modèle de développement avec Git |
300 | 7 | Lionel Morin | |
301 | 9 | Lionel Morin | Utiliser le modèle de développement "Gitflow":http://nvie.com/posts/a-successful-git-branching-model/. |
302 | 7 | Lionel Morin | |
303 | 9 | Lionel Morin | La "version AVH":https://github.com/petervanderdoes/gitflow-avh du logiciel **gitflow** est celle fournie par défaut sur Debian et Ubuntu, elle est maintenue contrairement à la version originelle. |
304 | 7 | Lionel Morin | |
305 | 7 | Lionel Morin | En résumé: |
306 | 7 | Lionel Morin | |
307 | 9 | Lionel Morin | * Chaque fonctionnalité est développée dans une branche dédiée (*feature/foo-bar*) |
308 | 9 | Lionel Morin | * Chaque fonctionnalité est intégrée à la branche d’intégration : |
309 | 9 | Lionel Morin | ** Si les tests passent |
310 | 9 | Lionel Morin | ** Après une relecture/validation du code (Gerrit) |
311 | 9 | Lionel Morin | * La préparation d’une livraison se fait sur une branche dédiée issue de la branche d’intégration (*release/1.2*) |
312 | 9 | Lionel Morin | * La branche *release/*, une fois prête, est fusionnée à la branche de production et un tag de release est créé |
313 | 1 | Lionel Morin | |
314 | 1 | Lionel Morin | Priorisation: |
315 | 1 | Lionel Morin | |
316 | 9 | Lionel Morin | # Mise en place de git flow (formation ?, document référent, définition de la configuration par défaut) |
317 | 9 | Lionel Morin | |
318 | 1 | Lionel Morin | h3. Qualité du code |
319 | 1 | Lionel Morin | |
320 | 1 | Lionel Morin | Des processus automatiques doivent être mis en place afin d’assurer une bonne qualité du code produit : |
321 | 1 | Lionel Morin | |
322 | 9 | Lionel Morin | * Le code doit correspondre au coding standard du projet (PyLint / Perl::Critic / JSLint) |
323 | 9 | Lionel Morin | * Le code doit être couvert par des tests unitaires |
324 | 9 | Lionel Morin | * L'API doit être documentée |
325 | 9 | Lionel Morin | |
326 | 1 | Lionel Morin | h3. Intégration continue |
327 | 1 | Lionel Morin | |
328 | 10 | Lionel Morin | * Exécution automatique des tests fonctionnels et unitaires (jenkins) |
329 | 1 | Lionel Morin | |
330 | 1 | Lionel Morin | h3. Déploiement d'environnements de Dev (Vagrant?) |