des bogues "subtils" se trouvent sur la production qui n'ont pas été identifiés sur l'environnement de mise en scène - dans l'un des projets avec de tels problèmes, j'ai vu que cela a été traité avec succès par une tactique que j'appellerais des doubles problèmes. Je veux dire pour des bugs comme ça, les gars ont créé deux tickets dans Issue Tracker: un a été attribué aux développeurs pour corriger le code, un autre aux testeurs pour concevoir et établir un test de régression ou un changement dans l'environnement de préparation qui empêcherait de le répéter à l'avenir. Cela a aidé à garder la mise en scène suffisamment proche pour produire.
les problèmes sur l'environnement de production nécessitent des retours en arrière - si ceux-ci sont fréquents alors vos versions hebdomadaires sont en fait des faux - envisagez d'ajuster la fréquence au niveau qui fonctionne vraiment. Par faux, je veux dire que si, par exemple, l'une de vos deux versions hebdomadaires est annulée, cela signifie que les utilisateurs doivent faire face à une nouvelle version (fonctionnelle) une fois toutes les deux semaines - c'est tout ce qui compte, pas le nombre de fois que vous déployez.
branches de fonctionnalités appliquées avec enthousiasme - cela signifie-t-il que vous avez également essayé de travailler sur une seule branche avant de la trouver inférieure? Si oui, sautez le reste. Sinon, essayez de travailler sur une seule branche (si nécessaire, google pour la stratégie de branche "branche de développement" ou la stratégie de branche "tronc instable" pour plus de détails). Ou, si vous utilisez Perforce, recherchez sur le Web les directives de Microsoft sur les branchements et les fusions. Essayez -je dit? Désolé, le mot approprié devrait être testé : je veux dire, 1) planifier quand et comment mesurer si une seule branche est meilleure ou non que celle que vous avez maintenant et 2) planifier quand et comment vous reviendrez aux branches de fonctionnalité au cas où cela le test échoue .
PS.
Vous pouvez probablement trouver plus de trucs comme ça en cherchant sur le Web quelque chose comme la gestion des risques des projets logiciels
mise à jour
<copie des commentaires>
Je considère que les correctifs logiciels fréquents sont le symptôme d'un pipeline de test cassé - n'est-ce pas le cas? Quoi qu'il en soit, ils nécessitent des versions répétées pour obtenir les correctifs à chaud, ce qui fait plus de travail pour l'équipe des opérations. De plus, les correctifs sont généralement codés sous une pression temporelle extrême, ce qui signifie qu'ils seront probablement de moins bonne qualité que le travail normal.
</ copie des commentaires>
- correctifs de dernière minute - les préoccupations ci-dessus me semblent raisonnables, ainsi que votre référence à un pipeline de test cassé. Avec cette mise à jour, votre note préalable selon laquelle une nouvelle intégration de code est bloquée lundi ressemble à un symptôme de plus du pipeline cassé (je pense qu'un mot plus précis serait soutenu ). Par contention, je veux dire ce qui suit: vous utilisez une seule branche pour servir simultanément deux objectifs: l'intégration et la publication. Lorsque la libération approche, ces deux objectifs commencent à se heurtant les uns avec les autres, poussant des exigences contradictoires: objectif d'intégration est mieux servi avec en permanence ouverte branche ( fusion précoce et souvent ) alors que les avantages de la stabilité de la libération de branche étant scellés(isolé) aussi longtemps que possible. A-ha, il semble que les pièces du puzzle commencent à être appariées ...
..Regardez, ce lundi-gel ressemble maintenant à un compromis fait pour servir des objectifs contradictoires: les développeurs souffrent d'un bloc d'intégration de nouveau code tandis que les testeurs souffrent de ce bloc étant trop bref, tout le monde est quelque peu mécontent mais les deux objectifs sont plus ou moins servis.
Vous savez, étant donné ci-dessus, je pense que votre meilleur pari serait d'essayer de sortir de la branche dédiée (autre que l'intégration) . Que cette branche soit de longue durée comme l'intégration ou de courte durée comme vos branches de fonctionnalités (avec "fonctionnalité" étant, eh bien, la version) - c'est à vous de décider, elle doit simplement être séparée.
Pensez-y. Actuellement, vous trouvez qu'un jour ne suffit pas pour stabiliser facilement la libération, non? avec la nouvelle stratégie de branchement, vous pouvez simplement bifurquer 2 jours avant la sortie au lieu d'un, pas de problème. Si vous trouvez que même deux jours ne suffisent pas, essayez de bifurquer 3 jours avant, etc. Le fait est que vous pouvez isoler la branche de publication dès que vous le souhaitez, car cela ne bloquera plus la fusion de nouveau code vers la branche d'intégration. Notez que dans ce modèle, il n'est pas nécessaire de geler la branche d'intégration du tout - vos développeurs peuvent l' utiliser en continu , le lundi, mardi, vendredi, peu importe.
Le prix que vous payez pour ce bonheur est une complication des correctifs. Ceux-ci devraient être fusionnés dans deux branches au lieu d'une (version + intégration). C'est ce sur quoi vous devez vous concentrer lorsque vous testez un nouveau modèle. Suivez tout ce qui est lié - efforts supplémentaires que vous consacrez à la fusion avec la deuxième branche, efforts liés au risque que l'on oublie de fusionner avec la deuxième branche - tout ce qui est lié.
À la fin des tests, agrégez simplement ce que vous avez suivi et découvrez si la quantité de cet effort supplémentaire est acceptable ou non. Si c'est acceptable, vous avez terminé. Sinon, revenez à votre modèle actuel, analysez ce qui n'a pas fonctionné et commencez à réfléchir à d'autres façons d'améliorer.
update2
<copie des commentaires>
Mon objectif est d'obtenir des histoires testées et livrables (derrière ou devant un mur de configuration) dans une itération, cela ne peut être réalisé que si les testeurs testent le travail effectué en itération (et non en stabilisant le code de l'itération précédente).
</ copie des commentaires>
Je vois. Eh bien, je n'ai pas d'expérience directe avec cette méthode, mais j'ai vu des tests de type en itération effectués avec succès dans un projet lié au nôtre. Puisque notre projet suivait la voie opposée, j'ai également eu le luxe de comparer en face à face ces approches opposées .
De mon point de vue, l' approche des tests hors itération semblait supérieure dans cette course. Oui, leur projet s'est bien passé et leurs testeurs ont détecté des bogues plus rapidement que le nôtre, mais cela n'a pas aidé. Notre projet s'est également bien passé, et d'une manière ou d'une autre, nous pouvions nous permettre des itérations plus courtes qu'eux, et nous avions moins (beaucoup moins) de versions glissées qu'eux, et il y avait moins de tension entre les développeurs et les testeurs à nos côtés.
BTW malgré une détection plus rapide de leur côté, nous avons réussi à avoir à peu près la même durée de vie moyenne des bogues (la durée de vie est le temps entre l'introduction et la correction , pas entre l'introduction et la détection). Nous avons probablement même eu un léger avantage ici, car avec des itérations plus courtes et des versions moins glissantes, nous pourrions affirmer qu'en moyenne, nos correctifs atteignent les utilisateurs plus rapidement que les leurs.
Pour résumer, je crois toujours que l'isolement de la ligne de code de version a de meilleures chances d'améliorer la productivité de votre équipe.
sur une autre réflexion ...
- l'isolement de la ligne de code de version a de meilleures chances - à la relecture, je pense que cela pourrait donner l'impression que je vous décourage d'essayer les tests d' itération . Je voudrais que ce soit parfaitement clair que non.
Dans votre cas, l'approche de test par itération semble sûre à essayer (euh ... test ) parce que vous semblez avoir une compréhension claire de la façon d'y parvenir ( pipeline de test fluide ) et quels sont les principaux obstacles. Et après tout, vous avez toujours la possibilité de recourir à une approche alternative si vous trouvez trop difficile de faire en sorte que ce pipeline soit correct.
BTW concernant les obstacles, d'autres qui méritent d'être suivis dans ce cas seront des problèmes tels que l' échec de la reproduction du bogue côté développeur et tard pour trouver / tard pour vérifier la correction côté testeurs. Ceux-ci pourraient également bloquer votre pipeline , comme cela se produit maintenant avec les correctifs.