| | 518 | ==== Resolución de conflictos ==== |
| | 519 | |
| | 520 | Imaginemos que tenemos un paquete A que es usado por otros dos: B y C los cuales se crearon respectivamente con las versiones A.n.1 y A.n.2, lo cual indica simplemente que cada uno funciona con su versión de A correspondiente, o mejor dicho, que ha pasado cierto número de tests de control porque a más no se puede llegar. Nada impide que cada uno de ellos pueda o no funcionar con versiones anteriores o posteriores. |
| | 521 | |
| | 522 | Esos números de versión quedan recogidos en la base de datos y son consultables vía WEB. Sería posible obligar al #Require a cargar las versiones específicas con las que se ha creado cada uno pero entonces los paquetes B y C serán incompatibles por definición, es decir, no se podrían usar conjuntamente en la misma sesión, cuando en realidad pueden ocurrir varias cosas: |
| | 523 | |
| | 524 | 1. Si B funciona con la A.n.2 y C funciona con la A.n.1 daría igual que cargaras una u otra con lo que lo mejor es usar la más moderna. |
| | 525 | 2. Si B funciona con la A.n.2 pero C no funciona con la A.n.1 entoces hay que usar la más moderna. |
| | 526 | 3. Si B no fuciona con la A.n.2 pero C sí funciona con la A.n.1 entonces ha aparecido un conflicto y habría que forzar el uso de la vieja anteponiendo en el código del usuario un #Require A.n.1 a los #Require B y #Require C, pero sólo como solución temporal mientras se hacen los cambios que toquen en A, en B o en ambos de forma que B funcione con la A.n.2 |
| | 527 | |
| | 528 | |
| | 529 | Para reducir las probabilidades de que aparezcan conflictos y paliar sus consecuencias cuando ocurran, la política de desarrollo debería cumpir estas normas: |
| | 530 | |
| | 531 | 1. Los paquetes nunca han de requerir versiones concretas de un paquete ni tampoco tiene sentido que intenten cargar una versión concreta sino siempre la más avanzada que haya. |
| | 532 | 2. Cada test debe acompañarse de una batería de tests automáticos que usen sólo #Require sin especificar versiones. |
| | 533 | 3. Aplicar de forma muy cuidadosa los parches, es decir, los cambios en un paquete que no suponen cambios de versión. hay que estar muy seguro de que ningún paquete dependiente pueda verse afectado, pues no habrá forma de arreglarlo después si hay conflictos. Básicamente hay que reservarlos a temas de documentación y errores muy claros y localizados. |
| | 534 | 4. Cada vez que se quiera cambiar la versión de un paquete hay que pasar los tests del mismo en local y los de todos los paquetes que dependan de él. |
| | 535 | 5. Si falla algún test de un paquete dependiente hay que depurar los paquetes afectados para resolver el conflicto antes de que llegue al usuario. |
| | 536 | 6. Si pese a todos los cuidados ocurre un fallo entonces se reporta un ticket y, de manera excepcional y sólo mientras se arregla el problema, se colocan en el código del cliente tantos #Require de versiones específicas como sean necesarias para que puedan regresar a un estado de compatibilidad. |
| | 537 | |
| | 538 | En cuanto a los usuarios en proyectos con procesos críticos de producción es evidente que no pueden andar corriendo riesgos por lo que simplemente no deben actualizar ningún paquete en las máquinas de producción mientras no hayan comprobado que las nuevas versiones funcionan correctamente en su máquinas de desarrollo. Si queremos que se puedan usar las nuevas herramientas sin frenar el desarrollo ni arriesgar la seguridad de los clientes no se me ocurre ninguna otra forma. La automatización de |
| | 539 | |
