Comment la livraison continue peut-elle fonctionner dans la pratique?

Question

La livraison continue semble bonne, mais mes années d'expérience en développement de logiciels suggèrent que dans la pratique, cela ne peut pas fonctionner.

(Modifier: pour indiquer clairement, j'ai toujours beaucoup de tests en cours d'exécution automatiquement. Ma question est de savoir comment obtenir la confiance pour livrer à chaque chèque, ce que je comprends est la forme complète de CD. L'alternative n'est pas des cycles d'un an . Ce sont des itérations chaque semaine (que certains pourraient considérer encore CD si elles sont faites correctement), deux semaines ou mois; y compris un QA à l'ancienne à la fin de chacun, en complétant les tests automatisés.)

• La couverture complète du test est impossible. Vous devez consacrer beaucoup de temps - et le temps est de l'argent - pour chaque petite chose. Cela est précieux, mais le temps pourrait être passé à contribuer à la qualité d'autres manières.
• Certaines choses sont difficiles à tester automatiquement. EG GUI. Même le sélénium ne vous dira pas si votre GUI est bancale. L'accès à la base de données est difficile à tester sans luminaires encombrants, et même cela ne couvrira pas des cas d'angle étranges dans votre stockage de données. De même la sécurité et bien d'autres choses. Seul le code de la couche commerciale est effectivement test un unitable.
• Même dans la couche commerciale, la plupart des code ne sont pas des fonctions simples dont les arguments et les valeurs de retour peuvent être facilement isolés à des fins de test. Vous pouvez passer beaucoup de temps à construire des objets simulés, ce qui pourrait ne pas correspondre aux implémentations réelles.
• Les tests d'intégration / fonctionnels complétent les tests unitaires, mais ceux-ci prennent beaucoup de temps à s'exécuter car ils impliquent généralement la réinitialisation de l'ensemble du système à chaque test. (Si vous ne réinitialisez pas, l'environnement de test est incohérent.)
• Le refactorisation ou tout autre changement brise de nombreux tests. Vous passez beaucoup de temps à les réparer. S'il s'agit de valider des changements de spécifications significatifs, c'est bien, mais souvent des tests de rupture en raison des détails de mise en œuvre de bas niveau sans signification, pas des choses qui fournissent vraiment des informations importantes. Souvent, les ajustements se concentrent sur le retravailleur des internes du test, et non sur la vérification véritable des fonctionnalités qui sont testées.
• Les rapports sur le terrain sur les bogues ne peuvent pas être facilement adaptés à la micro-version précise du code.