Cómo implementar: cambios de base de datos, fuente y binarios en 1 parche

Question

Soy parte de un equipo de desarrollo que trabaja en muchos proyectos basados ​​en CMS, usando sistemas como Joomla y Drupal.

En nuestro proceso de desarrollo, todos nuestros cambios de código se gestionan dentro de Git. Al final de un sprint, creamos un DIFF que podemos aplicar a través del parche al sitio en vivo.

El problema es que la mayoría de las veces, los cambios incluyen

• base de datos Cambios en el esquema
• Base de Datos de cambios de datos
• Código Fuente cambia
• cambios en los archivos binarios (como imágenes)

Git Diff maneja el código fuente cambia maravillosamente. Los archivos binarios solo no están incluidos en el Diff, excepto por la referencia al hecho de que los archivos han cambiado.

Cambios en el esquema de la base de datos y los cambios en los datos de la base de datos son un desastre.

Estaba vagando si algo como un sistema de parche unificado existe que podría utilizarse para implementar todos estos cambios en 1 parche.

Así que la pregunta es, "¿Hay un sistema que se puede utilizar para implementar todos estos cambios en 1 tiro?

Idealmente, este sistema permitiría a funcionar en seco-correr como parche, pero para todos los tipos de datos 4

Editar:. Gracias a todos por los comentarios que ha proporcionado, era un punto de partida de mi investigación en esta área

Aquí es lo que he encontrado hasta ahora.:

1. Es difícil de implementar en base aplicaciones php usando envases Linux sistema porque los cambios en el proyecto suceden de forma iterativa en lugar entonces como versiones.

2. Sería posible utilizar dbconfig para implementar cambios en un proyecto , pero el problema es generación de diferenciaciones base de datos MySQL (esquema y datos)

3. lo que realmente no se encuentra para el despliegue de aplicaciones basadas en PHP es un gestor de despliegue que ser instalado en el servidor y habría ser la interfaz para la implementación de los parches

Inicié un Google Wave sobre este tema y produje mucha información como resultado. Si alguien está interesado en leer esta ola, por favor avíseme y lo agregaré.

Answer 1

Para el manejo de la instalación y actualización de nuestra aplicación, utilizamos el debian packaging system. (Paquete .deb)

Contexto: Estamos haciendo aplicación Flex + J2EE. Envío y administración a través de una VPN. Así que no tan lejos de ti.

fresco instalar y actualizar de una versión a otra se realizan a través de marionetas (un sistema para la automatización de las tareas de administración del sistema: que instalar nuestra .deb)

En el .deb tenemos

1. nuestra compilado código fuente
2. el esquema de la base de datos (manejado por [db-config] [1])
3. cosas binaria
4. cómo instalar throught aptos todos los demás ne aplicación eded (MySQL, Tomcat ...)

= Todos los cosas para una nueva instalación

También vamos a añadir la información para pasar de una versión a otra

1. la secuencia de comandos para actualizar la base de datos (para cada versión)
2. nuevo binario
3. cosas nuevas a lauch en el arranque de la máquina (por ejemplo: hace algunas semanas tenemos añadir un servidor activemq)

=> Una vez que el archivo .deb está hecho correctamente, podemos instalarlo o actualizarlo sin problemas en una sola operación. (se hace automáticamente, sin ningún aviso).

Theire es un .deb por versión, cada .deb tiene un número de versión y una firma. Puede elegir cualquiera de nuestros .deb y realizar una nueva instalación o actualización de la versión actual al número de versión que posee.

El .deb se encuentra en nuestro sistema de integración continua. (construimos a.deb cada hora, como si estamos a punto de realease una nueva versión)

---

¿Cuáles son los beneficios?

• Instalar/actualizar de forma automática, con confianza.
• Rollback una versión
• simulacro forma native

---

En el caso preciso

* Database Schema Changes 
* Database Data Changes 
* Source Code changes 
* Binary file changes (like images) 

Database => tendrá que escribir script de migración. Uno para cada versión. (Por ejemplo: 1,2-update.sql 1,3-update.sql)

El código fuente y binario => añadirlos, por ejemplo en la versión de brujas que se tienen que copiar/usar

Edit: No estoy seguro acerca código fuente. Lo estamos haciendo con el código compilado ...

---

Algunos enlaces para empezar:

https://wiki.ubuntu.com/PackagingGuide/Complete

http://www.debian.org/doc/manuals/maint-guide/index.fr.html#contents (en francés)

[1]: http://pwet.fr/man/linux/formats/dbconfig dbconfig

[1]: http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html debian

Answer 2

No creo que encuentre un mecanismo a prueba de fallas.

Recomiendo que, cuando sea posible, tenga en cuenta la compatibilidad con la fuente publicada actual al realizar cambios en el esquema/datos.

De esta forma puede crear una v. Herramienta simple que ejecute scripts de bases de datos comprometidos con una ubicación svn particular (no desea diferencias en los cambios de la base de datos, como si necesitara modificaciones adicionales necesita instrucciones diferentes).

Con lo anterior hecho, puede tener un comando simple que ejecuta los cambios en la base de datos, luego cambia el código fuente & binario.

Para la base de datos también existe la opción de esquema & herramientas de comparación de los datos, éstos se podrían utilizar para comparar los entornos & asegurarse de que no es algo inesperado que faltan en los guiones de cambio - también podría generar los scripts de cambio, pero como yo dijo que realmente quiere asegurarse de que no rompa la fuente de corriente.

Answer 3

Puede crear una herramienta para realizar las migraciones sin problemas, algo similar al Asistente de actualización de parches de Peoplesoft.

Básicamente es un ejecutable independiente que lee una "Plantilla de actualización" y lleva a cabo tareas. La plantilla de actualización describe de manera declarativa las tareas de actualización o "pasos". Los pasos podrían ser: copiar (para hacer copias de seguridad o mover los objetos precompilados como clases y binarios othar), base de datos (para alterar elementos de esquema), secuencias de comandos SQL (para cargar o transformar datos actuales). Los pasos tendrán alguna lógica de predicado con capacidad; si es esto, haga esto, de lo contrario omítalo y vaya a siguiente etc.

La plantilla suele ser un archivo XML. También proporciona pasos manuales con instrucciones para acciones manuales. Cada paso también especifica si es recuperable o no. También validaría si el paso tuvo éxito o no.

Puede ser posible tener un proyecto de código abierto en torno a este requisito, que es bastante común.

Answer 4

Debe guardar los objetos de commit de git en un archivo local y luego importarlos a otro repositorio/sucursal.