projets internes : vers la version stable ou non ?

Question

Supposons que vous travaillez dans une entreprise de logiciels de taille moyenne à grande, avec de nombreux projets développés indépendamment (codeurs indépendants) mais qui dépendent les uns des autres (code dépendant).

Si cela ne tenait qu'à vous, feriez-vous en sorte que chaque projet produise des branches stables afin que les autres projets puissent utiliser ces branches de manière plus fiable, ou encourageriez-vous les projets à utiliser directement le dernier code disponible des autres projets ?

L'avantage d'une version stable est clair pour moi - une plus grande probabilité que vos dépendances fonctionnent comme prévu. Pourtant, je peux aussi voir des avantages à éviter les versions stables - chaque projet a un peu moins de travail à faire, et vous pouvez réagir très rapidement aux bogues qui affectent tout le monde, puisque votre code est en quelque sorte mis à jour automatiquement en permanence. Par exemple, imaginez qu'il y ait une faille de sécurité subtile à l'instant X dans une bibliothèque interne - elle pourrait ne pas être remarquée avant que ce code ne soit largement utilisé. Si vous utilisez des branches de versions stables, vous devrez demander à tous les autres projets de modifier leurs dépendances pour effectuer la correction de sécurité. Sans branche de publication, la correction est immédiatement prise en compte dans la prochaine version de tous les autres projets.

Je suis particulièrement intéressé si quelqu'un a une expérience industrielle avec les deux alternatives.

Answer 1

Comme toujours, il y a des avantages et des inconvénients pour chacune des options.

L'utilisation de branches peut être plus stable, mais elle nécessite plus de maintenance lorsque vous devez mettre à jour une branche plus récente. Cela demande également à l'équipe de développement de passer du temps supplémentaire lorsque la branche est fusionnée avec le tronc.

D'un autre côté, l'utilisation du tronc peut vous obliger à faire face aux bogues d'autres personnes et à écrire du code de contournement désordonné pour les contourner. Cela peut devenir particulièrement désordonné si vous rencontrez des problèmes bizarres d'OutOfMemory/Performance qui ne peuvent pas être attribués à une bibliothèque spécifique (ou à votre propre code). Rappelez-vous que ce n'est pas votre code, et que vous n'avez probablement pas la main d'œuvre nécessaire pour les aider dans leurs efforts d'assurance qualité...

Je pense donc que le mot de la fin est que cela dépend. Je vous suggère de prendre ces facteurs en considération :

1. L'API que vous utilisez va-t-elle changer ?
2. Est-il important de travailler sur un "code propre" ou peut-on se permettre de s'amuser avec les bugs des autres ?
3. Est-il crucial pour l'application d'utiliser la version "dernier cri" des bibliothèques ?

Par ailleurs, et par expérience, je peux vous dire que l'un de nos programmeurs a manqué quelques nuits de sommeil parce qu'il travaillait avec des branches et que la mise à niveau vers une branche plus récente a modifié toute l'API et la logique :)

HTH

Answer 2

Je pense que tout dépend de l'importance de la mission du logiciel. Si vous pouvez supporter un léger plantage et peut-être une certaine corruption de données et qu'il est facile de pousser de nouvelles constructions, l'exécution d'un code instable peut être préférée. En revanche, si des vies ou des réputations dépendent d'un fonctionnement correct, ou si l'envoi d'une nouvelle version est un processus majeur, les versions stables et testées sont la seule solution.

Answer 3

En regardant d'autres projets, il me semble que le problème que vous soulevez est résolu en ayant des branches de sécurité. Par exemple, les paquets Debian. De cette façon, vous continuez à utiliser la branche stable pour tous les projets. Pour les raisons que vous mentionnez, les branches de test / travail en cours comportent trop de risques.