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