Comment gérez-vous le changement des frameworks open source que vous utilisez pour vos projets?

C'est peut-être une bizarrerie personnelle, mais j'aime garder le code à jour des projets vivants - y compris les bibliothèques / cadres qu'ils utilisent. En partie, je pense qu'une application Web est plus sécurisée si elle est entièrement corrigée et à jour. Une partie de cela est juste une touche de compulsivité obsessionnelle de ma part.

Au cours des sept derniers mois, nous avons procédé à une réécriture majeure de notre logiciel. Nous avons abandonné le framework Xaraya, qui était lent et essentiellement mort en tant que produit, et converti en Cake PHP. (Nous avons choisi Cake car cela nous a donné la chance de faire une réécriture très rapide de notre logiciel, et suffisamment d'amélioration des performances par rapport à Xaraya pour que cela en vaille la peine.)

Nous avons implémenté les tests unitaires avec SimpleTest et suivi toutes les conventions de dénomination des fichiers et des bases de données, etc.

Cake est maintenant mis à jour vers 2.0. Et, il ne semble pas y avoir de chemin de migration viable pour une mise à niveau. Les conventions de dénomination des fichiers ont radicalement changé et ils ont abandonné SimpleTest en faveur de PHPUnit.

Cela va nous forcer à rester sur la branche 1.3 car, à moins qu'il n'y ait une sorte d'outil de conversion, il ne sera pas possible de mettre à jour Cake puis d'améliorer progressivement notre code hérité pour profiter des avantages du nouveau cadre Cake . Donc, comme d'habitude, nous allons nous retrouver avec un ancien framework dans notre dépôt Subversion et le patcher nous-mêmes au besoin.

Et c'est ce qui m'attire à chaque fois. De nombreux produits open source ne facilitent pas la mise à jour des projets basés sur eux. Lorsque les développeurs commenceront à jouer avec un nouveau jouet brillant, quelques correctifs critiques seront effectués sur les anciennes branches, mais la plupart de leurs efforts seront concentrés sur la nouvelle base de code.

Comment gérez-vous les changements radicaux dans les projets open source que vous utilisez? Et, si vous développez un produit open source, gardez-vous à l'esprit les chemins de mise à niveau lorsque vous développez de nouvelles versions?

Le problème n'est pas unique à l'open source. Les mêmes problèmes se produisent avec les projets commerciaux. Peut-être encore plus parce que vous n'avez pas de source, vous pouvez vous maintenir si l'entreprise abandonne le support.

Les projets open source de type utilisateur final ont des cycles de mise à niveau rapides et les anciennes versions perdent leur support très rapidement. D'un autre côté, les projets conçus pour que les utilisateurs mettent un effort de codage important sur le dessus ont tendance à avoir de longs cycles de support de l'ancienne branche après une mise à niveau majeure. Assez longtemps pour que vous preniez d'abord votre temps en attendant qu'il se stabilise et mûrisse, puis en migrant et en testant soigneusement votre propre code.

Il peut être difficile de résister à la tentation d'avoir la dernière et la meilleure, mais réalisez qu'il existe un compromis fondamental entre la stabilité et les nouvelles fonctionnalités. Vous ne pouvez pas en avoir un sans sacrifier l'autre. C'est pourquoi les branches de correction de bogues existent, vous pouvez donc choisir quel côté du spectre correspond le mieux à vos besoins.

Nous avons résolu ce problème en modularisant notre code.

Notre site Web principal a été construit il y a environ huit ans, et nous avons eu la chance qu'il soit construit par l'un des premiers contributeurs au framework Spring, donc c'était une fondation assez bien construite. Mais malheureusement, nous avons également eu la malchance que ce développeur ait décidé de bifurquer Spring après un argument sur la direction qu'il allait prendre, donc cette base de code est maintenant coincée sur une fourche non maintenue de Spring 1.1.4 (ou quelque chose de ce millésime).

Nous avons essayé de réécrire le code pour passer à de nouvelles versions de Spring, mais cela s'est avéré extrêmement difficile. Notre solution a donc été de commencer à créer de nouvelles fonctionnalités du site sous forme de modules dans une application complètement distincte, en utilisant les derniers frameworks tels que Spring 3.x, Hibernate 3.6, etc.

Nous avons maintenant deux applications Web exécutées sur la même URL de base et nous utilisons le module mod_proxy d'Apache pour allouer chaque chemin à l'application appropriée. Par exemple, "/ membres" va à l'ancienne application et "/ répertoires" va à la nouvelle application. Cependant, un visiteur du site n'aurait aucune idée qu'il utilise des applications différentes; ils ont exactement la même apparence pour l'utilisateur.

Les deux applications doivent communiquer, par exemple lorsqu'un membre se connecte au site (à l'aide de notre nouvelle application), nous devons informer l'ancienne application qu'il est maintenant connecté. Nous le faisons à l'aide d'un simple service Web, exposé uniquement à localhost. La quantité d'intégration nécessaire entre les deux applications s'est avérée minime.

Une partie importante de ce travail consistait à identifier et regrouper les actifs partagés. Ainsi, tous les textes, graphiques, feuilles de style, Javascript et modèles statiques ont été déplacés de l'application d'origine vers un troisième projet distinct que les applications anciennes et nouvelles utilisent. Cela garantit que les deux applications Web se ressemblent et agissent de la même manière, même si elles sont complètement séparées.

J'imagine qu'avec le temps, nous remplacerons de plus en plus l'application d'origine jusqu'à ce qu'elle soit finalement inutile. La bonne chose à propos de cette technique est que nous pouvons le faire lentement via une série de petites modifications à faible risque - il n'y a pas besoin d'un passage soudain massif et risqué à un nouveau système.

Je ne le fais pas toujours. De nombreux projets open source ont des branches de maintenance actives maintenues pour les versions majeures précédentes. Parfois, ceux-ci sont maintenus par des personnes qui ont besoin de cette version pour être maintenue. De nombreux projets restent sur une version majeure jusqu'à ce qu'ils soient eux-mêmes prêts pour une version majeure.

Et c'est ce qui m'attire à chaque fois.

À chaque fois? Vous devez faire des choix remarquablement mauvais. Il doit y avoir un exemple où cela ne s'est pas produit.

Quand les développeurs commencent à jouer avec un nouveau jouet brillant

Voilà un indice. Évitez les nouveaux jouets brillants lorsque vous utilisez des projets open source. Évitez la version 1.0.

Comment gérez-vous les changements radicaux dans les projets open source que vous utilisez?

Étape 1. Choisissez très soigneusement les projets open source. Comparez toujours deux ou plusieurs projets concurrents.

Étape 2. Lorsque vous comparez deux projets concurrents, essayez de comprendre la caractéristique «essentielle» qui est offerte et comment ils s'en approchent tous les deux. Évitez de «marier» une API spécifique trop tôt.

Étape 3. Adoptez les principes de conception de «liaison tardive» et de «couplage lâche». Essayez de vous isoler des modifications des projets open source.

Étape 4. Faites explicitement des comparaisons coûts / avantages entre les projets open source et «rouler le vôtre». De temps en temps, créer votre propre solution peut être mieux que de faire face à une solution open source.

La modification des noms de fichiers ne devrait pas être trop difficile. Oui, c'est un gros script moche. Oui, il doit être exécuté pendant plusieurs semaines lors de la conversion. Mais c'est un coût fini.

Si cela se produit à chaque fois, développez de meilleures stratégies d'adaptation. Puisque votre observation du monde réel est que cela va toujours arriver, alors espérer que le monde réel change ne va pas vraiment aider beaucoup. Vous avez une expérience du changement durement acquise. Tirez parti de cela. Considérez-le comme une infection et développez votre propre réponse immunitaire.