Hay una tercera forma, como dijiste tú mismo. Creo que está mezclando desarrollo, pruebas e implementación. Propongo que se considere todo el SDLC como un todo, primero, para comprender qué es lo que está tratando de lograr. Este es un gran tema, pero haré todo lo posible para resumir.
TL; DR;
En resumen, debe separar:
- su código, de
- la configuración de la aplicación, desde
- La configuración del entorno del sistema.
Cada uno debe ser independiente el uno del otro y adecuadamente:
- versión controlada
- probado
- desplegable
Versión más larga
Primero, tiene una aplicación compuesta de código y (conjuntos separados de) configuración. Esto debe probarse, tanto para la función de compilación como para la función intencional; esto se denomina integración continua (CI). Hay muchos proveedores de este servicio tanto en línea como localmente, por ejemplo CircleCI para un proveedor de la nube que se vincula a su repositorio y crea y prueba cada vez que se compromete. Si su repositorio es local y no puede usar un proveedor de la nube, algo como JenkinsSería un equivalente. Si su aplicación es bastante estándar, probablemente exista una imagen Docker existente que el servicio de CI pueda usar. De lo contrario, tendrá que crear uno, o un grupo de ellos, en el que pueda implementarse el código y la configuración de su aplicación. Configurado correctamente, tendrá una gran cantidad de estadísticas sobre la calidad del código de su aplicación.
Luego, una vez que esté satisfecho con la funcionalidad y la corrección de su aplicación, la base de código debe etiquetarse adecuadamente para una versión específica. Esta compilación se debe implementar en un entorno de prueba. Tenga en cuenta que el código será el mismo que el probado en su elemento de configuración (probablemente, si lo ha hecho correctamente), pero su configuración puede ser diferente. Una vez más, algunos proveedores de CI pueden ofrecer este paso para que pueda probar su implementación de una aplicación empaquetada y una configuración discreta. Esta etapa generalmente incluirá pruebas funcionales del usuario (para nuevas funcionalidades), así como pruebas automatizadas (para funcionalidades conocidas). Si la versión pasa esta etapa, tiene un candidato de versión para pruebas de integración. Puede ejecutar las pruebas de automatización desde otro contenedor Docker,algunas métricas que indican que el esfuerzo de prueba es 1: 1 al esfuerzo de codificación (aunque yo mismo no estoy seguro de esto).
Penúltimamente, el siguiente paso es donde construye su entorno (del sistema) como si fuera producción. Si está usando Docker en producción, aquí es donde pensará en el fortalecimiento de la seguridad, la optimización de la red y el servidor, etc. Sus imágenes de Docker pueden basarse en las que usó en Desarrollo (idealmente), pero puede haber cambios en la escala y la seguridad , como ya he dicho. En este momento, la prueba funcional de la aplicación debería estar completa, usted está más preocupado por la seguridad y el rendimiento. Según las pruebas funcionales, sus pruebas aquí se pueden desarrollar, implementar y ejecutar desde otras imágenes de Docker. Este paso solía ser terriblemente costoso y rara vez se hacía para hacerlo, por lo que necesitaba un hardware dedicado que reprodujera la producción. Hoy en día, esto es completamente viable, ya que puede ponerse de pie y derribar todo el entorno de casi cualquier escala bajo demanda.
Finalmente, tiene una versión que debe estar lista para producción con solo un pequeño conjunto de deltas de configuración de las pruebas de integración (direcciones IP, URI de bases de datos, contraseñas, etc.) Su base de código se ha probado al menos en tres entornos diferentes en este momento punto y la mayoría de la configuración del sistema al menos una vez.