EnvoleBonnesPratiques » Historique » Version 74
Version 73 (Lionel Morin, 14/09/2012 14:50) → Version 74/75 (Lionel Morin, 17/09/2012 11:59)
h2. !http://dev-eole.ac-dijon.fr/attachments/download/9/puce.png! Environnement Libre Ouvert Evolutif - Envole
{{include(eole:menu)}}
h1. Les Bonnes Pratiques
{{include(ModeleEbauche)}}
h2. Documentations, sources et articles wiki
Voici les bonnes pratiques sur le nommage des applications EOLE : http://dev-eole.ac-dijon.fr/projects/documentations/wiki/DokielGuideBonnesPratiques
h2. Git
h3. Placement
Les applications de Envole sont des sous-projets de "Envole":http://dev-eole.ac-dijon.fr/projects/envole .
Dans le dépôt ils apparaissent les un à côté des autres (à plat).
h3. Les Bonnes Pratiques
Les Bonnes Pratiques de Git généralité et autres : http://dev-eole.ac-dijon.fr/projects/eole/wiki/GitBonnesPratiques
Recueil de commandes Git : http://dev-eole.ac-dijon.fr/projects/eole/wiki/RecueilGit
Lorsque le master existe il contient les sources de la première version du paquet.
Créer une nouvelle branche en vue d'ajouter des développements
<pre>
$ git checkout -b devel
$ git push --all
</pre>
h3. prompt sympa pour git
Ajouter les lignes suivantes à votre .bashrc pour un peu plus de confort
<pre>
toUpper() {
echo $1 | tr "[:lower:]" "[:upper:]"
}
parse_git_branch() {
branch=`git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'`
if [ "$branch" != "" ];then
label=`toUpper $branch`
fi
echo $label
}
</pre>
h3. Nommage
Le nom des sous-projets doivent être en minuscule
Exemple dans la liste des sous-projets : http://dev-eole.ac-dijon.fr/projects/envole
h3. Structure du Master
Puisque votre développement n'est pas la branche d'un projet déjà existant on réalise un master.
Pour cela il faut créer selon les besoins de votre application les fichiers et répertoires suivant (remplacez <appli> par le nom de votre projet et <version> par sa version) :
* /src/
** <appli>-<version>/
** plugins-<version>/nom/
** lang-<version>/nom/
* /tmpl/
* /dicos/
* /pretemplate/
* /posttemplate/
* /postservice/
* /sql/
** gen/
** updates/
** conf/
*** gen/
*** updates/
*** pwd/
* /sso/
** filtres/
** user-info/
* /ldap/
** pwd/
* /sharenvole/
* Makefile
* eole.mk
* apps.mk
Commentaires :
* /src/ : répertoire des sources de l'application
* /src/<appli>-<version>/ : sources de l'application avec la possibilité de faire cohabiter plusieurs versions lors des mises à jour
* /src/plugins-<version>/ : dossier contenant les plugins externes et ceux développés en interne pour cette version (un dossier par plugin)
* /src/lang-<version>/ : dossier des traductions pour cette version (un dossier par langue)
* /tmpl/ : répertoire des templates eole
* /dicos/ : dictionnaire eole (XX_<appli>.xml)
* /pretemplate/, /posttemplate/, /postservice/ : scripts shell ou python
* /sql/gen/ et /sql/updates : fichiers sql de création ou de mise à jour de la base
* /sql/conf/ : sous-répertoires de configuration
* /sso/filtres/ : filtres sso (<appli>.ini, <appli>_apps.ini)
* /sso/user-info/ : profil sso (profil_<appli>.py)
* /ldap/pwd/ : configuration du mot de passe ldap (<appli>.ini)
* /sharenvole/ : scripts d'aide à l'installation (à éviter si possible)
* Makefile : Fichier de règles de "compilation"
* eole.mk : Règles standard Eole pour la gestion des dictionnaires, templates, gestion des bases de données, mots de passe ... ! ne pas changer ce fichier
* apps.mk : Règles pour l'installation de l'application web.
Les patchs sont gérés dans la branche de packaging : http://dev-eole.ac-dijon.fr/projects/envole/wiki/PatchQuilt. http://dev-eole.ac-dijon.fr/projects/envole/wiki/PatchAvance.
Pour récupérer des exemples de fichier rendez-vous dans le projet d'exemple eole-skeletor Exemple :
http://dev-eole.ac-dijon.fr/projects/eole-skeletor/repository/show/?rev=dist%2Fubuntu%2Flucid%2Fmaster http://dev-eole.ac-dijon.fr/projects/dokuwiki/repository
h2. Les fichiers templates
Le nom d'un fichier templétisé ne doit pas porter le même nom qu'un autre pour cela il faut préfixer le nom du fichier avec le nom de l'application.
Exemple du fichier config.php qui est présent dans une bonne partie des applications :
taskfreak_config.php
h2. Dico
h3. Nommage
Les applications du socle
<pre>5x_nom_de_l_application.xml</pre>
Les applications supplémentaires au socle
<pre>6x_nom_de_l_application.xml</pre>
x étant supérieur à 0
h3. construction du fichier
L'activation/la désactivation des applications se fait dans la famille "Applications web". Il ne faut pas utiliser de séparateur.
{{include(ModeleFixme)}}
h2. Paquetage
h3. nommage du paquet
eole-nom_de_l_application
h3. fichiers postinst postrm
dans les fichiers postinst et postrm il faut utiliser des chemins absolus pour les commandes :
<pre>/bin/cp</pre>
h2. Apache
h3. nommage du fichier de conf dans sites-enabled
Un fichier de conf apache par application :
<pre>apache-nom_de_l_application.conf</pre>
h3. contenu du fichier de conf dans sites-enabled
Le chemin de l'application doit être son nom
Si un projet ne contient pas de .htaccess il faut ajouter la directive *AllowOverride None*.
Celle-ci permet de diminuer le délai d'attente en lui évitant de partir à la recherche de fichier .htaccess dans chaque répertoire qu'il visite.
Date d'expiration du cache proxy ou navigateur.
Régler correctement et finement le cache des clients permet d'éviter un grand nombre de requête.
En prévision de l'activation du *mod_expires* sur le serveur Apache, on peut ajouter la directive *ExpiresActive On* suivit de directive *ExpiresByType type "durée de vie dans le cache"*
<pre>
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/html "access plus 1 day"
</IfModule>
</pre>
Exemple complet d'un fichier de configuration d'une application :
<pre>
# Envole Infos
# Equipe EOLE
Alias /envole-infos /var/www/html/envole-infos
<Directory "/var/www/html/envole-infos">
AllowOverride None
AddDefaultCharset UTF-8
DirectoryIndex index.php
Order Allow,Deny
Allow from All
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/html "access plus 1 day"
ExpiresByType text/xml "access plus 1 day"
ExpiresByType image/gif "access plus 1 week"
ExpiresByType image/jpg "access plus 1 week"
ExpiresByType image/png "access plus 1 week"
ExpiresByType video/quicktime "access plus 1 month"
ExpiresByType audio/mpeg "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType application/ps "access plus 1 month"
ExpiresByType text/css "access plus 1 day"
ExpiresByType application/x-shockwave-flash "access plus 1 day"
ExpiresByType text/js "access plus 1 week"
ExpiresByType text/javascript "access plus 1 week"
ExpiresByType application/x-javascript "access plus 1 week"
ExpiresByType image/x-icon "access plus 1 day"
</IfModule>
</Directory>
</pre>
h2. répertoire debian (empaquetage)
h3. le changelog
<pre>
eole-envole-tools (1.0-eole1) eole-2.2-dev; urgency=low
* Initial release
-- Equipe Eole <eole@ac-dijon.fr> Fri, 20 May 2011 09:25:40 +0200
</pre>
La date s'obtient avec la commande date -R
h3. les droits dans /var/www/html/
Application des droits minimaux sur les répertoires:
<pre>
# Définition du propriétaire du répertoire
/bin/chown -R root:www-data /var/www/html/votre_appli<br />
# Définition des droits minimaux pour les répertoires (ont besoin d'être exécutables)
/bin/chmod -R 750 /var/www/html/votre_appli<br />
# Définition des droits minimaux pour les fichiers
/usr/bin/find /var/www/html/votre_appli -type f -exec /bin/chmod ugo-x {} \;
</pre>
Pour des raisons de sécurité seuls les fichiers nécessitant d'être modifiés par l'application sont éditables par l'utilisateur avec lequel est lancé apache à savoir www-data.
<pre>
/bin/chmod 770 /var/www/html/votre_appli/datas
/bin/chmod 660 /var/www/html/votre_appli/datas/*.*
</pre>
h2. Base de données
<pre>scribe-nom_de_l_application.sql</pre>
Si la bdd nécessite une templétisation il est préférable de découper la bdd en deux fichiers MySql.
L'un avec la partie à templétiser et l'autre avec le reste.
Cette découpe fait gagner un temps considérable lors du reconfigure.
h2. Stockage des données
FIXME : méthode obsolète -> méthode bacula
Exemple de Dokuwiki
Pour être prise en charge par la sauvegarde Bacula les données des applications sont stockées dans :
<pre>
/home/www-data/var/www/html/nom_de_l'application
</pre>
h2. CASsifier une application
Se référer à la documentation suivante :
http://dev-eole.ac-dijon.fr/projects/eole-php5-cas/wiki
h2. Commandes systèmes
h3. Patch
==Création d'un patch==
<pre>diff -uNr toto/ toto.new/ > patch/toto.patch</pre>
NB : Utilisez des chemins relatifs
==Application d'un patch==
<pre>patch -d /home/username/travail -p0 < toto.patch</pre>
[[PatchQuilt|Créer un patch quilt]] [[patchAvance|Patch avancé]]
h3. Mot de passe
Changer les mots de passe PhpMyAdmin (mode interactif)
<pre>/usr/share/eole/mysql_pwd.py</pre>
Changer le mot de passe root de PhpMyAdmin
<pre>
/usr/share/eole/mysql_pwd.py monMotDePass
</pre>
Remettre un mot de passe aléatoire
<pre>
/usr/share/eole/mysql_pwd.py `/usr/bin/pwgen -1`
</pre>
h3. Debugger
Usage :
<pre>
include('envolePHP/logger.php');
$monlogger = new Logger("/var/log/monfichier.log");
$monlogger->debug('msg');
$monlogger->error('erreur');
</pre>
h2. Intégration au bureau Posh
Voici la marche à suivre pour que votre nouvelle application apparaisse automatiquement dans les items de bureau de Posh.
Dans le paquet eole-posh, mettre l’icône (32x32) de la nouvelle application dans :
<pre>
plugins/plugin_desktop/icones
</pre>
Puis ajouter l'item de bureau dans le fichier :
<pre>
eole/tmpls/poshprofile-update.sql
</pre>
Exemple :
<pre>
-- piwigo (Galerie de photos)
%if %%is_defined('activer_piwigo') and %%activer_piwigo == 'oui'
CALL InsertDesktopItem('piwigo', 'Galerie<br />de photos', '/piwigo', '%%alias_envole/includes/plugins/plugin_desktop/icones/piwigo.png');
%end if
</pre>
h2. Logiciels
h3. Firebug
Très pratique dans la conception de page web.
Console permettant le debbugage Javascript et Css :
https://addons.mozilla.org/firefox/1843/
h2. Batterie de tests
h3. Tester la compilation du paquet (postinst, Makefile, ...)
Il est possible de tester la compilation de votre paquet sur une machine perso :
exporter vos sources :
<pre>
git archive nomDeBranche | tar -x -C /somewhere/else
</pre>
Se rendre dans le répertoire des sources et compiler sans signer (-uc -us)
<pre>
fakeroot dpkg-buildpackage -uc -us
</pre>
Le paquet est disponible dans le répertoire parent.
h3. Tester le paquet
Le nouveau paquet doit être testé en fresh install et en update (cas de figure où l'application est en production).
h3. Test de l'application
L'application doit être testée avec tous les types de comptes utilisateurs.
h2. Documentation
h3. Première mouture
Il faut documenter une application avant son passage en candidat.
Ouvrez une page wiki et y mettre les changements majeurs concernant
l'installation, les rôles, les consignes diverses ...
Ses informations doivent permettre de faciliter la vie du testeur.
h3. Finalisation
L'utilisateur doit trouver la doc à jour au moment où il en a besoin.
Aussi votre documentation doit être faite avant la sortie du paquet en stable.
Si vous n'avez pas accès au logiciel pour élaborer la doc, posez un signalement dans "Documentations" en mettant le lien vers la page wiki.
h2. Fioritures
Les couleurs pour uniformiser les applications.
jaune pâle max #fff999
jaune pâle mini #ffffcc
jaune orangé logo Eole #ffcc29
mauve logo Eole #57537e
h2. Divers
Logiciel de packaging Epack : http://test-eoleng.ac-dijon.fr/eoleng/eole-2.2-security/all/eolepack_2.2-eole37_all.deb
{{include(eole:menu)}}
h1. Les Bonnes Pratiques
{{include(ModeleEbauche)}}
h2. Documentations, sources et articles wiki
Voici les bonnes pratiques sur le nommage des applications EOLE : http://dev-eole.ac-dijon.fr/projects/documentations/wiki/DokielGuideBonnesPratiques
h2. Git
h3. Placement
Les applications de Envole sont des sous-projets de "Envole":http://dev-eole.ac-dijon.fr/projects/envole .
Dans le dépôt ils apparaissent les un à côté des autres (à plat).
h3. Les Bonnes Pratiques
Les Bonnes Pratiques de Git généralité et autres : http://dev-eole.ac-dijon.fr/projects/eole/wiki/GitBonnesPratiques
Recueil de commandes Git : http://dev-eole.ac-dijon.fr/projects/eole/wiki/RecueilGit
Lorsque le master existe il contient les sources de la première version du paquet.
Créer une nouvelle branche en vue d'ajouter des développements
<pre>
$ git checkout -b devel
$ git push --all
</pre>
h3. prompt sympa pour git
Ajouter les lignes suivantes à votre .bashrc pour un peu plus de confort
<pre>
toUpper() {
echo $1 | tr "[:lower:]" "[:upper:]"
}
parse_git_branch() {
branch=`git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'`
if [ "$branch" != "" ];then
label=`toUpper $branch`
fi
echo $label
}
</pre>
h3. Nommage
Le nom des sous-projets doivent être en minuscule
Exemple dans la liste des sous-projets : http://dev-eole.ac-dijon.fr/projects/envole
h3. Structure du Master
Puisque votre développement n'est pas la branche d'un projet déjà existant on réalise un master.
Pour cela il faut créer selon les besoins de votre application les fichiers et répertoires suivant (remplacez <appli> par le nom de votre projet et <version> par sa version) :
* /src/
** <appli>-<version>/
** plugins-<version>/nom/
** lang-<version>/nom/
* /tmpl/
* /dicos/
* /pretemplate/
* /posttemplate/
* /postservice/
* /sql/
** gen/
** updates/
** conf/
*** gen/
*** updates/
*** pwd/
* /sso/
** filtres/
** user-info/
* /ldap/
** pwd/
* /sharenvole/
* Makefile
* eole.mk
* apps.mk
Commentaires :
* /src/ : répertoire des sources de l'application
* /src/<appli>-<version>/ : sources de l'application avec la possibilité de faire cohabiter plusieurs versions lors des mises à jour
* /src/plugins-<version>/ : dossier contenant les plugins externes et ceux développés en interne pour cette version (un dossier par plugin)
* /src/lang-<version>/ : dossier des traductions pour cette version (un dossier par langue)
* /tmpl/ : répertoire des templates eole
* /dicos/ : dictionnaire eole (XX_<appli>.xml)
* /pretemplate/, /posttemplate/, /postservice/ : scripts shell ou python
* /sql/gen/ et /sql/updates : fichiers sql de création ou de mise à jour de la base
* /sql/conf/ : sous-répertoires de configuration
* /sso/filtres/ : filtres sso (<appli>.ini, <appli>_apps.ini)
* /sso/user-info/ : profil sso (profil_<appli>.py)
* /ldap/pwd/ : configuration du mot de passe ldap (<appli>.ini)
* /sharenvole/ : scripts d'aide à l'installation (à éviter si possible)
* Makefile : Fichier de règles de "compilation"
* eole.mk : Règles standard Eole pour la gestion des dictionnaires, templates, gestion des bases de données, mots de passe ... ! ne pas changer ce fichier
* apps.mk : Règles pour l'installation de l'application web.
Les patchs sont gérés dans la branche de packaging : http://dev-eole.ac-dijon.fr/projects/envole/wiki/PatchQuilt. http://dev-eole.ac-dijon.fr/projects/envole/wiki/PatchAvance.
Pour récupérer des exemples de fichier rendez-vous dans le projet d'exemple eole-skeletor Exemple :
http://dev-eole.ac-dijon.fr/projects/eole-skeletor/repository/show/?rev=dist%2Fubuntu%2Flucid%2Fmaster http://dev-eole.ac-dijon.fr/projects/dokuwiki/repository
h2. Les fichiers templates
Le nom d'un fichier templétisé ne doit pas porter le même nom qu'un autre pour cela il faut préfixer le nom du fichier avec le nom de l'application.
Exemple du fichier config.php qui est présent dans une bonne partie des applications :
taskfreak_config.php
h2. Dico
h3. Nommage
Les applications du socle
<pre>5x_nom_de_l_application.xml</pre>
Les applications supplémentaires au socle
<pre>6x_nom_de_l_application.xml</pre>
x étant supérieur à 0
h3. construction du fichier
L'activation/la désactivation des applications se fait dans la famille "Applications web". Il ne faut pas utiliser de séparateur.
{{include(ModeleFixme)}}
h2. Paquetage
h3. nommage du paquet
eole-nom_de_l_application
h3. fichiers postinst postrm
dans les fichiers postinst et postrm il faut utiliser des chemins absolus pour les commandes :
<pre>/bin/cp</pre>
h2. Apache
h3. nommage du fichier de conf dans sites-enabled
Un fichier de conf apache par application :
<pre>apache-nom_de_l_application.conf</pre>
h3. contenu du fichier de conf dans sites-enabled
Le chemin de l'application doit être son nom
Si un projet ne contient pas de .htaccess il faut ajouter la directive *AllowOverride None*.
Celle-ci permet de diminuer le délai d'attente en lui évitant de partir à la recherche de fichier .htaccess dans chaque répertoire qu'il visite.
Date d'expiration du cache proxy ou navigateur.
Régler correctement et finement le cache des clients permet d'éviter un grand nombre de requête.
En prévision de l'activation du *mod_expires* sur le serveur Apache, on peut ajouter la directive *ExpiresActive On* suivit de directive *ExpiresByType type "durée de vie dans le cache"*
<pre>
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/html "access plus 1 day"
</IfModule>
</pre>
Exemple complet d'un fichier de configuration d'une application :
<pre>
# Envole Infos
# Equipe EOLE
Alias /envole-infos /var/www/html/envole-infos
<Directory "/var/www/html/envole-infos">
AllowOverride None
AddDefaultCharset UTF-8
DirectoryIndex index.php
Order Allow,Deny
Allow from All
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/html "access plus 1 day"
ExpiresByType text/xml "access plus 1 day"
ExpiresByType image/gif "access plus 1 week"
ExpiresByType image/jpg "access plus 1 week"
ExpiresByType image/png "access plus 1 week"
ExpiresByType video/quicktime "access plus 1 month"
ExpiresByType audio/mpeg "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType application/ps "access plus 1 month"
ExpiresByType text/css "access plus 1 day"
ExpiresByType application/x-shockwave-flash "access plus 1 day"
ExpiresByType text/js "access plus 1 week"
ExpiresByType text/javascript "access plus 1 week"
ExpiresByType application/x-javascript "access plus 1 week"
ExpiresByType image/x-icon "access plus 1 day"
</IfModule>
</Directory>
</pre>
h2. répertoire debian (empaquetage)
h3. le changelog
<pre>
eole-envole-tools (1.0-eole1) eole-2.2-dev; urgency=low
* Initial release
-- Equipe Eole <eole@ac-dijon.fr> Fri, 20 May 2011 09:25:40 +0200
</pre>
La date s'obtient avec la commande date -R
h3. les droits dans /var/www/html/
Application des droits minimaux sur les répertoires:
<pre>
# Définition du propriétaire du répertoire
/bin/chown -R root:www-data /var/www/html/votre_appli<br />
# Définition des droits minimaux pour les répertoires (ont besoin d'être exécutables)
/bin/chmod -R 750 /var/www/html/votre_appli<br />
# Définition des droits minimaux pour les fichiers
/usr/bin/find /var/www/html/votre_appli -type f -exec /bin/chmod ugo-x {} \;
</pre>
Pour des raisons de sécurité seuls les fichiers nécessitant d'être modifiés par l'application sont éditables par l'utilisateur avec lequel est lancé apache à savoir www-data.
<pre>
/bin/chmod 770 /var/www/html/votre_appli/datas
/bin/chmod 660 /var/www/html/votre_appli/datas/*.*
</pre>
h2. Base de données
<pre>scribe-nom_de_l_application.sql</pre>
Si la bdd nécessite une templétisation il est préférable de découper la bdd en deux fichiers MySql.
L'un avec la partie à templétiser et l'autre avec le reste.
Cette découpe fait gagner un temps considérable lors du reconfigure.
h2. Stockage des données
FIXME : méthode obsolète -> méthode bacula
Exemple de Dokuwiki
Pour être prise en charge par la sauvegarde Bacula les données des applications sont stockées dans :
<pre>
/home/www-data/var/www/html/nom_de_l'application
</pre>
h2. CASsifier une application
Se référer à la documentation suivante :
http://dev-eole.ac-dijon.fr/projects/eole-php5-cas/wiki
h2. Commandes systèmes
h3. Patch
==Création d'un patch==
<pre>diff -uNr toto/ toto.new/ > patch/toto.patch</pre>
NB : Utilisez des chemins relatifs
==Application d'un patch==
<pre>patch -d /home/username/travail -p0 < toto.patch</pre>
[[PatchQuilt|Créer un patch quilt]] [[patchAvance|Patch avancé]]
h3. Mot de passe
Changer les mots de passe PhpMyAdmin (mode interactif)
<pre>/usr/share/eole/mysql_pwd.py</pre>
Changer le mot de passe root de PhpMyAdmin
<pre>
/usr/share/eole/mysql_pwd.py monMotDePass
</pre>
Remettre un mot de passe aléatoire
<pre>
/usr/share/eole/mysql_pwd.py `/usr/bin/pwgen -1`
</pre>
h3. Debugger
Usage :
<pre>
include('envolePHP/logger.php');
$monlogger = new Logger("/var/log/monfichier.log");
$monlogger->debug('msg');
$monlogger->error('erreur');
</pre>
h2. Intégration au bureau Posh
Voici la marche à suivre pour que votre nouvelle application apparaisse automatiquement dans les items de bureau de Posh.
Dans le paquet eole-posh, mettre l’icône (32x32) de la nouvelle application dans :
<pre>
plugins/plugin_desktop/icones
</pre>
Puis ajouter l'item de bureau dans le fichier :
<pre>
eole/tmpls/poshprofile-update.sql
</pre>
Exemple :
<pre>
-- piwigo (Galerie de photos)
%if %%is_defined('activer_piwigo') and %%activer_piwigo == 'oui'
CALL InsertDesktopItem('piwigo', 'Galerie<br />de photos', '/piwigo', '%%alias_envole/includes/plugins/plugin_desktop/icones/piwigo.png');
%end if
</pre>
h2. Logiciels
h3. Firebug
Très pratique dans la conception de page web.
Console permettant le debbugage Javascript et Css :
https://addons.mozilla.org/firefox/1843/
h2. Batterie de tests
h3. Tester la compilation du paquet (postinst, Makefile, ...)
Il est possible de tester la compilation de votre paquet sur une machine perso :
exporter vos sources :
<pre>
git archive nomDeBranche | tar -x -C /somewhere/else
</pre>
Se rendre dans le répertoire des sources et compiler sans signer (-uc -us)
<pre>
fakeroot dpkg-buildpackage -uc -us
</pre>
Le paquet est disponible dans le répertoire parent.
h3. Tester le paquet
Le nouveau paquet doit être testé en fresh install et en update (cas de figure où l'application est en production).
h3. Test de l'application
L'application doit être testée avec tous les types de comptes utilisateurs.
h2. Documentation
h3. Première mouture
Il faut documenter une application avant son passage en candidat.
Ouvrez une page wiki et y mettre les changements majeurs concernant
l'installation, les rôles, les consignes diverses ...
Ses informations doivent permettre de faciliter la vie du testeur.
h3. Finalisation
L'utilisateur doit trouver la doc à jour au moment où il en a besoin.
Aussi votre documentation doit être faite avant la sortie du paquet en stable.
Si vous n'avez pas accès au logiciel pour élaborer la doc, posez un signalement dans "Documentations" en mettant le lien vers la page wiki.
h2. Fioritures
Les couleurs pour uniformiser les applications.
jaune pâle max #fff999
jaune pâle mini #ffffcc
jaune orangé logo Eole #ffcc29
mauve logo Eole #57537e
h2. Divers
Logiciel de packaging Epack : http://test-eoleng.ac-dijon.fr/eoleng/eole-2.2-security/all/eolepack_2.2-eole37_all.deb