¿Cómo administra las versiones frecuentes de software a varios clientes? [cerrado]

7

tenemos un producto de middleware multiplataforma que normalmente terminamos personalizando / corrigiendo errores por cliente. En algunos casos, proporcionar actualizaciones una vez / dos veces por semana.

Tenemos muchos problemas para administrar y liberar las actualizaciones a nuestros clientes de manera eficiente.

He investigado un poco, pero no puedo encontrar nada que aborde específicamente este problema.

¿Alguien puede compartir sus experiencias? ¿Cómo maneja este escenario, o sabe de un buen software de entrega de software?

    
pregunta meeech 13.03.2011 - 15:27

3 respuestas

5

Esto es lo que hacemos:

  • Tenemos iteración fija en la que creamos todas las funciones planeadas.
  • Cada vez que se completa una función activamos el script de compilación automatizada y lo hacemos inmediatamente disponible en un área especial llamada "BETA". Es completamente automático, incluida la actualización de la página web & subir. Se llama BETA porque es un término bien entendido por nuestros usuarios. Pero son puramente construcciones de desarrollo. Listo para ser consumido por ellos. El hecho de que es una página BETA, el usuario acepta imperfecciones y el hecho de que se convierten en probadores implícitos de esa construcción.
  • Al final de una iteración, decidimos realizar una publicación oficial (boletín, cambio de sitio web, etc.) o demorar la siguiente iteración.
  • Durante el proceso, recibimos comentarios de nuestros clientes continuamente . En ocasiones, abordamos una función inmediatamente . Lo pusimos a disposición muy rápidamente a través de esas compilaciones de desarrolladores.
  • Si nos enfrentamos a un error molesto, lo arreglamos en el tronco y lo fusionamos con la rama que hicimos cuando lanzamos la versión anterior. Y actualice el archivo en el área de descarga oficial en silencio y notifique a los usuarios afectados por el problema.

Al hacerlo, danos las siguientes ventajas:

  • controlamos nuestro proceso de lanzamiento. Nuestro cliente lo siente y luego confía en nosotros más.
  • Algunos clientes están más dispuestos a proporcionar comentarios valiosos , ya que consideran que es importante para nosotros. Muchas innovaciones vienen de ese canal.
  • Nuestros clientes saben que estamos continuamente construyendo sobre lo que pagaron, y por lo tanto tenemos el (real) sentimiento de que vale la pena el dinero que invirtieron en él.

Eso es solo una descripción general del proceso, pero estoy seguro de que entiendes el punto.

    
respondido por el user2567 13.03.2011 - 15:54
3

Hay un gran libro llamado Entrega continua que podría ayudarlo. Además, es posible que desee ver un proceso llamado Líneas de productos de software que aborda los enfoques para mantener un grupo de personas estrechamente relacionadas. sucursales de software. Usamos esa técnica cuando estaba en Convergys (que maneja la facturación para la mayoría de los proveedores de servicios inalámbricos y de Internet en Estados Unidos usando un solo producto personalizado para cada uno de los proveedores).

    
respondido por el Michael Brown 13.03.2011 - 17:26
2

En su mayor parte, uso ramas. En varias raras ocasiones, cloné una copia del repositorio específica para el cliente completamente nueva. El punto principal es que usted quiere que todo se mantenga "relacionado" para que la fusión y quizás incluso la recolección de cerezas no tenga que chupar proverbialmente.

Sigo la misma regla que sigo al hacer un fork de cualquier otro proyecto de código abierto. Si necesito que el proyecto vaya en una dirección que la mayoría de las personas involucradas consideraría demasiado localizada y específica para mis propias necesidades, lo haré. Si las necesidades del cliente se desvían lo suficiente del esfuerzo principal, bifurque otro repositorio.

De lo contrario, no es nada raro mantener sucursales para varias arquitecturas, por lo que las sucursales para clientes particulares que no requieren que se desvíe demasiado del enfoque principal de desarrollo servirán básicamente para lo mismo.

De nuevo, no hay nada de malo en clonar un nuevo repositorio por cliente. El punto es, mantenerlos todos relacionados para que su sistema de control de versiones lo ayude a administrar fusiones, bisecciones, etiquetas y todas las otras cosas encantadoras para las que contamos para hacerlas.

    
respondido por el Tim Post 13.03.2011 - 15:35

Lea otras preguntas en las etiquetas