¿Cómo mantener el código para que pueda ser utilizado en múltiples software?

Necesito entender las mejores prácticas para usar el mismo código fuente / bibliotecas en múltiples aplicaciones. El requisito es, por ejemplo, que esté vendiendo mi código / biblioteca a alguna empresa, digamos xyx , luego debería usar xyz como nombre de la empresa en mis packages (y en otros lugares, si es necesario).

Más tarde, si alguna otra compañía pqr quiere ese código / biblioteca, necesito ir y cambiar todos los nombres de packages (y otros) manualmente y crear otro repository en el software de control de fuente. Esta tarea consume mucho time y no es nada buena.
Cada vez que encuentro un error en el código base, debo realizar cambios en todas las copys del mismo código y lanzar la biblioteca a todas las empresas.

Estoy tratando de encontrar cómo abordar esta situación.

Estoy aquí hablando de algunos packages de Java (contiene características muy básicas que deseo usar en el software de toda la compañía), y estoy usando el svn de tortuga como repository.

Si está vendiendo el código / biblioteca, eso significa que está entregando una entrega resultante de una operación de empaque.
En otras palabras, no se proporciona el repository en sí, sino un set de files empaquetados (como, por ejemplo, un file, un file comprimido)

Eso significa que las fonts versionadas en su repository no tienen que include el nombre de la compañía. Pueden include un campo de plantilla (como @[email protected] ) y una secuencia de commands, en la salida de ese código, para poner el valor correcto en lugar de ese campo de plantilla.

En git, esto se llama un controller de filter de contenido usando un script declarado en .gitattribute (como aquí ), y almacenando el valor real fuera del git repo (de esa manera, no pueden ser empujados por error)

mancha

(image de " Personalizar los attributes de Git " del Libro de Git )

Con SVN, podrías considerar usar " Substitución de palabras key ".

En ambos casos (Git o SVN), la idea es versionar los files fuente con @ COMPANY @ en él, y generar a pedido los files correctos cuando sea necesario liberar esa biblioteca a un cliente.

No mezcle el desarrollo (que ocurre en su repo de Git o SVN) con la administración de versiones (que puede usar un process diferente, como un file que representa el nombre de la empresa objective, que se utiliza para valorar los files fuente. Si ese file no está presente) , los files fuente permanecen sin cambios al finalizar la compra)

    Intereting Posts