ejecutar - servidores web para php
¿Cómo despliega un sitio web en sus servidores web? (7)
En mi empresa tenemos un grupo de 8 desarrolladores web para nuestro sitio web comercial (escrito completamente en PHP, pero eso no debería importar). Todos en el grupo están trabajando en diferentes proyectos al mismo tiempo y cada vez que terminan con su tarea, la implementan inmediatamente (porque el negocio se está moviendo rápidamente en estos días).
Actualmente, el desarrollo ocurre en un servidor compartido con todos los desarrolladores trabajando en la misma base de código (usando RCS para "bloquear" los archivos de otros). Cuando se debe realizar la implementación, los archivos modificados se copian en un servidor "intermedio" y luego un script de sincronización carga los archivos a nuestro servidor web principal desde donde se distribuye a los otros 9 servidores.
Muy felizmente, el equipo de desarrollo web nos pidió ayuda para mejorar el proceso (después de que nos quejamos por un tiempo) y ahora nuestra idea para configurar su entorno de desarrollo es la siguiente:
- Un servidor de desarrollo con directorios virtuales, para que todos tengan su propia base de código
- SVN (o cualquier otro VCS) para realizar un seguimiento de los cambios
- un servidor central para pruebas con el último código registrado
La pregunta ahora es: ¿cómo logramos implementar los archivos modificados en el servidor sin cargar accidentalmente errores de otros proyectos? Mi primera idea fue simplemente exportar la última revisión desde el repositorio, pero eso no daría un control total sobre los archivos.
¿Cómo manejas tal situación? ¿Qué tipo de scripts de implementación tienes en acción?
(Como desafío especial: el sitio web ha crecido orgánicamente en los últimos 10 años, por lo que los proyectos no se dividen en fragmentos pequeños, pero los archivos para una característica específica se extienden por todo el árbol de directorios).
Cassy: obviamente, tienes un largo camino por recorrer antes de que puedas ordenar completamente tu código fuente, ¡pero parece que estás en camino!
Tener sandboxes individuales definitivamente ayudará en las cosas. Luego, asegúrate de que el sitio web SIEMPRE es solo una verificación limpia de una revisión, etiqueta o rama particular de subversión.
Usamos git, pero tenemos una configuración similar. Etiquetamos una versión en particular con un número de versión (en git también podemos agregar una descripción a la etiqueta; ¡es bueno para las notas de la versión!) Y luego tenemos una secuencia de comandos que cualquier persona con acceso a "hacer una publicación" puede ejecutar y requiere dos parámetros: qué sistema se va a actualizar (el centro de datos y si estamos actualizando la prueba o el servidor de producción) y luego el número de versión (la etiqueta).
El script usa sudo para luego ejecutar el script de lanzamiento en una cuenta compartida. Comprueba la versión relevante, minimiza javascript y CSS 1 , envía el código a los servidores correspondientes para el entorno y luego reinicia lo que debe reiniciarse. La última línea del script de lanzamiento se conecta a uno de los servidores web y conecta el registro de errores.
En nuestros sitios web , incluimos un comentario html en la parte inferior de cada página con el nombre del servidor actual y la versión: hace que sea fácil ver "¿Qué se está ejecutando ahora?"
1 y un montón de otras tareas de limpieza como esa ...
Comprobamos la estabilidad con hormiga , todas las noches. Y use el script ant para implementar. Es muy fácil de configurar y usar.
Debería considerar el uso de bifurcaciones y fusiones para proyectos individuales (en la misma base de código), si realizan grandes cambios en la base de código compartida.
usualmente tenemos un entorno de desarrollo local para pruebas (es decir, servidor web localmente) para probar el código no comprometido (no se quiere comprometer ningún código que no funcione), pero ese entorno dev también podría estar en un servidor separado utilizando carpetas compartidas.
sin embargo, el código comprometido debe implementarse en un servidor intermedio para probarlo antes de ponerlo en producción.
Naturalmente, consulte SVN para el repositorio, Trac para realizar un seguimiento de cosas y Apache Ant para implementar.
El proceso básico es administrar en Subversion, rastrear el repositroy y los desarrolladores en Trac y usar los scripts de implementación de Ant para sacar su sitio con la configuración necesaria. Ant le permite implementar fácilmente un proyecto en una ubicación específica. (Dev / prueba / prod) etc.
Probablemente puedas usar Capistrano, aunque es más para ruby, hay algunos artículos que describen cómo usarlo para PHP
Creo que Phing se puede usar con CVS pero no con SVN (al menos eso que leí por última vez)
También hay algunos proyectos que imitan a Capistrano, pero escritos en PHP.
De lo contrario, también hay una solución personalizada:
- los archivos de etiquetas que desea implementar
- Pagar archivos usando la etiqueta en una
directorio específico - enlace simbólico del directorio a la raíz del documento actual (fácil de revertir a la versión anterior)
Tienes que mirar:
- Integración continua
- Ejecutar pruebas unitarias en el check-in del código para verificar que esté libre de errores
- Código de rechazo potencial si contiene un error
- Tener compilaciones nocturnas
- Liberando solo la última compilación sin errores
Es posible que no obtenga una solución perfecta, especialmente al principio, pero cuanto más utilice la solución elegida, más cómodo se sentirá todo el mundo y podrá hacer sugerencias para mejorarla.
Ayer di una respuesta similar a otra pregunta. Básicamente, puedes trabajar en sucursales e integrarlo antes de lanzarlo.
Lo más importante que tendrá que resolver es que se trata de cambios en los archivos, en lugar de archivos individuales. Una vez que tienes sucursales no hay realmente una versión actual, solo hay versiones con diferentes cambios en.