Quels aspects de la gestion des versions aident à expliquer la différence entre Waterfall et Agile?

Lorsque vous expliquez DevOps à quelqu'un, il arrive qu'une question se pose comme:

En quoi la gestion des versions utilisant la méthodologie Agile diffère-t-elle de Waterfall?

Alors, quel genre de critères pouvez-vous utiliser pour expliquer ces différences à un tel public?

IMO DevOps est une culture, un peu comme Agile (sans choisir une méthodologie agile.) Par conséquent, vous ne "faites" pas DevOps.

Vous "faites" une méthodologie de publication appelée livraison continue dans le cadre d'une culture DevOps. (divulgation complète, je ne pense pas avoir déjà fait référence au CD comme méthodologie de sortie auparavant, mais dans mon état de décalage horaire, je pense que cela fonctionne)

Si vous achetez cela, alors voici la définition de la livraison continue de l'une des personnes qui ont écrit le livre du même titre, Jez Humble .

La livraison continue est la possibilité d'obtenir des changements de tous types - y compris de nouvelles fonctionnalités, des changements de configuration, des corrections de bogues et des expériences - en production ou entre les mains des utilisateurs, en toute sécurité et rapidement de manière durable.

Notre objectif est de rendre les déploiements, qu'il s'agisse d'un système distribué à grande échelle, d'un environnement de production complexe, d'un système embarqué ou d'une application, des affaires courantes prévisibles pouvant être effectuées à la demande.

Nous réalisons tout cela en nous assurant que notre code est toujours dans un état déployable, même face à des équipes de milliers de développeurs qui apportent des changements au quotidien. Nous éliminons ainsi complètement les phases d'intégration, de test et de durcissement qui suivaient traditionnellement le «dev complete», ainsi que les blocages de code.

Alors, vous pouvez travailler dans une méthodologie Agile, avoir des logiciels que vous pouvez démontrer à l'entreprise, vous assurer que vous faites des tests automatisés appropriés, bien réagir au changement et à tout ce qui le rend meilleur que la cascade. Trop souvent, cela ne signifie pas que vous pouvez réellement le déployer en production.

Vous vous retrouvez avec quelque chose comme ça:

Ainsi, le logiciel sera (probablement) meilleur lorsque vous aurez terminé, si vous n'aviez pas une sorte d'approche itérative, mais vous ne le savez pas vraiment car les vrais utilisateurs ne l'ont jamais vu.

Ce que vous voulez vraiment, c'est quelque chose qui ressemble plus à ceci:

À chaque itération, quelque chose est déployé en production. Ainsi, le logiciel est déployé . Si vous décidez de créer des téléchargements, ouvrez le serveur Web, ou si vous remettez le logiciel entre les mains des utilisateurs, il sera publié .

Que diable!? J'ai posé des questions sur DevOps! Personne n'a posé de questions sur la livraison continue !!

Alors, qu'est-ce que DevOps a à voir avec cela?

Il est très, très difficile (presque impossible) de vraiment avoir votre logiciel dans un état où vous pouvez le déployer quand vous le souhaitez, sauf si cette équipe travaille dans une culture DevOps. Une culture où les administrateurs système, les administrateurs de base de données, les SRE, les responsables de la sécurité, les développeurs, les AQ, etc., etc., font tous partie d'une même équipe et ne font pas partie d'une organisation avec des transferts.

Remarque :

À propos d'une partie d'un commentaire publié sur cette réponse, qui ressemblait à ceci:

A propos de votre "... logiciel dans un état où vous pouvez le déployer quand vous le souhaitez ...": cela me rappelle le logiciel "pilote automatique" (dans un avion) ​​... Ma question préférée à ce sujet: " Imaginez une mise à jour est appliqué à de tels logiciels ... Comment vous sentiriez-vous de le faire en vol ... Pendant que vous êtes à bord? ".

J'adore cette question (en gras, dans la citation ci-dessus)! L'idée de "est-elle vraiment prête?" est quelque chose que je raconte tout le temps - blog . OMI, il est essentiel que vous ayez confiance en la sécurité, les performances et d'autres tests trop souvent «secondaires» afin de pratiquer le CD. Les fonctionnalités sont terminées lorsqu'elles sont terminées, mais les pirates sont toujours là.

Je ne sais pas s'il n'y en a pas d'autres, mais ce sont les critères que j'utilise:

+-------------------+-----------+-----------+
! Criteria          ! Agile     ! Waterfall !
+-------------------+-----------+-----------+
! Release Events    ! Frequent  ! Rare      !
! Risk              ! Less      ! High      !
! Required Effort   ! Smoother  ! Peaks     !
! Volume of changes ! Small     ! Huge      !
+-------------------+-----------+-----------+

Et si vous voulez vraiment faire la différence vous-même en tant qu'utilisateur de certains logiciels, pensez à utiliser des logiciels (comme une distribution Linux), où vous avez le choix entre utiliser l'une de ces versions:

• une version " Rolling" (==> Agile).

• une version " Long Term Support" (==> Waterfall).