Développement à l'aide d'outils de développement pré-version

Question

Nous développons un site Web. L'un des outils de développement que nous utilisons a une version alpha disponible de sa prochaine version qui comprend un certain nombre de fonctionnalités que nous voulons vraiment utiliser (c'est-à-dire qu'elles nous éviteraient d'avoir à mettre en œuvre des milliers de lignes à faire à peu près). exactement la même chose de toute façon).

J'ai fait quelques évaluations initiales dessus et j'aime ce que je vois. La question est, devrions-nous commencer à l'utiliser réellement pour de vrai? c'est-à-dire au-delà de simplement l'évaluer, en l'utilisant réellement pour notre développement et en nous appuyant dessus?

En tant que logiciel alpha, il n'est évidemment pas encore prêt pour la publication ... mais notre propre code n'est pas non plus. C'est un logiciel open source, et nous avons les compétences nécessaires pour le déboguer, afin que nous puissions en théorie apporter des corrections de bogues. Mais d'un autre côté, nous ne savons pas quel est le calendrier de publication (ils n'en ont pas encore publié), et même si je me sens bien en cours de développement, je ne serais pas si sûr d'utiliser il en production donc si ce n'est pas prêt avant que nous soyons alors il peut retarder notre propre lancement.

Qu'en pensez-vous? Cela vaut-il la peine de prendre le risque? Avez-vous des expériences (bonnes ou mauvaises) de situations similaires?

[EDIT] J'ai délibérément pas spécifié la langue que nous utilisons ou l'outil de développement en question afin de garder la portée de la question large, car je pense que c'est une question qui peut s'appliquer à peu près n'importe quel environnement de dev.

[EDIT2] Merci à Marjan pour la réponse très utile. J'espérais cependant plus de réponses, alors je mets une prime là-dessus.

Answer 1

J'ai déjà eu l'occasion de contribuer à un projet open source, comme vous avez dit que vous espérez contribuer. Ils ont ignoré le patch pendant un an (ils ont bien entendu des clients, bien qu'ils ne vendent pas le logiciel mais le support). Après un an, ils ont rejeté le patch sans solution alternative au problème, et sans une base solide pour le faire. C'était juste hors de leur portée à ce moment-là, je suppose.

Dans votre situation, j'essaierais de résoudre un ou deux de leurs bogues non-prioritaires, déjà signalés, et de voir à quel point ils sont réactifs, puis de décider. Parce que votre succès sur les délais sera compromise à la leur. Si vous devez conserver une copie de leurs artefacts, la douleur est garantie.

En bref: non seulement évaluer le produit, évaluer les producteurs.

Cordialement.

Answer 2

Mon opinion personnelle sur ce point: non. S'ils ne vous parviennent pas dans votre échelle de temps, vous êtes coincé et vous devrez toujours insérer les milliers de lignes vous-même et probablement sous une lourde contrainte de temps. Cela dit, il y a une façon que je vois que vous pourriez essayer et avoir votre gâteau et le manger aussi. Si vous voyez un moyen de l'extraire, c'est d'isoler votre propre code de la bibliothèque, par exemple en utilisant des modèles d'adaptateurs ou de façades, alors allez-y et utilisez l'alpha pour le développement. Mais déterminez auparavant quelle est la date la plus tardive selon votre calendrier de diffusion que vous devriez commencer à développer votre propre version de milliers de lignes derrière l'adaptateur/façade. Si l'alpha ne s'est pas transformé en RC, alors: souriez et supportez-le et développez le vôtre.

Answer 3

Cela dépend.

Pour les environnements opensource, il dépend plus de la qualité de la version que de l'étiquette (alpha/bêta/stable) dont elle dispose. J'ai travaillé avec un code alpha solide par rapport au code de production présumé d'un autre producteur. Si vous avez la source, vous pouvez corriger tous les bogues, alors qu'avec les sources fermées (généralement commercialement supportées), vous ne pouvez jamais publier de code de production construit avec un produit bêta parce qu'il n'est pas supporté par le fournisseur qui a le code. et ainsi vous ne pouvez pas le réparer. Donc, dans votre position, j'évaluerais la qualité de la version alpha et je déciderais si cela pourrait entrer en production.

Bien sûr, tout ce qui précède ne s'applique à rien, même à distance critique de sécurité.

Answer 4

C'est juste une question de gestion des risques. En open source, la version alpha peut signifier beaucoup de choses différentes. Vous devez être prêt à:

• gérer les modifications de l'API;
• fournir des correctifs de bogues et des solutions de contournement;
• tester la stabilité, la performance et l'évolutivité vous-même;
• suivre les changements beaucoup plus près, et décider d'adopter alors encore;
• suivre les progrès réalisés et leur réactivité aux correctifs/problèmes.

Vous utilisez une intégration continue, n'est-ce pas?