Il y a une troisième voie, comme vous l'avez dit vous-même. Je pense que vous mélangez le développement, les tests et le déploiement. Je propose que l'ensemble du SDLC soit considéré dans son ensemble, d'abord, pour comprendre ce que vous essayez d'atteindre. C'est un gros sujet, mais je ferai de mon mieux pour résumer.
TL; DR;
En bref, vous devez séparer:
- votre code, de
- la configuration de l'application, de
- la configuration de l'environnement système.
Chacun doit être indépendant les uns des autres et convenablement:
- version contrôlée
- testé
- déployable
Version plus longue
Tout d'abord, vous avez une application composée de code et (ensembles séparés de) configuration. Cela doit être testé, à la fois pour la construction et la fonction intentionnelle - c'est ce qu'on appelle l'intégration continue (CI). Il existe de nombreux fournisseurs de ce service en ligne et localement - par exemple CircleCI pour un fournisseur de cloud qui se connecte à votre référentiel et crée et teste chaque fois que vous vous engagez. Si votre référentiel est sur site et ne peut pas utiliser un fournisseur de cloud, quelque chose comme Jenkinsserait un équivalent. Si votre application est assez standard, il existe probablement une image Docker existante que le service CI peut utiliser. Si ce n'est pas le cas, vous devrez en créer un, ou un cluster, pour que votre code d'application et votre configuration puissent être déployés. Correctement configuré, vous disposerez d'une multitude de statistiques sur la qualité de votre code d'application.
Ensuite, une fois que vous êtes satisfait de la fonctionnalité et de l'exactitude de votre application, la base de code doit être correctement étiquetée pour une version spécifique. Cette version doit ensuite être déployée dans un environnement de test. Notez que le code sera le même que celui testé dans votre CI (peut-être, si vous l'avez fait correctement), mais votre configuration peut différer. Encore une fois, certains fournisseurs de CI peuvent proposer cette étape afin que vous puissiez tester votre déploiement d'une application packagée et d'une configuration discrète. Cette étape comprend généralement des tests fonctionnels de l'utilisateur (pour les nouvelles fonctionnalités), ainsi que des tests automatisés (pour les fonctionnalités connues). Si la version réussit cette étape, vous disposez d'une version candidate pour les tests d'intégration. Vous pouvez exécuter les tests d'automatisation à partir d'un autre conteneur Docker,certaines mesures qui indiquent que l'effort de test est de 1: 1 à l'effort de codage (bien que je ne sois pas sûr de cela moi-même).
Avant tout, l'étape suivante consiste à créer votre environnement (système) comme s'il s'agissait de production. Si vous utilisez Docker en production, c'est là que vous penserez au renforcement de la sécurité, à l'optimisation du réseau et du serveur, etc. Vos images Docker peuvent être basées sur celles que vous avez utilisées en développement (idéalement), mais il peut y avoir des changements pour la mise à l'échelle et la sécurité , comme j'ai dit. A présent, les tests fonctionnels de l'application devraient être terminés, vous êtes plus préoccupé par la sécurité et les performances. Selon les tests fonctionnels, vos tests ici peuvent être développés, déployés et exécutés à partir d'autres images Docker. Cette étape était horriblement coûteuse et rarement effectuée pour ce faire, vous aviez donc besoin d'un matériel dédié en place qui reproduise la production. Aujourd'hui, c'est complètement viable car vous pouvez vous lever et détruire tout l'environnement de presque n'importe quelle échelle à la demande.
Enfin, vous avez une version qui devrait être prête pour la production avec seulement un petit ensemble de deltas de configuration de celui de vos tests d'intégration (adresses IP, URI de base de données, mots de passe, etc.) Votre base de code a été testée au moins dans trois environnements différents à ce point et la majorité de la configuration du système au moins une fois.