Bonjour,

Je voudrais vous soumettre une problématique sur laquelle nous réfléchissons actuellement sur mon projet, concernant le déploiement d'une application jelix via un processus d'intégration continue.

Le job d'intégration continue que nous mettons en place effectue un checkout de notre application Jelix depuis SVN. (Nous ne souhaitons pas lier le code qui tourne sur nos environnements à SVN et faire des update) Nous n'avons pas commité le fichier installer.ini.php étant donné que celui-ci est généré dynamiquement lors de l'exécution du script install.php utilisé pour la première install et les upgrades de modules ou schémas en BD.

Du coup, lors d'un checkout via notre processus d'intégration continue j'imagine que si jelix a déjà été installé auparavant, et étant donné que le fichier installer.ini.php n'est pas présent dans le checkout (puisque pas commité sur SVN), Jelix doit relancer une install from scratch alors que les tables existent déjà en base. Donc plantage.

Si les données présentes dans le fichier installer.ini.php étaient stockées et récupérées dans la base plutôt que dans un fichier, n'où n'aurions pas cette problématique.

Auriez-vous un moyen clean et qui colle avec le framework pour gérer cette situation? Pourrait-on faire évoluer le framework afin de permettre la sauvegarde du changelog en base plutôt que dans le fichier installer.ini.php?

Bonjour,

Nous ne souhaitons pas lier le code qui tourne sur nos environnements à SVN et faire des update

Pourquoi faut-il vraiment faire un checkout ? pourquoi pas un simple update ?

Nous n'avons pas commité le fichier installer.ini.php étant donné que celui-ci est généré dynamiquement lors de l'exécution du script install.php utilisé pour la première install et les upgrades de modules ou schémas en BD.

tout à fait, ce fichier ne doit jamais être commité dans un dépot, tout comme le profils.ini.php.

Du coup, lors d'un checkout via notre processus d'intégration continue j'imagine que si jelix a déjà été installé auparavant, et étant donné que le fichier installer.ini.php n'est pas présent dans le checkout (puisque pas commité sur SVN), Jelix doit relancer une install from scratch alors que les tables existent déjà en base. Donc plantage.

logique

Si les données présentes dans le fichier installer.ini.php étaient stockées et récupérées dans la base plutôt que dans un fichier, n'où n'aurions pas cette problématique.

que ce soit dans un fichier ou en base, ça ne change rien. Parce que pour accéder à la base, il te faut un fichier profils.ini.php, qui n'est à priori pas dans le svn (pour des raisons évidentes de sécurité)

Donc pourquoi tu aurais le problème avec ce fichier installer.ini.php et pas profils.ini.php ?

La solution que je vois c'est d'avoir un processus d'installation de tes sources pour l'intégration continue, plus complet :

1. tu checkout
2. tu copie une sauvegarde de tout les fichiers "dynamiques" non présent dans le svn : profils.ini.php, installer.ini.php
3. tu lances l'installeur, pour tenir compte des éventuels scripts de mise à jour
4. tu sauvegardes le fichier installer.ini.php et autres fichiers dynamiques qui auraient pu être modifié par la mise à jour
5. les tests et autres tâches peuvent être lancées

Et c'est là peut-être qu'utiliser Phing ou autre serait effectivement intéressant, comme tu m'en avais parlé par mail (si c'est bien toi qui m'a posé plein de question par mail cette semaine)

PS: installer.ini.php n'est pas un changelog, il n'y a pas d'historique dans installer.ini.php.

Bonjour Laurent,

Merci pour ce retour. Ci-dessous mes réponses.

laurentj a dit :
Bonjour,

Nous ne souhaitons pas lier le code qui tourne sur nos environnements à SVN et faire des update

Pourquoi faut-il vraiment faire un checkout ? pourquoi pas un simple update ?

Pour être sûr de récupérer une version clean d'SVN et écraser d'éventuelles modifications locales sur l'environnement.

Nous n'avons pas commité le fichier installer.ini.php étant donné que celui-ci est généré dynamiquement lors de l'exécution du script install.php utilisé pour la première install et les upgrades de modules ou schémas en BD.

tout à fait, ce fichier ne doit jamais être commité dans un dépot, tout comme le profils.ini.php.

En fait nous réfléchissons actuellement à une harmonisation de nos outils de gestion de configuration et de déploiement pour l'ensemble de nos applications PHP, qui ne tournent malheureusement pas toutes sous Jelix. Nous n'avons pas encore choisi de manière définitive la solution à mettre en oeuvre. ( repository SVN dédié à la conf d'environnements pour versioning, mutalisation sur un serveur de fichiers ...)

Du coup, lors d'un checkout via notre processus d'intégration continue j'imagine que si jelix a déjà été installé auparavant, et étant donné que le fichier installer.ini.php n'est pas présent dans le checkout (puisque pas commité sur SVN), Jelix doit relancer une install from scratch alors que les tables existent déjà en base. Donc plantage.

logique

Si les données présentes dans le fichier installer.ini.php étaient stockées et récupérées dans la base plutôt que dans un fichier, n'où n'aurions pas cette problématique.

que ce soit dans un fichier ou en base, ça ne change rien. Parce que pour accéder à la base, il te faut un fichier profils.ini.php, qui n'est à priori pas dans le svn (pour des raisons évidentes de sécurité)

Donc pourquoi tu aurais le problème avec ce fichier installer.ini.php et pas profils.ini.php ?

Nous comptons externaliser ce fichier (qui contient de la config propre à l'environnement d'exécution) dans notre futur outil de gestion de configuration. Pour le moment nous maintenons donc un fichier profils.ini spécifique à notre environnement d'intégration continue et le déployons dans le process d'intégration continue. Nous avons constaté que le script runTests.php associé à l'execution des tests unitaires, ne passait pas en l'absence du fichier installer.ini.php (d'où mon message). Finalement nous avons pour le moment désactivé l'utilisation de l'installer jelix via l'option disableInstallers=on.

La solution que je vois c'est d'avoir un processus d'installation de tes sources pour l'intégration continue, plus complet :

# tu checkout
# tu copie une sauvegarde de tout les fichiers "dynamiques" non présent dans le svn : profils.ini.php, installer.ini.php
# tu lances l'installeur, pour tenir compte des éventuels scripts de mise à jour
# tu sauvegardes le fichier installer.ini.php et autres fichiers dynamiques qui auraient pu être modifié par la mise à jour
# les tests et autres tâches peuvent être lancées

Et c'est là peut-être qu'utiliser Phing ou autre serait effectivement intéressant, comme tu m'en avais parlé par mail (si c'est bien toi qui m'a posé plein de question par mail cette semaine)

Tout à fait, on l'utilise déjà dans notre processus d'intégration continue. Ca nous permettrait effectivement de mettre en place facilement ce genre de procédure. (C'était bien moi le mail avec un tas de questions :) )

PS: installer.ini.php n'est pas un changelog, il n'y a pas d'historique dans installer.ini.php.