2008-09-24 20 views
6

Estamos buscando automatizar nuestra implementación de aplicaciones web, particularmente cuando se trata de un desarrollo local a un servidor remoto.¿Qué utilizas para implementar tus aplicaciones web?

Nuestra pila actual es LAMP de forma remota, MAMP localmente, pero estoy interesado en general en lo que las personas están usando para esta tarea, independientemente de su entorno.

No estoy hablando sólo de mover archivos de un lado, también me refería a considerar otras tareas tales como:

  • Configuración de esquema de base de
  • configuraciones Administrar
  • Varios tareas necesarias para el despliegue (registro de la creación archivos, etc.)
+0

[Mercurial] (http://www.selenic.com/mercurial/wiki/) –

Respuesta

0

rsync-> gran herramienta

Pero, t la respuesta depende de tu entorno. ¿Qué usas para el control de la fuente? ¿Qué usas para un sistema de compilación? Etc.

La implementación de un servidor web no es más que un comando "cp" según los archivos modificados. Debe crear un proceso que rastree los archivos que cambian, extraiga esos archivos del control de origen y luego los impulsa. Cuando tratas con archivos PHP, ¿cómo sabes qué archivos presionar? Ese es el problema. Si resuelves eso, estarás bien. La herramienta para copiar los archivos y "desplegarlos" es la parte fácil.

2

Usamos "svn export" cuando necesita activarse. Mantiene nuestro código bajo control de revisión, y nos permite desarrollarlo activamente en cuadros de prueba o en nuestra computadora local.

3

Cuando y donde sea posible, Prefiero una implementación automatizada, como con Ant, incluso la implementación FTP se puede manejar con bastante facilidad. Automatizar la implementación, al igual que una versión automatizada, elimina el proceso de adivinar y de error y, por definición, proporciona al menos la documentación mínima necesaria (es decir, el script de compilación) para que un nuevo programador comprenda el proceso.

2

no he probado todavía, pero estoy mirando usando Fabric en el futuro:

Tela es una sencilla herramienta de implantación remota Pythonic.

Está diseñado para cargar archivos y ejecutar comandos de shell en varios servidores en paralelo o en serie. Estos comandos se agrupan en tareas (funciones normales de python) y se especifican en un 'fabfile'.

Es un poco como un Capistrano simplificado, excepto que está en Python, dosn't espera que esté implementando aplicaciones Rails, y el comando 'poner' funciona.

A diferencia de Capistrano, la tela quiere ser pequeña, liviana, fácil de cambiar y no está sujeta a ningún marco específico.

+0

Más detalles sobre la tela: http://stackoverflow.com/questions/1233655/what-is-the-simplest-way- to-ssh-using-python – hughdbrown

3

Una de las cosas usadas en una compañía anterior era - créanlo o no - archivos RPM.Cuando construimos nuestro software, todas las partes se empacarán en archivos RPM, que luego se implementarán en el servidor.

  1. Los servidores maestros en un clúster tenían una lista de todos los servidores y sus roles, que se usarían para determinar qué paquetes necesitaba cada servidor.
  2. La fase de implementación verifica las versiones en cada servidor y determina qué servidores necesitan actualizaciones. Cada servidor obtendría una copia de los paquetes nuevos que necesitara,
  3. Cada servidor tendría sus paquetes instalados por la secuencia de comandos de implementación, que administraría las tareas y las comprobaciones previas y posteriores a la instalación.
  4. La secuencia de comandos de implementación desencadenaría un proceso separado, el sistema de administración de configuración, para leer las plantillas de configuración para generar archivos de configuración para cualquier servicio que necesite un servidor (según su lista de roles) y agrúpelos a los servidores
  5. El sistema de implementación generaría una lista de acciones que debían tomarse (servicios a reiniciar) para cada sistema y presentarlas al operador que administra la actualización. El operador realizaría los reinicios (si la actualización se realizaba durante la ventana de mantenimiento programado del cliente, o si teníamos un pedido de trabajo para el reinicio del servicio de medio día), o crearía un ticket para el personal nocturno con una lista de tareas para estar hecho.

RPM es un hack horrible, pero como nuestros clientes ejecutaban Red Hat Linux (según nuestro requisito), tenía mucho sentido. Si tuviera que elegir, iría con un sistema como Debian o Ubuntu, y establecería un repositorio que los sistemas podrían aprovechar. Aún así, funcionó bien para cientos de clientes, con miles de servidores en total. Con buena pinta.

1

Capistrano funciona muy bien para este tipo de cosas. Salió del ecosistema Ruby on Rails, y al principio estuvo muy vinculado a la implementación de aplicaciones de Rails. Como mucha gente había notado que era útil para el control remoto del servidor, se ha vuelto un poco más general.

Con ninguna configuración adicional, Capistrano:

  • usa SSH para conectarse a los servidores de aplicaciones
  • cabo controles de la última versión del código fuente de Subversion para una nueva fecha, carpeta
  • Activa la nueva versión mediante la actualización de un enlace simbólico o dos
  • vuelve a cargar el servidor de aplicaciones

Y todo ello con r funcionalidad ollback.

Otra buena opción sería utilizar el sistema de embalaje de su sistema operativo (RPM, deb/apt, etc.). Esto tiende a requerir un buen nivel de familiaridad con su sistema operativo y sus políticas, pero encaja perfectamente con otras herramientas si sabe lo que está haciendo.

Cuestiones relacionadas