Header Ads Widget

Ticker

6/recent/ticker-posts

¿Cuál es la diferencia entre las API de control de versiones y revisión?

 


La gestión de versiones es una parte importante del ciclo de vida de cualquier desarrollo de API . Dicho esto, también se pasa por alto constantemente, a menudo se considera más como una ocurrencia tardía que como un elemento fundamental de la API y el entorno empresarial. Esto es lamentable, ya que implementar una gestión de versiones adecuada no solo puede evitar que surjan problemas importantes, sino que también puede mejorar la eficacia y el valor de los procesos de gestión de la relación con el cliente.

Hoy veremos dos enfoques para la gestión de versiones. Analizaremos el control de versiones y la revisión , y aislaremos algunas circunstancias específicas en las que cada una es apropiada. Algunas de nuestras definiciones están inspiradas en el trabajo de Darrell Miller , quien ha llegado a definir el concepto de revisión en lo que respecta al control de versiones de API.

Definición de control de versiones

La idea principal detrás del control de versiones es que cada grupo de cambios relacionados con una API se presenta bajo un número específico , que a menudo indica qué tipo de versión es. Por lo general, el primer número denota una versión importante y marca un cambio importante en la base de código que a menudo altera la funcionalidad o tiene un tipo y cantidad de soporte significativamente diferente a otras versiones. La implicación es que lo que funciona en 2.0 puede no tener soporte en 1.0 debido a la diferencia entre el código base.

Los números secundarios, y los números posteriores, normalmente denotan cambios más pequeños y, de hecho, a menudo representan subversiones de la versión principal principal. Por ejemplo, " Versión 1.1 " podría indicar que es una revisión menor de la primera versión del código base. Yendo más allá, la "Versión 1.1.2.3" podría indicar que es el tercer parche de la segunda actualización de la segunda revisión menor de la primera versión principal de la base de código. Puede ver claramente que, si bien el sistema de numeración puede volverse muy complejo, organizar los números de una manera muy clara ayuda a los usuarios a comprender incluso el esquema de nombres más denso de un vistazo.

Una gran ventaja para el control de versiones es que no previene por sí mismo el código que rompe la funcionalidad, solo hace que sea obvio cuando ocurre y permite al usuario predecir y planificar.

Lea también:  Introducción a las mejores prácticas de control de versiones de API

Revisiones

Las revisiones , el control de versiones no deseado, tienen que ver con evitar que el código se rompa de una versión a otra. Una revisión es solo eso: un pequeño cambio en la API a lo largo del tiempo que permite una funcionalidad y un propósito modificados sin romper completamente la API. Cuando se realiza una revisión del código base, esa revisión se considera la fuente de código autorizada actual, y se convierte en el código principal para todas las implementaciones. Cada cambio detrás de eso, sin embargo, sigue siendo válido y se considera "legado".

La principal diferencia entre el control de versiones y la revisión, entonces, es que cada cambio es incremental de principio a fin. Si bien el control de versiones tiene integración de revisión en las fases menores de 1.0 a 1.x, cualquiera que sea la última etapa, la revisión es completamente incremental para evitar que el código y las funciones se rompan.

Relacionado:  Uso de Canary Release para facilitar el control de versiones de API

Por qué esto importa

Todo esto se reduce a una simple dicotomía: las revisiones son cambios incrementales e inquebrantables en una API, mientras que las versiones suelen ser cambios importantes e importantes . Debido a esta dicotomía, cada enfoque tiene un caso de uso muy específico. Cuando una API es lo suficientemente flexible para admitir la versión 1.0 como una opción heredada durante la transición a 2.0, el control de versiones es una buena idea. Los usuarios comprenden exactamente cuáles son las expectativas, qué significa realmente el código base, qué representa cada número y cuáles son las limitaciones del soporte.

Además, cuando una API solo es útil como un conducto a otra API o sistema, en esos casos tiene más sentido tener un único 1.0 que sea compatible, usado y luego desaprobado , lo que forzará una interrupción. En estos casos, la funcionalidad de la API en sí no es el valor, es la integración; por lo tanto, cuando la integración ya no funciona y requiere un cambio importante, obligar al cliente a actualizar es el mejor enfoque.

Por supuesto, no todos pueden admitir ese tipo de flujo de usuarios y, en esos casos, la revisión es mucho más aceptable. Cuando la API debe estar absolutamente en funcionamiento sin ningún cambio en la base de código, como cuando una API admite funciones comerciales vitales, fines médicos , sistemas de seguridad , etc., una interrupción de la función es completamente inaceptable y, más concretamente, la El proceso de diseño de tales funciones críticas nunca debería requerir dicha funcionalidad de ruptura en primer lugar.

Participación y transparencia

Cabe señalar que esta conversación tiene más de una solución fuera de la dicotomía versionar / revisar. Si bien el control de versiones y la revisión son excelentes soluciones para el problema del control de iteraciones, existe el problema subyacente de que los usuarios pueden no querer estos cambios en absoluto.

Esto se debe a una comunicación defectuosa con el usuario desarrollador, pero se puede administrar de manera efectiva mediante la adopción de un método simple de consentimiento. A los usuarios se les puede ofrecer la posibilidad de elegir entre la oferta estable y el cambio "decisivo". Esto se puede hacer en cualquier nivel, en realidad, y es más una elección organizativa que cualquier otra cosa.

En un entorno de control de versiones, esto parece un sistema de sucursales con múltiples soportes. Tener una rama experimental , una rama estable y una rama de actualización continua puede garantizar que los usuarios que opten por no participar en cambios importantes puedan usar ofertas heredadas, mientras que los nuevos usuarios que deseen funciones adicionales pueden optar por esas funciones y el riesgo asociado de funcionalidad rota. Esto también podría significar tener una "API heredada" y una "API actual", con la salvedad de que la API heredada no recibirá actualizaciones y tiene una oferta de soporte técnico limitado.

La revisión ya es, en muchos sentidos, un proceso de suscripción siempre que los usuarios puedan utilizar revisiones anteriores. La clave para ambos procesos es la transparencia: la idea de que el usuario sea consciente de las posibilidades y los riesgos antes de hacer su elección. En consecuencia, la documentación es enorme aquí y debe considerarse el principio de la solución sin importar qué ruta se tome.

Por qué es importante la gestión de versiones

Antes de adentrarnos en las diferencias entre revisión y control de versiones, deberíamos analizar por qué la gestión de versiones, en general, es un elemento importante del diseño de API exitoso. La gestión de versiones como concepto es simplemente la idea de que cada cambio en la API debe ser categorizado, conocido y mostrado al usuario para una mejor comprensión, descubrimiento y usabilidad . En última instancia, la administración de versiones permite a los desarrolladores tener un control completo sobre la versión de cada compilación y, por lo tanto, sirve como herramienta de administración y comunicación.

La administración de versiones brinda a los usuarios una gran cantidad de beneficios, pero quizás aún más importante no es lo que habilita, sino lo que previene: cambios importantes . Cuando se envía un código al usuario que rompe la funcionalidad principal de la aplicación cliente, este tipo de cambio puede provocar que los usuarios se vean completamente desconectados de sus servicios requeridos. Con la gestión de versiones estratégicas, la comunicación de los cambios alineados con las funciones y objetivos a largo plazo de la organización se puede comunicar de manera eficaz a la base de usuarios, evitando así que muchos de estos problemas ocurran.

Por supuesto, esto también significa que la organización también puede beneficiarse de esta única fuente de verdad . Alinear los esfuerzos de la organización (es decir, admitir la versión 2.0 y desaprobar la versión 1.0) junto con la única fuente de verdad e integrar la comunicación del usuario en el proceso puede ayudar a mantener la usabilidad al mismo tiempo que promueve una mejor función . En otras palabras, con esta única fuente de verdad, todos entienden qué iteración se admite actualmente, qué iteración no es, qué hacen esas iteraciones y qué se cambió para hacer que la iteración actual sea lo que es (junto con los datos sobre quién realmente hizo ese cambio ).

El problema con este proceso es que parece que mucha gente piensa que la gestión de iteraciones y versiones se puede configurar y gestionar de forma arbitraria. La realidad es que el sistema solo funciona realmente si está estructurado ; de lo contrario, es solo una forma muy organizada de caos. Con este fin, podemos considerar dos opciones muy poderosas para la gestión de versiones : control de versiones y revisiones .

Consulte: Estrategia de control de versiones continua para API internas

Conclusión

En última instancia, esta es una elección de diseño fundamental que debe tomarse desde el principio cuando un desarrollador de API sabe que los cambios serán algo que se hará. Las revisiones son excelentes ya que evitan cambios rotos en la base de código, pero limitan lo que los desarrolladores pueden hacer en un período de tiempo determinado, ya que cada cambio debe ser incremental. El control de versiones, por otro lado, le permite hacer lo que quiera cuando quiera, pero también aumenta la frustración en la base de usuarios y podría romper los sistemas críticos del cliente si el cambio no se planifica de manera efectiva.

En realidad, esto se reduce a cuál es su relación con el cliente . Si emite cambios directamente a un cliente y no le importa romper la función, entonces el control de versiones es su elección, especialmente si el cliente no está haciendo algo tan crítico que los cambios breves resultarían en fallas catastróficas. Sin embargo, si necesita un toque más suave, obviamente esto no es apropiado, y la revisión es una mejor opción; esto es especialmente cierto si su API tiene problemas regulatorios, impulsa dispositivos médicos, etc.

Publicar un comentario

0 Comentarios