¿Cómo manejas el control de versiones en un proyecto de varios lados?

Sé que es una pregunta amplia, así que intentaré ser lo más específico posible. Esta pregunta es más una pregunta "organizativa" que técnica.

Tenemos un proyecto de varios lados con estos componentes principales:

• Un servidor que aloja la lógica empresarial central (modelos de datos)
• Un backoffice para clientes que utiliza la lógica comercial central
• Una API de aplicación (REST) ​​que también utiliza la lógica empresarial central
• Existen aplicaciones para teléfonos inteligentes (iOS y Android) que utilizan la aplicación API
• Hay otra aplicación de tableta (android) diferente de la del teléfono inteligente que usa la misma aplicación API.

Pronto estaré en producción con clientes activos. Y como cualquier proyecto, necesitaré mantener todos los componentes diferentes a lo largo del tiempo. Eso significa que se puede actualizar todo lo siguiente:

• El código de la lógica empresarial central en el servidor (utilizado por el back-office, la API y, como efecto secundario, por las aplicaciones móviles)
• la API en sí (utilizada por aplicaciones de teléfonos inteligentes y tabletas)
• todas las aplicaciones móviles (a través de appstore / googleplay)

Por supuesto, yo mismo puedo cambiar las partes del lado del servidor (código de lógica de negocio central y código API). Sin embargo, los clientes deben descargar nuevas aplicaciones móviles en la tienda de aplicaciones / googleplay, y no puedo estar seguro de que estén actualizadas.

¿Podría proporcionar alguna orientación, consejos de buenas prácticas, para que estas actualizaciones sean fluidas y sin riesgos para el cliente?

¿Qué componente necesito para "versión"? ¿Cómo garantizar que todo funcione incluso si el cliente no actualiza su aplicación móvil? ¿Debo obligarlo a actualizar para facilitar mi trabajo?

En una palabra, ¿cómo debo organizarme para hacer que mi proyecto multifacético se viva con el tiempo?

Como no puede controlar cuándo se actualizarán las aplicaciones móviles a una nueva versión, debe versionar al menos su API REST. Si no lo hace, será imposible realizar cambios retrocompatibles en esa interfaz.

Además de la API REST, es una buena idea versionar también las otras interfaces de comunicación que pasan por una interfaz de red. De esa manera, tampoco está obligado a actualizar todos los clientes de backoffice al mismo tiempo que los servidores y puede implementar una migración gradual a una nueva versión con un período de "prueba beta".

Además de versionar las interfaces de comunicación, también debe intentar hacer que los cambios sean compatibles con versiones anteriores tanto como sea posible. Idealmente, podría implementar una nueva versión de interfaz que todavía sea totalmente compatible con los clientes antiguos para que no noten que nada ha cambiado.

Esta publicación hace un punto interesante sobre su pregunta.

De una manera más práctica, si tiene 3 componentes:

• 2 consumidores: un front-end y una aplicación móvil
• 1 proveedor de API: un back-end

Puede usar el esquema de versiones típico de Mmp (Major.minor.patch) para cada uno, pero en su URL de back-end puede poner algo como http://youhost/M.m/resourceURI.

A medida que evolucione y los cambios en la API no afecten su contrato con los consumidores, mantenga el estado M.mtal como está en la URL. Desde el momento en que realiza un cambio en el BackEnd que afecta a sus consumidores (ya sea un cambio en el comportamiento o un objeto diferente), utiliza un M.m+1, M+1.m+1o M+1.m.

La forma de mantener las cosas en funcionamiento es implementar el nuevo Back-End simultáneamente con el anterior, mientras los usuarios instalan los nuevos consumidores y descontinúan lentamente la API anterior.

Puede ver una respuesta mucho mejor que la mía aquí: Versioning REST API en Stackoverflow

Le recomiendo que instale un servidor de integración continua, lo conecte a su repositorio de código y un repositorio de instantáneas / lanzamiento y automatice sus compilaciones. Esto tendrá una serie de ventajas:

1. Cada componente se versionará cuando se lance. Esto incluye bibliotecas de bajo nivel, así como sus productos finales.
2. Cada confirmación de código activará una compilación de instantánea. Esto ayuda a mantener honestos a sus desarrolladores, especialmente si utiliza la instalación para enviar un correo electrónico al culpable que rompió la compilación.
3. Cada compilación puede ejecutar pruebas unitarias. Esto mejora notablemente la calidad del código.
4. Cada lanzamiento será etiquetado, por lo que si se requiere un arreglo de producción, es fácil ramificar desde la etiqueta y hacer el arreglo.
5. Deberá mantener un registro de compatibilidad de algún tipo. (por ejemplo, BackOffice 1.0.23 es compatible con REST API 2.0.267, etc.). No conozco una herramienta que ayude en esta área.

Mi experiencia ha sido con herramientas de código abierto: SVN, Maven 2, Jenkins y Nexus, pero hay alternativas a todos estos.

No subestimes el tiempo de aprendizaje para poner a tu equipo al día. Pero una vez que estén al día, nunca volverán.

Para un equipo relativamente pequeño para el desarrollo y la implementación, el modelo de compatibilidad del Cliente N-1 empleado por IBM Jazz puede funcionar bastante bien

Intente mantener a los clientes y servidores en el mismo número de versión. [En lugar de gestionar una matriz de versiones independientes y sus compatibilidades]

Establezca una política de que la versión de cliente Xyy debería funcionar con todas las versiones de servidores superiores a Xyy pero inferiores a X + 2.0.0

Para un servidor versión 4.0, idealmente debería haber una versión de cliente 4.0 para cada tipo de cliente. Sin embargo, la compatibilidad debe mantenerse para permitir versiones ligeramente diferentes de clientes y servidores.

Una versión de cliente 4.x debe ser compatible con servidores versión 4.xy superior pero inferior a 6.0; Un servidor 4.x debe ser compatible con todos los clientes versión 3.0 y superior, pero menor o igual que 4.x

De esta manera, puede actualizar una versión en el servidor sin preocuparse por el lanzamiento inmediato de nuevas versiones de los clientes, pero solo tendrá una ventana de compatibilidad bien definida para mantener.

Ref: IBM Jazz Model [ https://www.ibm.com/support/knowledgecenter/en/SSYMRC_6.0.0/com.ibm.jazz.install.doc/topics/c_n-1.html]

Primero, comencemos por enmarcar el problema un poco diferente. Ha preguntado qué software necesita para "versionar". Versión es un término sobrecargado en CS, y podría significar unas 100 cosas diferentes. Lo principal que miraría es:

1. Control de versiones: el control de versiones es una herramienta de administración de configuración que lo ayuda a realizar un seguimiento de las instantáneas y el historial de su desarrollo. TODO EL CÓDIGO DEBE ESTAR BAJO CONTROL DE VERSIÓN. No me importa si solo se trata de los scripts de conveniencia que agrega a su carpeta bin, cualquier cosa que valga la pena pasar tiempo escribiendo vale los dos segundos para agregar a un software de control de revisión.
2. Gestión de la configuración: cómo controlo lo que hay en la compilación. Todo el software debe tener cierto grado de gestión de la configuración. Me gusta describir a los gerentes la diferencia entre el control de versiones y la administración de la configuración, ya que el control de versiones es solo una herramienta para rastrear el historial de desarrollo, mientras que la administración de la configuración son las pautas sobre cómo creamos el historial y cómo hacemos cosas como decidir el código es bueno.
3. Versiones de software: asignación de nombres a versiones de código. Esto es a lo que muchas personas se aferran cuando ven el problema por primera vez porque están acostumbrados a ver "MineSweeper 7.1.29290149210" o lo que sea que compren, pero honestamente encuentro que esta es la parte más pequeña de un problema mucho más grande. Para ser honesto, simplemente usando el hash generado por 1 y no me importa tanto que no sea legible para humanos, está perfectamente bien hacerlo.

Entonces, como es lo más nebuloso y lo más interesante para mí, me voy a centrar en el n. ° 2. No hay una solución única para cortar la galleta para la gestión de la configuración. Las reglas que funcionan bien para un equipo de 2 o 3 pueden ser demasiado flexibles para mantener la cordura en un proyecto que requiere cientos de trabajadores. Las reglas que funcionan para el equipo grande pueden requerir demasiados gastos generales para el equipo pequeño. Lo más probable es que tenga que improvisar algo propio para reunir algo, pero usaría la siguiente lista como una forma de desarrollar las especificaciones para su sistema de administración de configuración:

1. ¿Cómo puedo hacer un seguimiento de las versiones (y los problemas asociados con ellas) que estoy soportando en el mercado?
2. ¿Cómo decidiré qué rutas de desarrollo están listas para su lanzamiento a los sistemas de producción? (También podría estar listo para cualquier otro paso en un proceso)
3. ¿Quién debería tener el control / gestionar la configuración del sistema? ¿Cuál es el flujo de trabajo para agregar código que se distribuirá a otros desarrolladores?
4. ¿Cómo voy a controlar la interacción entre las partes que interactúan? ¿Cómo sabré si cambiar una parte romperá el resto del sistema?
5. ¿Cómo mejoraremos nuestro sistema de gestión de configuración con el tiempo?

¿Necesita ayuda para responder las preguntas anteriores? Probablemente debería contratar a un consultor o gerente de ingeniería de software ... respondiendo que puede llenar los libros de texto y está fuera del alcance de este tipo de foro.