Nuestros equipos practican el enfoque de desarrollo basado en troncales: el código nuevo se agrega inmediatamente a la rama maestra, las ramas de terceros funcionan durante un máximo de varios días. Y para que las confirmaciones no interfieran entre sí, los desarrolladores usan Feature Flags: interruptores en el código que inician y detienen el trabajo de sus componentes.
Considere una iteración de desarrollo típica: planificación, especificación de requisitos, creación de tareas en el rastreador, desarrollo. Cuando las tareas están listas, se implementan en el entorno de prueba para realizar las pruebas, la rama de lanzamiento se estabiliza. Luego, finalmente llega el lanzamiento y el equipo finalmente puede obtener comentarios reales de los usuarios.
Si está buscando reducir el tiempo de comercialización, es demasiado tiempo. Cuanto antes reciba comentarios de los usuarios, antes corrija los errores, menos tiempo dedicará a las malas ideas y más recursos podrá dedicar a las ideas exitosas.
Para que las actualizaciones lleguen a la venta más rápido, una iteración debe incluir una característica. Por eso es necesario acortar la vida de las ramas.
Problemas de rama de larga duración
Conflictos entre confirmaciones (Fusionar infierno). Retrasar el lanzamiento, la integración con un sistema externo y otros factores externos pueden hacer que el recuento no funcione.
Dificultades para compartir código. Es posible que otros miembros del equipo necesiten código de la nueva rama si las funciones dependen unas de otras. Tenemos que iniciar otra rama solo por acceder a este código.
Pruebe los problemas del entorno. Si solo hay un servidor de prueba y hay muchas ramas de funciones, no funcionará para probar tareas en paralelo.
Es difícil revertir los cambios. Los problemas después de un lanzamiento son comunes, y si una nueva rama de funciones comienza a fallar, los desarrolladores tienen que elegir entre revisión y reversa, ingresar al código fuente y volver a cargar la solución.
Cómo el desarrollo basado en troncales resuelve estos problemas
Trunk Based Development ( . trunk – « ») – . Gitflow, TBD master. feature- , .
Trunk Based Development , trunk. , , , -. .
trunk -. , . trunk , .
, - , ? Feature Flags.
Feature Flags
, IF-, . – , . : , - . – , .
(toggle router), . , , . ( ), (, , , ..).
Feature Flags
- , :
(release toggles): , , . .
(experiment toggles): A/B , . % , .
(permission toggles): . , .
(ops toggles): . , – , .
### Feature Flags
– .
– - , .
– TBD , .
: LaunchDarkly, Bullet-Train, Unleash. - , - . , .
Open source : Moggles, Esquilo. , , . , , .
: , . , . .
Feature Flags Portal (FF-Portal): Web + REST API . .
Feature Flags Storage (FF-Storage): .
Kubernetes ConfigMap (FF-configmap): k8s ConfigMap , , FF-Storage . FF-Portal FF-configmap.
Microservice (MS): , FF-configmap . FF-configmap, .
FF-ConfigMap, Pod- . ConfigMap, k8s , .
Las banderas se cambian a través del portal, que envía un mensaje de integración al bus cuando se actualiza el estado. El componente Config Updater actualiza los valores de las banderas en FF-ConfigMap a través de la API de K8S.
Finalmente sobre las pruebas
Surge la pregunta, ¿cómo probar un producto con indicadores de funciones? A primera vista, las banderas complican este proceso: si hay muchos conmutadores, el número de todos los estados posibles aumenta drásticamente.
Pero las banderas no siempre dependen unas de otras. Por lo tanto, estamos probando dos casos límite para el lanzamiento: 1) todos los indicadores nuevos están apagados y 2) todos los indicadores están activados.
La práctica demuestra que esto suele ser suficiente.