2009-07-27 9 views
8

Estoy trabajando en un nuevo proyecto y estamos utilizando una pila bastante buena. NHibernate, Spring, MVC ... la lista continúa.Técnicas para mantener sus proyectos en la última versión

Una cosa que he notado es que en los 6 meses desde que comenzamos tenemos una nueva versión de NHibernate, una nueva versión de un kit de herramientas de control de terceros y Windows 7 está en el horizonte.

Hemos tenido problemas antes de que nos haya costado quedarnos atrapados en una versión anterior de una tecnología, así que me pregunto cuáles son algunas de las técnicas que podemos usar para asegurar que nuestras transiciones a las últimas versiones tan indolora como sea posible?

Respuesta

8

Acepto los comentarios aquí acerca de la actualización frecuente. Si espera demasiado, será suficiente trabajo que lo notará en la productividad del proyecto.

La forma en que lo hacemos es la siguiente.

  • Una persona en el equipo, recibe la versión más reciente, y se asegura de que todas las pruebas se ejecutan.
  • Esa persona las actualizaciones cualesquiera dll's/tools se actualicen
  • También documenta la actualización.
  • Genere todos los códigos necesarios para que se genere
  • Ejecute todas las pruebas, asegúrese de que se ejecuten.
  • prueba de humo Manual de IU
  • Enviar información al resto del equipo con el documento de actualización
  • in/check-asegúrese de que se basa en la construcción de servidor

De esta manera hacemos no la productividad suelto del equipo durante la actualización Tenga en cuenta que esto sería mucho más difícil sin pruebas unitarias.

10

Simplemente haga que sea una prioridad y actualice según avance. Si se mantiene actualizado con la última versión, habrá menos cambios de interrupción que si tiene que actualizar 5 versiones a la vez.

Quizás crees una rama y realices una prueba de actualización de las versiones para que estés al tanto de los próximos problemas cuando la versión RTM (si usas las versiones beta es una preocupación para ti).

+1

La gestión de cambios a través de sucursales es definitivamente una opción. – lomaxx

4

"actualización temprana, actualizar a menudo"

si se espera que será cada vez más difícil por lo que una gran prioridad a la actualización del sistema. A los desarrolladores les gusta estar a la vanguardia para que no les importe demasiado, el desafío clave es vender esta idea a la gerencia.

Siempre es bueno hacer un enfoque paso a paso en el que se actualizan una por una herramienta. Entonces también es más fácil si necesita retroceder a una versión anterior. El enfoque Big Bang es más difícil y muchas cosas pueden salir mal.

Seamos realistas, cada actualización le costará tiempo y también a su equipo cambiar a la nueva versión de herramientas, pero después de un tiempo el equipo aprende a manejarla y el nivel de estrés al cambiar las versiones es mucho menor.

+0

Esto es bueno en teoría, pero ¿cómo asegurarse de que no está presentando problemas temprano y con frecuencia? – lomaxx

+1

@lomaxx: si no prueba la actualización, se le garantiza que presentará problemas más adelante. La introducción de cambios es simplemente parte de las pruebas y la garantía de calidad. Es fácil y debería ser parte de tu proceso. –

1

Hablando desde un punto de vista de gestión, no actualice a menos que haya un motivo convincente. Tienes que ver qué aporta la actualización a tu proyecto.Si no hay beneficios para la actualización, no lo haga. Obviamente, esta no es una regla difícil y rápida, pero la mayoría de los equipos que conozco no tienen tiempo para pasar los sistemas de actualización sin ninguna razón, están demasiado ocupados con las solicitudes de funciones y las correcciones de errores. Recomiendo trabajar en mejoras sobre la base siguiente:

  1. La nueva versión corre [significativamente] más rápido o más eficiente y sus clientes/clientes verán esto mejora o se reducirá su necesidades de hardware inmanentes.
  2. Se han agregado las características que usted o su clientes/clientes quieren y pueden tomar [inmediata] ventaja de.
  3. Mejora de la seguridad para una falla de seguridad que afecta a su actual o arquitectura futura inmediata.
  4. Motivos de la licencia/soporte. Si usted es al final de su contrato, entonces probablemente tendrá que llegar a la final salto a la última versión del software que tiene derecho a mientras todavía tiene soporte para la actualización . Alternativamente, si está en una versión anterior del software que encontrar la documentación de soporte es difícil, entonces es necesario actualizar .
  5. Algunos aspectos del proyecto en el que está trabajando se ven directamente afectados por el software que podría ser actualizado. Si ya va al para trabajar con él y probar la funcionalidad, probablemente sea un buen momento para actualizar y [probablemente] no agregará una carga significativa al proyecto .
  6. Cambios importantes. Si su proyecto o el software en el que se basa han sufrido cambios importantes, entonces es probablemente un buen momento para agregar las actualizaciones en su plan de proyecto. Los cambios importantes implican una ruta de actualización más difícil y debe ser persude de forma programada más bien que tener que ser en forma de zapato en el último minuto debido a una reparación o mejora necesaria.

razones específicas no actualizar:

  1. software, instalación y pruebas de regresión cuesta dinero. De ahí la necesidad de una razón de peso para actualizar.
  2. El nuevo software a menudo tiene errores o tiene "características" desconocidas. Por esta razón, muchos eligen quedarse con una versión detrás de la última versión.
  3. Las versiones más nuevas a menudo pueden ser más lentas que las versiones anteriores, esto es especialmente cierto para pequeñas actualizaciones y parches.
  4. Problemas de compatibilidad. Las actualizaciones interrumpen las cosas, es mejor omitir tantas actualizaciones incrementales como sea posible para evitar actualizaciones que rompan la compatibilidad, que se puede corregir en la próxima actualización.

Recomiendo mantener una lista de todo el software que utiliza su proyecto junto con su versión y última actualización (junto con otra información importante como información de licencia, información de soporte, etc.). Evalúe cada elemento de esta lista una vez al año para asegurarse de que no se pierda ninguna actualización que coincida con un motivo de actualización que pueda haberse perdido. El software en esta lista con una versión/fecha anterior y una versión más nueva disponible puede ser un incentivo suficiente para convencer a la administración de que se debe realizar una actualización.

Cuestiones relacionadas