Développer l'aide d'outils pré-version dev

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 caractéristiques que nous vraiment à utiliser (c.-à-ils nous évitent 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 à ce sujet et j'aime ce que je vois. La question est, faut-il commencer à utiliser réellement pour de vrai? à-dire au-delà de l'évaluation, en utilisant réellement pour notre développement et se fondant sur elle?

alpha logiciel, il est évidemment pas encore prêt à sortir ... mais ni notre propre code. Il est open source, et nous avons les compétences nécessaires pour déboguer, afin que nous puissions en théorie contribuer réellement bug retour des corrections.

Mais d'autre part, nous ne savons pas ce que le calendrier de sortie est (ils n'ont pas publié un encore), et alors que je me sens bien développer avec elle, je ne serais pas si sûr de l'utiliser dans la production, donc s'il est pas prêt avant que nous soyons alors il peut retarder notre lancement.

Que pensez-vous? Est-il utile de prendre le risque? Avez-vous des expériences (bonnes ou mauvaises) de situations similaires?

[EDIT] J'ai volontairement pas précisé la langue que nous utilisons ou l'outil de dev en question afin de maintenir large la portée de la question, je pense qu'il est une question qui peut appliquer à peu près tout environnement de dev.

[EDIT2] Merci à Marjan pour la réponse très utile. J'espérais plus de réponses, donc je mets une prime à ce sujet.

Answer 1

J'ai eu l'expérience de contribuer à un projet open source une fois, comme vous avez dit que vous espérez contribuer. Ils ont ignoré le patch pendant un an (ils ont des clients à assister à des cours, 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. Il était hors de leur portée à ce moment-là, je suppose.

Dans votre situation, je voudrais essayer de résoudre un ou deux de leurs pas si haute priorité, bogues déjà et voir comment ils réagissent, et de décider ensuite. Parce que votre succès sur les délais sera compromise à la leur. Si vous devez conserver une copie de leurs artefacts, qui est la douleur garantie.

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

.

Cordialement.

Answer 2

Mon opinion personnelle à ce sujet: non. Si elles ne viennent pas par vous dans votre échelle de temps, vous êtes coincé et vous aurez encore à mettre dans les milliers de lignes vous-même et probablement sous une restriction de temps lourd.

Cela dit, il y a une façon dont je vois que vous pourriez essayer d'avoir votre gâteau et le manger aussi.

Si vous voyez un moyen de faire abstraction dehors, qui est d'isoler votre propre code de la bibliothèque de, par exemple en utilisant des modèles d'adaptateur ou de façade, puis aller de l'avant et d'utiliser l'alpha pour le développement. Mais déterminer avance ce que la date est en fonction de votre calendrier de sortie que vous devriez commencer à développer vos propres milliers de lignes derrière la version de l'adaptateur / façade. Si l'alpha n'a pas transformé en un RC alors: sourire et supporter et développer votre propre

.

Answer 3

Cela dépend.

Pour les environnements opensource cela dépend plus de la qualité de la sortie de l'étiquette (alpha / bêta / stable) dont il dispose. J'ai travaillé avec alpha code qui est solide par rapport au code de production présumée d'un autre producteur.

Si vous avez la source, vous pouvez corriger les éventuels bugs, alors qu'avec la source fermée, vous pouvez (généralement pris en charge dans le commerce) ne divulguera jamais le code de production construit avec un produit bêta car il est non pris en charge par le vendeur qui a le code, et de sorte que vous ne pouvez pas le fixer.

Donc, dans votre position de je serais d'évaluer la qualité de la version alpha, puis décider si cela pourrait entrer en production.

Bien sûr, tout ce qui précède ne s'applique pas à quoi que ce soit, même à distance de sécurité critiques.

Answer 4

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

• gérer les changements de l'API;
• fournir des correctifs et des solutions de contournement bogue;
• stabilité de test, les performances et l'évolutivité vous;
• change beaucoup plus suivi de près et décider d'adopter puis encore;
• suivre les progrès qu'ils font et leur réactivité face aux patches / problèmes.

vous utilisez l'intégration continue, avez-vous?