Modelo de mantenimiento para artefactos externos

7

Cuando pensamos en mantener una solución de software de manera integral, debemos pensar en cosas como el control de cambios sin código y la administración de la configuración, además del código fuente real. Por ejemplo, para mantener una aplicación web grande, rastrear:

  

"Realice el siguiente cambio de configuración (manual) en la granja de servidores, como parte de la implementación de esta versión específica xx.yy.zz del paquete de solución".

He implementado un modelo bastante bueno para esto, pero ahora estoy abordando el siguiente problema más grande: ¿cómo administramos los cambios en otros sistemas que no tenemos? Tomemos un ejemplo simple:

Tenemos una aplicación ASP.NET propiedad de un equipo de soluciones (llamémosle el Equipo PLM). Su próxima versión incluye un cambio que requiere que el equipo de SAP (que está bajo un paraguas de mantenimiento diferente) también implemente un cambio en uno de sus puntos finales BAPI.

Por supuesto, la coordinación real de la implementación en el momento del lanzamiento es una simple interacción humana & Coordinación, pero en términos del SDLC total:

  • ¿Cómo funciona nuestro paquete de ejemplo "Equipo de PLM" & trazar esta dependencia como un artefacto, como un cambio próximo y, luego de la implementación, una dependencia administrada con los requisitos que posee pero una implementación que no controlan directamente?
  • ¿Cuál es la información correcta para capturar al respecto? ¿Cómo debería tratarse de manera diferente a los elementos de configuración que no son de código que controlan?
pregunta Rex M 24.08.2012 - 21:17

1 respuesta

1
  • Si dos equipos se comunican constantemente, se trata de interacción y coordinación humana, no de procesos de negocios. Simplemente acuerda cómo cambiará la interfaz utilizada por ambos proyectos, implementará el cambio y desplegará ambos productos al mismo tiempo. Al mismo tiempo, me refiero a que desconecta una máquina de una granja de servidores, detiene ambas aplicaciones, luego las actualizaciones se aplican a ambas aplicaciones, y luego comienzan a ejecutarse nuevamente y la máquina puede volver a la granja de servidores.

  • Si dos equipos no se pueden comunicar muy bien (ya sea porque están ubicados geográficamente en diferentes ciudades o porque se odian entre sí, o lo que sea), no hay nada que pueda hacer desde la perspectiva del proceso empresarial para actualizar ambas aplicaciones en al mismo tiempo.

En este segundo caso, estás en el rol de un gran proveedor de API que lanzó una nueva versión de la API, pero tiene muchos clientes que todavía están usando la versión anterior. Si la próxima versión no extiende la primera, pero la cambia, debes seguir ejecutando ambas versiones.

Esto significa que tendrá ambos:

http://api.example.com/products/get/5

y:

http://api.example.com/v2/d6w9UbnZ50/products/get/5
                       ↑       ↑
                    version  token

y mientras que los nuevos clientes podrán beneficiarse de la API RESTfull utilizando la segunda versión, los clientes más antiguos que dependen de las sesiones aún podrán usar la API.

Dado que su proyecto solo es utilizado por otro proyecto, tanto desarrollar como mantener dos versiones del mismo proyecto tienen un costo prohibitivo . Esto significa que una vez que la segunda versión se haya desarrollado y probado, deberías intentar todo lo posible para forzar al otro equipo a comenzar a usar la segunda versión lo antes posible . Esto también significa que si abren un ticket informando que hay un error en su primera versión, este ticket debe cerrarse inmediatamente ya que "no se resolverá" con una nota de que la primera versión ya no se mantiene.

¹ Extender: agregar un argumento opcional a un método existente o agregar una sobrecarga o un nuevo método no rompe la API actual.

² Cambiar: cambiar el nombre de los métodos para hacerlos más explícitos o eliminar un argumento o agregar uno obligatorio romperá la API actual.

    
respondido por el Arseni Mourzenko 25.08.2012 - 13:23

Lea otras preguntas en las etiquetas