web-applications - para - desarrollo de app en android pdf

¿Qué utilizas para implementar tus aplicaciones web?

Question

Buscamos automatizar nuestra implementación de aplicaciones web, particularmente cuando se trata de desarrollo local a un servidor remoto.

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

No solo estoy hablando de mover archivos, también me refería a considerar otras tareas como:

• Configurando el esquema de la base de datos
• Administrar configuraciones
• Tareas diversas requeridas para la implementación (creación de archivos de registro, etc.)

Answer 1

Cuando y donde sea posible, prefiero una implementación automatizada , como con Ant, incluso la implementación de FTP puede manejarse 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.

Answer 2

Soy un tipo de .NET así que para nosotros es CruiseControl + nant

Sin embargo, he oído grandes cosas sobre Jet Brains TeamCity .

Answer 3

Todavía no lo he probado, pero estoy buscando usar Fabric en el futuro:

Fabric es una herramienta de implementación remota pythonic simple.

Está diseñado para cargar archivos y ejecutar comandos de shell en una cantidad de 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, no espera que estés desplegando aplicaciones de Rails, y el comando ''put'' funciona.

A diferencia de Capistrano, Fabric quiere mantenerse pequeño, ligero, fácil de cambiar y no ligado a ningún marco específico.

Answer 4

Una de las cosas usadas en una compañía anterior era, créanlo o no, los 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 verificaría las versiones en cada servidor y determinaría qué servidores necesitaban actualizaciones. Cada servidor obtendría una copia de cualquier paquete nuevo que necesitara,
3. Cada servidor tendría sus paquetes instalados por el script de implementación, que administraría las tareas y los controles previos y posteriores a la instalación.
4. La secuencia de comandos de implementación desencadenaría un proceso separado, el sistema de gestión de configuración, para leer las plantillas de configuración para generar archivos de configuración para cualquier servicio que un servidor necesitara (según su lista de roles) y distribuirlos en los servidores.
5. El sistema de implementación generaría una lista de las acciones necesarias (servicios a reiniciar) para cada sistema y las presentará 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 los reinicios 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.

Answer 5

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.

Answer 6

rsync-> gran herramienta

Pero, la respuesta depende de tu enviro. ¿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.

Answer 7

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.

Sin configuración adicional, Capistrano:

• Utiliza SSH para conectarse a los servidores de aplicaciones
• Comprueba el último código fuente de Subversion en una carpeta nueva y fechada
• Activa la nueva versión actualizando un enlace simbólico o dos
• Recarga el servidor de aplicaciones

Y todo esto con la funcionalidad de reversión.

Otra buena opción sería usar el sistema de empaque 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.