¿Qué formas hay para desacoplar la implementación de la versión?

Un método de implementación continua es desacoplar la implementación de la versión, es decir, implementar actualizaciones sin activar los cambios de inmediato.

Sé que se pueden usar las funciones de alternancia para esto, pero me pregunto si existen otras técnicas para las "no funciones".

Por ejemplo, ¿crearía una función de alternancia para una corrección de errores? Probablemente no, y uno podría argumentar que las correcciones de errores deben implementarse lo antes posible, porque solo puede mejorar. Y después de que se haya lanzado una corrección de errores, estoy seguro de que no quiero volver a desactivarla. ¿Pero es éste el caso? Puede ser un cambio arriesgado que desea liberar de forma controlada. Y si no son efectos secundarios inesperados, es bueno ser capaz de rodar de nuevo. Entonces, ¿hay banderas de características para cada cambio?

¿Y qué hay de los cambios visuales? Por ejemplo, ¿puedes implementar algo como una marca de función en CSS? ¿Tiene sentido?

Para el software en la categoría de aplicaciones web, dependiendo de su proveedor de infraestructura / hosting, tal desacoplamiento podría ser posible cambiar el tráfico entrante (o dividirlo) en diferentes versiones implementadas del sw, cubriendo prácticamente cualquiera de los cambios que menciona: correcciones de errores, visuales etc.

Tal soporte normalmente no requeriría alternar características. Y puede ser aplicable independientemente de que la aplicación sea monolítica o esté dividida en microservicios.

Por ejemplo, la oferta de App Engine Paas de Google admite la división y la migración del tráfico.

Desde la división del tráfico :

Puede usar la división del tráfico para especificar un porcentaje de distribución del tráfico en dos o más de las versiones dentro de un servicio. La división del tráfico le permite realizar pruebas A / B entre sus versiones y proporciona control sobre el ritmo al implementar las funciones.

Del tráfico migratorio :

La migración de tráfico cambia el enrutamiento de solicitudes entre las versiones dentro de un servicio de su aplicación, moviendo el tráfico de una o más versiones a una única versión nueva.

Mientras que con los monolitos puede estar restringido a conmutadores, con arquitecturas de microservicio, puede dividir cada grupo de implementación de nodos que proporcionan un servicio (es decir, pods). Luego, activa la implementación del producto recién cambiado en un subconjunto de grupo y lo supervisa cuidadosamente; incluso puede elegir en qué cantidad del grupo desplegar el cambio para, por ejemplo, activar el cambio para el 15% del tráfico. Puede encontrar la característica llamada "actualización continua" en la literatura.