Solíamos ejecutar un sitio web social, en una configuración estándar de LAMP. Teníamos un servidor en vivo, un servidor de prueba y un servidor de desarrollo, así como las máquinas de desarrolladores locales. Todos fueron manejados usando GIT.
En cada máquina, teníamos los archivos PHP, pero también el servicio MySQL, y una carpeta con imágenes que los usuarios subirían. El servidor Live creció hasta tener unos 100K (!) Usuarios recurrentes, el volcado fue de aproximadamente 2GB (!), La carpeta Image fue de unos 50GB (!). Cuando me fui, nuestro servidor estaba llegando al límite de su CPU, Ram y, sobre todo, los límites de conexión de red concurrentes (incluso compilamos nuestra propia versión del controlador de la tarjeta de red para maximizar el servidor 'lol'). No pudimos ( ni debería suponer que con su sitio web ) poner 2GB de datos y 50GB de imágenes en GIT.
Para administrar todo esto bajo GIT fácilmente, ignoraríamos las carpetas binarias (las carpetas que contienen las Imágenes) insertando estas rutas de carpeta en .gitignore. También teníamos una carpeta llamada SQL fuera de la ruta del documentroot de Apache. En esa carpeta SQL, pondríamos nuestros archivos SQL de los desarrolladores en numeraciones incrementales (001.florianm.sql, 001.johns.sql, 002.florianm.sql, etc.). Estos archivos SQL también fueron administrados por GIT. El primer archivo sql de hecho contendría un gran conjunto de esquemas DB. No agregamos datos de usuario en GIT (por ejemplo, los registros de la tabla de usuarios o la tabla de comentarios), pero los datos como configuraciones o topología u otros datos específicos del sitio, se mantuvieron en los archivos sql (y, por lo tanto, GIT). Principalmente son los desarrolladores (que conocen mejor el código) los que determinan qué y qué no mantiene GIT con respecto al esquema y los datos SQL.
Cuando se llegó a un lanzamiento, el administrador inicia sesión en el servidor de desarrollo, fusiona la rama en vivo con todos los desarrolladores y las ramas necesarias en la máquina de desarrollo en una rama de actualización, y la envía al servidor de prueba. En el servidor de prueba, comprueba si el proceso de actualización para el servidor Live sigue siendo válido y, en una rápida sucesión, señala todo el tráfico en Apache a un sitio de marcador de posición, crea un volcado de base de datos, señala el directorio de trabajo de 'live' a 'update ', ejecuta todos los archivos sql nuevos en mysql y reenvía el tráfico al sitio correcto. Cuando todos los interesados estuvieron de acuerdo después de revisar el servidor de prueba, el administrador hizo lo mismo desde el servidor de prueba al servidor en vivo. Luego, fusiona la rama en vivo en el servidor de producción, a la rama maestra en todos los servidores, y vuelve a crear una base en todas las ramas en vivo.
Si hubo problemas en el servidor de prueba, por ejemplo. las fusiones tuvieron demasiados conflictos, luego el código fue revertido (señalando la rama de trabajo nuevamente a "en vivo") y los archivos sql nunca se ejecutaron. En el momento en que se ejecutaron los archivos sql, esto se consideró como una acción no reversible en ese momento. Si los archivos SQL no funcionaban correctamente, la base de datos se restauraba utilizando el volcado (y los desarrolladores dijeron que no, para proporcionar archivos SQL mal probados).
Hoy, mantenemos una carpeta sql-up y sql-down, con nombres de archivo equivalentes, donde los desarrolladores tienen que probar que tanto los archivos sql de actualización pueden ser degradados igualmente. En última instancia, esto podría ejecutarse con un script bash, pero es una buena idea si los ojos humanos siguen monitoreando el proceso de actualización.
No es genial, pero es manejable. Espero que esto dé una idea de un sitio de la vida real, práctico y de alta disponibilidad. Ya sea un poco anticuado, pero aún así siguió.