Qu'est-ce qu'un "squelette en marche"?

Une de mes équipes agiles a adopté une approche intéressante au début de leur projet. Au lieu de démarrer le projet avec un Sprint 0 où ils ont configuré l’infrastructure de code et décidé de l’architecture de la solution, ils ont commencé à créer un "Squelette ambulant", qu’ils décrivent comme une pratique de DevOps.

Cela semble se résumer à créer quelque chose de très petit (dans le cas d’une API, un seul point de terminaison qui revient tout juste 200-OK), à le faire en intégration continue et à développer le pipeline de distribution continue pour le déployer dans chacun des environnements:

Développement ► Test ► UAT ► Pré-production ► Production

Au cours du processus, ils ont réussi à cocher bon nombre des besoins non fonctionnels qui auraient pu être manqués si les déploiements avaient été laissés à la dernière minute.

Ma question est la suivante: qu'est-ce qu'un "squelette ambulant" et quels avantages procure-t-il à une équipe agile suivant les pratiques de DevOps?

terminology patterns practices

— Richard Slater
source

J'adore celui-ci, je peux partager un

— événement

Un "squelette ambulant" est une forme de "preuve de concept" de votre concept architectural de base. Lorsqu'une preuve de concept se concentre généralement davantage sur une fonctionnalité unique, un "squelette ambulant" est une implémentation minimaliste de bout en bout. Un "squelette ambulant" n'est pas un aperçu de votre concept (seulement un "squelette") mais est vraiment exécutable et expédiable (il peut "marcher": O) et devrait être accompagné d'essais.

Alistair Cockburn l' a décrit (et est souvent cité):

Un squelette ambulant est une petite implémentation du système qui remplit une petite fonction de bout en bout. Il n’est pas nécessaire que l’architecture finale soit utilisée, mais elle devrait relier les principaux composants architecturaux. L'architecture et les fonctionnalités peuvent alors évoluer en parallèle.

L'avantage ici pour DevOps est qu'un "squelette ambulant" doit être développé dès le début du projet et donne lieu à un code fonctionnel, livrable et testable . De cette façon, DevOps peut mettre en place une chaîne d’intégration continue complète au début du projet, au lieu d’être intégré dans la phase finale des projets. Cela signifie que tous les problèmes qui pourraient survenir sont également abordés à un stade précoce au lieu d'un travail urgent à la fin.

— 7ochem
source

Eh bien, il ne s’agit pas seulement de la chaîne CI, mais elle pourrait littéralement couvrir le pipeline de production de bout en bout, y compris la livraison et le déploiement. Un squelette de cela aussi - vous n’avez pas besoin de toutes les vérifications d’AQ pour le produit final en place le jour 1, vous pouvez progressivement ajouter la «viande» de vérification à ce squelette à mesure que l’histoire «viande» s’accumule sur le squelette en marche.

— Dan Cornilescu

J'aime le terme "viande" qui correspond très bien à la terminologie utilisée: P

— 7ochem

Très bonne réponse. J'imagine que c'est l'équivalent dans le pipeline de livraison d'un produit minimum viable.

— Adrian

Cela ressemble au produit minimum viable, mais à un niveau plus granulaire - "composant minimum viable" peut-être. Retourner 200 d'un service juste pour le rendre "en cours d'exécution" me semble être un morceau.

— Dave Swersky