¿Qué herramientas existen para ayudar a reunir varios elementos de software en una versión de software completa?

Question

Nuestro producto de software está hecho de muchas partes. Digamos que está hecho de una parte del controlador del kernel, un dll de usuario y un software GUI. Durante el desarrollo, los compilamos y los usamos a todos en las últimas versiones, pero no es lo mismo cuando se trata del lanzamiento.

De hecho, la parte del kernel debe congelarse mucho antes que la otra. Entonces, el dll está congelado, para ser ampliamente probado, y congelado por última vez es la GUI. A medida que avanza el control de calidad, debemos crear versiones más nuevas de la versión completa con una GUI fija, pero aún utilizando el controlador kernel incluido previamente y dll.

Me preguntaba si existía alguna herramienta que pudiera administrar ¿qué versión de cada parte de software se usa para crear una versión?

Esta herramienta posiblemente se integrará en la cadena de herramientas, para construir la versión de cada software seleccionado y reunirlos en un instalador de Windows o paquetes de Linux.

Editar: ¿Cómo estamos?

A partir de ahora, estamos utilizando SVN con buildbot como herramienta de CI para Linux/gcc y Windows/VStudio. Estamos en el modo en el que todo el repositorio está ramificado/etiquetado según sea necesario. Pero esto duele y hace que el proceso de liberación sea doloroso ahora que hay cada vez más partes de software relativamente independientes.

Estamos pensando en cambiar el diseño del repositorio para que tenga varios proyectos independientes ramificados/etiquetados. Este sería un ajuste mucho mejor para el desarrollo del software y el ciclo de lanzamiento. Pero entonces, absolutamente necesitaríamos tal herramienta.

El problema está relacionado con tener diferentes piezas de software, cada una con sus propias versiones ramificadas/etiquetadas, reunidas en una versión de software completa.

Editar: Lo que se necesita.

Al final, entendí que lo que necesito es un administrador de paquetes para Windows. Administrador de paquetes en el sentido de administrador de RPM o DEB en Linux.

¿Alguien sabe de un administrador de paquetes en Windows?

Answer 1

Una herramienta con la que he estado jugando es maven, es muy interesante en la forma en que presenta los diferentes ciclos de vida. Puedes usarlo no solo para proyectos Java sino también para .net y hay muchos complementos, así como buenos repositorios (estoy usando el de sonatype).

Answer 2

Creo que el término que está buscando es Software Configuration Management. Aquí también hay un documento bastante valioso: http://www.sei.cmu.edu/reports/87cm004.pdf.

Answer 3

Lo más obvio que tiene es el problema de las dependencias entre esas diferentes partes del software (como Kernel 1.0, Driver A 1.1, etc.). Esto me dará la impresión de que debes pensar en tu herramienta de compilación si es capaz de gestionar dependencias que no suenan así. Así que deberías echarle un vistazo a Maven (ya mencionado), SCons (no estoy seguro) u otras herramientas como Ant en combinación con Ivy. Necesita definir algún tipo de línea de base que describa qué módulos en qué versión funcionan juntos y pueden publicarse. Esta es la metainformación que debe ser manejada por la herramienta de compilación. Puede crear algo por su cuenta ... pero no lo recomiendo.

Answer 4

Tenemos un sistema donde "tronco" es lo que está en producción. Creamos una rama para la próxima versión, cuando un desarrollador realiza sus cambios para un problema, los revisa en nuestro administrador de versiones y asocia esos archivos modificados con ese número de problema o ID de error.

Cuando vamos a la compilación, podemos contener todos los cambios para un problema de compra que no incluye ese problema en nuestra compilación. Cuando colapsamos la rama, podemos ver todos los archivos que fueron cambiados pero no incluidos en la última compilación, los excluimos del colapso.

La otra buena parte de este sistema es que toma todas las secuencias de comandos de SQL y las combina (inteligentemente) en 1 gran archivo de SQL que se utiliza para promover la versión de Prueba, QA y Prod.

Se puede encontrar más HERE.

Answer 5

Para manejar su fuente, que debe de ser de ramificación sus componentes individualmente. Los binarios se manejan a través de package manager. Las mejores prácticas para eso van a variar en función de su sistema operativo objetivo. Mi empresa tiene un software integrado, por lo que lo gestionamos con scripts personalizados que diseñamos. En Linux, quiere hacer paquetes .deb o .rpm. Here's una guía para Ubuntu. No estoy muy familiarizado con Windows, pero InstallShield es una opción popular en el software que he instalado.

Todos deben tener mecanismos para especificar rangos de versiones de dependencias. Puede solicitar una versión exacta, una determinada versión o más reciente, o cualquier otra entre dos versiones. Luego tiene un paquete "principal" que no tiene binarios, pero solo especifica las versiones de los paquetes de componentes. Eso le permitirá actualizar un componente mientras conserva los binarios para los otros componentes. Si desea mantener todo en un solo paquete, hay pocas razones para no reconstruir todo desde el origen. Si sus scripts de compilación están controlados por la versión, sus binarios serán los mismos.

Answer 6

Utilizamos Buckminster para gestionar el nivel de integración de la implementación del software.

Tenemos varios repositorios de código (internos git y svn repositorios, y las referencias a bibliotecas externas y repositorios, como PyDev) y todos ellos tira muy bien juntos, desplegando sólo los componentes que son necesarios para cualquier construcción dada.

Desde su Tech Overview page:

Buckminster es un marco materialización componente de resolución de &. Su propósito es obtener componentes de software para usted y materializarlos en un contexto de elección, generalmente un espacio de trabajo o sistema de archivos. Esto se aplica ya sea que esté mirando lo que está disponible en su máquina local, dentro de su organización de desarrollo o en la nube pública de código abierto. Buckminster elimina la ambigüedad de las descripciones de los componentes, permite el uso compartido de componentes y aumenta la productividad cuando se aplica en escenarios de desarrollo, construcción, ensamblaje e implementación.

Buckminster es un meta-framework extensible, que comprende un lenguaje de metadatos de componentes y un tiempo de ejecución, que puede ejecutarse sin cabeza o como un plug-in dentro del Eclipse IDE. Aunque Buckminster se puede usar para resolver compilaciones comunes, ensamblar & problemas de despliegue, no es un sistema de compilación o administración de componentes per se. Buckminster puede reutilizar las inversiones existentes en una amplia gama de herramientas de compilación y administración de fuentes (Maven, ANT, CVS, SVN, PDE, etc.) y está diseñado para colocar las menos restricciones posibles sobre los servicios que estas herramientas externas pueden proporcionar.

Usando Buckminster puedo implementar, en un solo paso, cualquier versión principal de nuestro software, junto con la configuración específica para cualquiera de mis clientes.

Buckminster también se integra muy bien con nuestros servidores de integración continua Jenkins (nee Hudson).

Por último, Buickminster es lo que es posible para nosotros movemos nuestros repositorios de fuentes primarias de un repositorio svn monolítica a una serie de más de grano fino-git repositorios en una caja fuerte, gestionado manera. En esta versión, movimos un componente principal de nuestro software de svn a su propio repositorio git y, aunque hubo algunos problemas de reintegración, eran manejables.

Al hacer la transición de un subsistema a la vez, reducimos significativamente el riesgo de romper todo el sistema al realizar el movimiento, y tenemos que volver a usar svn o sufrir un sistema de implementación interrumpido hasta que se solucione.