Control de versiones para SAAS Workflow

Lo siento si esto se ha cubierto, pero honestamente puedo decir que he pasado al less 3 días completos tratando de encontrar una solución de control de versiones y mi cabeza está a punto de explotar.

También he repasado el libro de subversión, pero todavía estoy muy confundido.

Básicamente tengo una aplicación SAAS que ha estado creciendo constantemente. Actualmente, en realidad solo hay 1 desarrollador (yo) trabajando en la aplicación, pero si continúa el interés en ello, es posible que tenga que empezar a contratar.

La aplicación está escrita en PHP, utiliza una database MySQL y está alojada en una stack LAMP estándar de pantano.

Actualmente tengo GIT instalado en mi máquina de desarrollo, sin embargo, mi falta de comprensión ha significado que mis compromisos sean irregulares y, a menudo, irrelevantes, y tengo problemas para no hacer un seguimiento de los cambios en los directorys.

Mi principal preocupación es implementarlo en nuestro server de producción. Nuestros clientes tienen sus propias carpetas de aplicaciones y sus propias bases de datos.

Actualmente, cuando ejecutamos una actualización, tenemos que escribir un script de actualización personalizado que:

1.Duplicates clients installation into a backup folder 2.Removes the live installation folder 3.Copies the new updated installation folder 4.Copies the users config files from the backup to the live install 5.Tells the operator to make the changes to the users database using a third party app 6.Cleans up. 

Fue aburrido con 5 usuarios, pero ahora nos acercamos a los 50 y es una pesadilla absoluta.

Para complicar las cosas (y un poco más seguro), cada carpeta de installation contiene una configuration de database única, lo que significa que el esquema de la database solo se puede actualizar desde esa aplicación.

He estado buscando configurar un buen server pero pensé que searchía algunos consejos sobre cómo proceder antes de profundizar más.

Gracias

¿Tal vez podría mantener los files de su aplicación en un directory aparte fuera de los directorys de inicio de los usuarios y crear un enlace simbólico en cada directory de usuarios que apunte a su aplicación? Ejemplo:

 ln -s /var/myapp/publicfiles /home/someuser/lib 

De esta forma, solo necesitaría actualizar el código una vez y luego actualizar el esquema para cada usuario. El directory publicfiles se puede actualizar desde un repository git para que no se necesite copyr files manualmente.

Para el código fuente

Si cada cliente tiene una configuration diferente y files fuente potencialmente ligeramente diferentes, es posible que desee mantener un repository git separado para cada cliente y usar rebase para incorporar los cambios desde el repository principal.

Es decir, tiene un directory, en el server, que contiene el repository principal (un repository de git simple). Empuja los cambios en este repository principal, luego realiza una operación de rebase para cada cliente.

En cada cliente puede verificar files adicionales o cambiar files existentes. La forma en que funciona la rebase es deshacer los cambios locales, extraer todos los cambios del maestro y volver a aplicar los cambios locales. Entonces, esencialmente, los cambios / configuraciones locales anulan el maestro (configuration común).

  • Nota: si puede separar los files por cliente del rest del tree fuente, puede usar el método de enlaces simbólicos de Kaivosukeltaja. Sin embargo, es probable que aún desee la versión de estos files por cliente, a less que la aplicación los administre de alguna manera.

Para la database

Probablemente desee utilizar algún tipo de file de migration similar a Rails (y probablemente a otros). En su tree de códigos fuente, tenga un directory de files de migration (probablemente commands SQL) que realicen los cambios necesarios en la database (es mejor si también tiene los files "migrar hacia adelante" y "migrar hacia atrás").

En principio, puede tener un gancho post-rebase para ejecutar automáticamente un script y aplicar los nuevos scripts de migration para actualizar la database. En la práctica, sería más cuidadoso con los datos del cliente.

Creo que su problema aquí es la cantidad de implementaciones que tiene. Eso es lo que está causando la mayor pesadilla. Sin embargo, todavía es manejable en esta forma. Básicamente, lo que quieres hacer es:

  1. Haz un clon de tu repository de git para cada deployment
  2. Realice modificaciones personalizadas para cada implementación
  3. Para cada actualización de software, revisará cada implementación y fusionará los cambios desde el repository pnetworkingeterminado (principal).

Esto debería combinarse en cambios sin estropear nada dentro de la aplicación. El único cambio es escribir una secuencia de commands que pueda realizar las migraciones o actualizaciones de su database después de que se implemente el nuevo código.