Archives par mot-clé : upgrade

There comes the time to upgrade.

I want to reflect on the past to propel to the future!

At that time, my goal was only to update this extension for PHP 7.0.
At that time, I have written a couple of little programs in C, most in C++, and so many in PHP since its version 3.

I have taken out the Win32Service extension from the oldest SVN repository on May 29 2016. The most recent SVN commit is on July 26 2011.

It is hard work to understand how to write a PHP extension, but with time, documentation, books, friends and labor, I released version 0.1.2-dev on October 16 2016.

At that time, some ground-work was done.

  • The AppVeyor service was set on the project.
  • The DLL are built for x86 and amd64
  • The DLL are available with (TS) and without (NTS) Thread Safe mode.

But the work was far from done, and the first version really usable for PHP 7.0 was version 0.2.0, released on March 23 2017.

The work for version 0.2 span over 10 months during my free time. I’m really proud of my work.

Since the 0.2 version, I have released one other version in 2017, two in 2018, three in 2019 (four versions soon)…

I have added some features asked by users in the old PHP documentation comments, on the PHP bug tracker or directly.

However, I have just received a little bit of feedback despite my calls for it.

Of course, I use Twitter to send my calls and the world is not only on Twitter, however, my network is so small, and my contacts don’t have an interests to forward my calls…

One can ask who in 2017, 2018, 2019, works on the Windows platform to write a PHP application when needing to run a script in the background? Who?

You would be surprised by the amount of people on Windows running PHP scripts, it is far greater than what you imagine.

The download statistics available from the Pecl web site show the interest for this extension.

The most downloaded version (v0.1. excluded) is version 0.2.1. The next one is 0.3.0, not 0.3.1 nor the last one: 0.3.2. Why? Surely because version 0.3.0 is the last version available for PHP 7.0!

Dear PHP developers, why don’t you update PHP? (This is a genuine question, please answer in the comments.)

So, as version 7.4 of PHP will be coming soon and I will release a new version. It is time to migrate to the latest version!

I need to thank you for your trust and if you want some help to upgrade your application, you can contact me in the comments.

Mettre à jour un projet Symfony 2

Dans cet article qui me servira d’aide mémoire, je vais tenter de vous présenter ma méthode de mise à jour d’un projet Symfony 2.

Cette méthode vaut ce qu’elle vaut mais je n’ai rien trouvé de tel sur internet ! Même en anglais.

Plantons le décor

Nous avons un projet qui fonctionne avec Symfony 2.2.11 et nous souhaitons le faire passer sur la version LTS de Symfony 2 soit la version 2.3.x. En effet, la branche 2.2 n’est plus maintenue.

Comme de nombreux projets, j’utilise des librairies et bundles tiers gérés via l’utilitaire Composer.

Avant de rentrer dans le vif du sujet et, comme je compte pouvoir revenir en arrière, je commence par installer mon application dans un nouveau dossier. L’application doit fonctionner parfaitement avant la mise à jour.

Maintenant que nous avons notre application installée, voyons comment mettre à jour les librairies.

Récupération de la version cible

 

Sur le site de l’éditeur de Symfony, je commence par télécharger la version souhaitée du framework sans les vendors (without vendors). Ou je télécharge depuis le dépôt GitHub de la standard edition pour Symfony jusqu’à 3.4 ou le dépôt GitHub du Website Skeleton pour Symfony 4 et plus.

Dans l’archive, je récupère le fichier « composer.json » afin de le comparer à celui du projet.

Lors de la comparaison, je modifie le fichier « composer.json » de mon projet et modifie les versions des packages.

Mise à jour des librairies tierces

Pour les librairies tierces, j’utilise le site packagist pour vérifier la compatibilité de chaque version utilisée. Au besoin, je recherche la version compatible et je change également la version dans le fichier « composer.json » du projet.

A chaque changement de version pour une librairie tierce, je vérifie que le fonctionnement n’a pas changé. Si c’est le cas, il faudra mettre à jour mon code.

Téléchargement des mises à jour

 

Dans un terminal, je me place à la racine du site et j’exécute la commande qui peut faire peur :

$ php composer.phar update

Et oui, cette commande va chercher à mettre à jour toutes les librairies. L’exécution est longue et lorsque le téléchargement commence, un soulagement se fait sentir. Aucun conflit n’a été trouvé; ça ne veut pas dire qu’il n’y aura pas d’erreur(s) lors de l’exécution.

Test des nouvelles librairies

 

Une fois les nouvelles versions téléchargées et installées, commence la phase de débug !

La première chose que je fais est de vider les caches en supprimant les dossiers présents dans le dossier app/cache (var/cache depuis Symfony 3). Puis, dans la console, j’exécute les commandes suivantes :

$ php app/console cache:warmup

$ php app/console cache:warmup –env=prod

 

Si aucune erreur n’est présente à ce moment-là, vous n’avez pas d’erreur au niveau des annotations.

Voici celle que j’ai eue :

@Assert\MaxLength(100) est remplacé par @Assert\Length(max=100)

 

Si vous utilisez le bundle JMS/SerializerBundle et si vous êtes passés de la version 1.x à la version 2.0, les annotations ont changé de place. Il faut donc changer toutes les instructions « use » de vos fichiers.

 

Maintenant que le kernel démarre, passons aux choses sérieuses.

 

Avez-vous écrit vos tests unitaires et fonctionnels ? Non, c’est une mauvaise idée mais il n’est pas trop tard pour le faire.

 

Pour détecter toutes les erreurs, je teste le logiciel dans les moindres détails. A chaque erreur rencontrée, je commence par écrire les tests unitaires et fonctionnels permettant de générer l’erreur. Le test échouera bien sûr mais sera concluant une fois la correction apportée.

 

Pourquoi perdre du temps à écrire des tests ? Et bien pour en gagner plus tard. Un test écrit pour un bug permet d’éviter son retour !

 

Car une fois que tous ces tests seront écrits, vous les exécuterez avant chaque livraison pour vérifier que tout fonctionne bien. Il n’est pas exclu qu’un bug passe au travers du filet.

 

Mise en production

 

Après quelques heures de travail, le logiciel fonctionne bien. Que reste-il à faire ?

Sauvegarder les corrections du code dans le gestionnaire de codes sources ainsi que les fichiers « composer.json » et « composer.lock ».

Ce dernier est le précieux sésame pour la mise en production. C’est grâce à lui et la commande suivante que l’installation se passera sans problème en production.

$ php composer.phar install –prefer-dist

 

Mon petit truc pour la mise en production : installer un nouveau site et une fois le nouveau site fonctionnel, réaliser la bascule. Ainsi, la coupure est limitée dans le temps.

D’autre part, j’évite de livrer de nouvelles fonctionnalités avec un changement de version du framework, surtout si elles modifient la base de données. Mais là chacun fait selon ses circonstances.

 

Bonne mise à jour ! Contactez moi si vous avez des difficultés !