Funciones Alterna vs Ramas de Funciones
¿Qué son los "Conmutadores de características" y las "Ramas de características" y cuál es la diferencia entre ellos?
¿Cuáles son los pros y los contras? ¿Por qué uno es mejor que el otro?
Encontré algunos artículos en Google con respecto a esto, y tiendo a estar en el campo de "Funciones Alternas", pero no estoy convencido de que "Funciones Alternas" sea la mejor opción en todos los casos.
3 answers
Los conmutadores de características son una metodología utilizada en una cadena de Integración Continua/Entrega Continua (CI/CD) (metodología de proyecto Ágil/Kanban). Básicamente, envía nuevas funciones a producción en un estado deshabilitado y, a continuación, en una consola de administración, activa la función (o desactiva si descubres que está rota).
Las ramas de características pueden ser parte de una metodología de liberación e integradas en una cadena de integración continua. Puede desarrollar en una rama de características, implementar la rama en DEV / QA, obtener certificación, fusionar la rama de características al tronco, luego empujar el tronco a los entornos SIT/UAT/PROD.
Hay pros y contras asociados con este enfoque. La conmutación de funciones requiere una disciplina muy estricta, ya que el código roto/oscuro está llegando a la producción. Esto es ideal para startups y tiendas donde la administración sabe cómo lograrlo y tiene herramientas de automatización del sistema en su lugar (Chef/Puppet/cfengine, etc.) Google, Facebook, LinkedIn, WordPress todos se implementan en entornos de producción utilizando función de conmutación y automatización del sistema.
Hay algunos requisitos previos "técnicos" para hacer el cambio de funciones correctamente: Entrega/Implementación Continua, Integración Continua, Pruebas Unitarias Automatizadas, Pruebas de Integración Automatizadas, Pruebas de Estrés/Rendimiento Automatizadas, Automatización del Sistema. Si no tiene estos en su lugar, considere una estrategia de lanzamiento más simple (por ejemplo, ramificación de características.)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-09-22 18:30:03
Discuto esto en profundidad en mi blog: http://geekswithblogs.net/Optikal/archive/2013/02/10/152069.aspx
En resumen, las ramas de características le darán un mejor aislamiento, pero le requerirán lidiar con el dolor de la integración diferida y las fusiones. Los conmutadores le brindan una integración continua, pero requieren que diseñe/implemente su código de tal manera que admita los conmutadores e introduzca el riesgo de que el código de características inacabado pueda afectar negativamente a la producción.
Puede utilizar ambas ramas y alterna entre sí (no son mutuamente excluyentes). En cuanto a decidir cuál usar en cada escenario, mis pensamientos son que los conmutadores deberían ser la opción predeterminada a menos que lo siguiente sea cierto:
- es difícil ocultar la funcionalidad detrás de un toggle
- tiene un impacto potencial en un área de la aplicación que no tiene pruebas exhaustivas
Si cualquiera de esas condiciones es verdadera, probablemente usaría una rama feature en lugar de toggle.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-07-15 20:23:00
El cambio de característica requiere una disciplina muy estricta, ya que el código roto/oscuro es llegando a la producción.
Estoy de acuerdo Electrawn, he estado usando ramificación de características a lo largo de 6 años, porque en nuestro caso, no tenemos los requisitos previos.
También es importante entender que la "Estrategia Toogle" transfiere el esfuerzo invertido en la Estrategia de Ramas de Características( Fusión ) a otro momento.
Http://martinfowler.com/bliki/FeatureToggle.html
Es muy importante retirar los conmutadores una vez que las características pendientes se hayan reducido en producción. Esto implica eliminar las definiciones en el archivo de configuración y todo el código que las usa. De lo contrario, obtendrá una pila de interruptores que nadie puede recordar cómo usar. En un ejemplo memorable del que he oído hablar, era necesario hacer una recompilación especial del kernel de linux para manejar suficientes conmutadores de línea de comandos.
Nota: Siguiendo los principios SCM si alguien abre y editar un archivo que podría ser código roto.
Por lo tanto, En mi perspectiva no creo en una "mejor elección en todos los casos", porque depende de la cultura de su equipo y si u tiene la cubierta de la prueba.
Bueno, es una pregunta muy polémica.
Todavía prefiero la Estrategia de Ramas de Características en mi caso. Manteniendo las mejores prácticas de SCM y planificando la hoja de ruta, el proceso de fusión tiende a ser una manera fácil. Durante este año, escuché que mucha gente se queja del proceso de fusión, pero en en muchos casos el problema de la fusión es el mismo en mi experiencia, "La comunicación falla":)
Lo siento por la respuesta imprecisa, pero creo que hay algunos aspectos humanos en torno a este tema de mejor elección en SCM.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-10-17 19:33:07