Je fais partie d'un groupe de développement avec 5 équipes, un total d'environ 40 développeurs. Nous suivons la méthodologie Scrum, avec des sprints de 3 semaines. Nous avons une configuration d'intégration continue (Jenkins), avec un pipeline de construction prenant plusieurs heures (en raison de tests automatisés approfondis). Fondamentalement, le processus de développement fonctionne bien.
Cependant, nous observons qu'après quelques jours dans un nouveau sprint, notre build devient souvent instable et reste instable jusqu'à la fin du sprint "commit stop". L'effet néfaste de cela est que les étapes de construction loin dans le pipeline, en particulier les tests UI / Web ne sont pas exécutés pendant plusieurs jours (car ils ne sont déclenchés que sur une construction «verte»). Par conséquent, les bogues nouvellement introduits ne sont souvent détectés que très tard dans le sprint.
- Chaque validation est vérifiée par rapport à un ensemble de tests de base. Une fois vérifié, le changement est poussé à maîtriser après une revue de code (Gerrit)
- Les tests unitaires de base s'exécutent toutes les 30 min, durée inférieure à 10 min
- Les tests d'intégration s'exécutent toutes les 2h, durée 1h
- UI- / Webtests exécutés sur des tests d'intégration réussis, durée plusieurs heures
Selon qui est responsable de la stabilité de la construction pendant le sprint (cette responsabilité est transmise par sprint), il peut y avoir des "arrêts de validation" intermédiaires et ad hoc pour ramener la construction à stable.
Donc, nous voulons:
- Nos équipes de développement pour développer et valider des changements au cours d'un sprint sans entrave
- Notre processus de construction à abandonner si une étape de construction échoue, car les résultats de construction ultérieurs ont peu de sens
- Notre processus de construction pour fournir aux développeurs des commentaires de qualité en temps opportun
Étant donné (2), les points (1) et (3) semblent se contredire. Quelqu'un a-t-il une bonne pratique pour gérer cela?
( Nous relâchons actuellement le point (2) et autorisons la poursuite de la construction même en cas d'échec de la construction. Je n'ai pas encore de commentaires sur la façon dont cela influence notre qualité )
Merci Simon
several hours
c'est le vrai problème. cela signifie que la solution combinée est trop grande et trop large. Vous devez chercher à composant la solution, puis disposer de petits morceaux de code sous forme de packages (disponibles d'une manière ou d'une autre dans toutes les langues principales sur toutes les plateformes). Ainsi, tout changement irait aux composants uniquement et sera détecté beaucoup plus rapidement. La construction complète consistera essentiellement à assembler des composants déjà combinés et sera également plus rapide. Vous ne pourrez alors éventuellement exécuter que quelques tests pour vous assurer que les bons composants ont été résolus.