Respuestas:
Las banderas de características son un dispositivo de ingeniería que se puede utilizar para evitar ramificaciones de larga duración y conflictos en el desarrollo de productos. Así es como se puede usar el contexto de un lenguaje orientado a objetos para ayudar a los desarrolladores a colaborar en una característica específica del producto mientras se maneja una nueva versión. Esta solución también se puede utilizar en contextos no orientados a objetos, siempre que exista una noción de "interfaz". ( véase el sistema de módulos OCaml).
Con fines ilustrativos, asumimos una herramienta que presenta informes sobre los datos almacenados en una base de datos. El código implementa una clase DatabaseClient utilizada para realizar solicitudes. A medida que crece el conjunto de datos, queda claro que algunos diseños de datos alternativos mejorarían el rendimiento de la aplicación. Por lo tanto, Alice desarrollará una nueva versión de DatabaseClient capaz de recuperar datos de las estructuras con un diseño mejorado, mientras que Bob mantendrá el histórico DatabaseClient .
Con los siguientes pasos, Alice y Bob pueden colaborar en ramas de corta duración mientras minimizan sus conflictos.
Alice cambia el nombre de DatabaseClient a DatabaseClient_v1 y crea una clase delegada llamada DatabaseClient que usa un objeto DatabaseClient_v1 e implementa una interfaz llamada DatabaseClientInterface. (Si es posible, este DatabaseClientInterface debería ser un artefacto de código, pero los lenguajes de tipo pato no siempre admiten esto).
Bob revisa los cambios realizados por Alice en 1 y es consciente de que su trabajo de mantenimiento debe realizarse en DatabaseClient_v1 .
Alice introduce un nuevo indicador de configuración en la aplicación que gobierna el comportamiento del delegado de DatabaseClient e implementa un marcador de posición DatabaseClient_v2 , una clase que implementa el DatabaseClientInterface cuyos métodos arrojan una excepción "No implementado".
Después de esto, Alice y Bob pueden colaborar sin sincronización explícita, porque el código escrito en sus respectivas iteraciones está sujeto a la base de datos ClientClientInterface . Esto minimiza el riesgo de un conflicto resultante de su trabajo concurrente.
Las iteraciones de Alice pueden ser muy cortas, como implementar una prueba, implementar un método, o incluso hacerlo parcialmente, porque en producción, el código no se selecciona para su uso y no necesita ser completamente funcional. El testuite automatizado debe configurarse para que DatabaseClientInterface siempre use DatabaseClient_v1 mientras que Alice puede alternar fácilmente a DatabaseClient_v2 cuando ejecuta el testuite localmente, o en una configuración de CI personalizada. Una vez que todo está listo, una sola confirmación puede realizar el cambio, actualizando el valor de configuración que rige al delegado de DatabaseClient .
Los pasos son bastante "fáciles", para pasar a una aplicación de indicador de características necesita básicamente dos cosas:
La característica básica del indicador de función es activarlos / desactivarlos, pero rápidamente deseará lanzar una nueva función de forma progresiva, por ejemplo: 1 servidor en 5 que alojan la aplicación tienen la función "activada" para comenzar, luego activa la función en otro servidor, hasta que todos los servidores la tengan "activada".
Esto significa que debe tener cuidado de que su función sea compatible con la aplicación sin ella (columna adicional en DB, por ejemplo).
Frameworks existe en varios idiomas para evitar reinventar la rueda, el ahora sin mantenimiento de Etsy's tiene un léame interesante para explicar cómo funciona.
El mundo del software incorporado a menudo utiliza indicadores de tiempo de compilación, en el código de la aplicación en sí ( #define/ #ifdefdeclaraciones, por ejemplo) y / o en los archivos de configuración de herramientas de compilación ( makefile's, por ejemplo).
Los indicadores de compilación se pueden usar, de manera similar, no solo para funciones, sino también para todo tipo de refactorización de código, migraciones, soporte de depuración, etc. Permiten comprometerse en la rama de integración cambios parciales o no verificados sin romper la compilación o causar regresiones en las características / proyectos que ya funcionan en la rama. Excelente para manejar arreglos de puntos junto con cambios de progreso grandes / arriesgados / lentos (que de lo contrario requerirían una rama de larga duración) de una manera de integración continua.
Pero además de verificar el código de rama ya existente para las regresiones, también es posible realizar verificaciones de progreso / estabilidad del nuevo código. Para esto, los indicadores de tiempo de compilación deben activarse.
Una forma de alternar las banderas sería usar, en una tubería de verificación separada del sistema de CI de la misma rama (si tiene soporte para dicha funcionalidad), un archivo de parcheo para alternar la bandera, que se aplicará a un espacio de trabajo separado antes del construir. Se construiría un conjunto diferente de artefactos en este espacio de trabajo y luego se verificaría.
Alternativamente, una rama de características de larga duración se puede extraer de la rama de integración principal, pero el único cambio en esta rama de características sería la bandera conmutada. Debido a este pequeño cambio, la rama de características se puede sincronizar automáticamente de forma extremadamente rápida, prácticamente ocultando muy de cerca la rama de integración principal. Una ejecución de CI separada en esta rama ya no necesitaría un archivo de parche preliminar. Sería trivial llevar tal rama de características incluso durante un período prolongado de tiempo.
También puede ser posible crear, en la rama de integración principal, nuevos artefactos de construcción que realmente serían solo clones de los artefactos de construcción existentes pero con las banderas activadas. De esta manera, ni el archivo de parche preliminar ni la rama de características serían necesarios para verificar el nuevo código, directamente en la rama principal.