php - with - ¿Cómo implementar correctamente cuando se utiliza el interruptor de desarrollo/producción de Composer?
php composer phar (5)
En realidad, recomendaría EN CONTRA la instalación de dependencias en el servidor de producción.
Mi recomendación es verificar el código en una máquina de implementación, instalar dependencias según sea necesario (esto incluye NO instalar dependencias de desarrollo si el código pasa a producción) y luego mover todos los archivos a la máquina de destino.
¿Por qué?
- en alojamiento compartido, es posible que no pueda acceder a una línea de comando
- incluso si lo hiciera, PHP podría estar restringido allí en términos de comandos, memoria o acceso a la red
- Es probable que las herramientas CLI del repositorio (Git, Svn) no estén instaladas, lo que no funcionaría si su archivo de bloqueo registrara una dependencia para verificar una determinada confirmación en lugar de descargar dicha confirmación como ZIP (usted utilizó --prefer-source, o Composer no hay otra manera de obtener esa versión)
- si su máquina de producción se parece más a un pequeño servidor de prueba (piense en la microinstancia de Amazon EC2) probablemente no haya memoria suficiente instalada para ejecutar la
composer install - mientras el compositor intenta no romper cosas, ¿cómo te sientes al terminar con un sitio web de producción parcialmente roto porque no se pudo cargar alguna dependencia aleatoria durante la fase de instalación de Composer?
Para resumir: use Composer en un entorno que pueda controlar. Su máquina de desarrollo sí califica porque ya tiene todas las cosas necesarias para operar Composer.
¿Cuál es la forma correcta de implementar esto sin instalar las dependencias -dev?
El comando para usar es
composer install --no-dev
Esto funcionará en cualquier entorno, ya sea el servidor de producción en sí, o una máquina de despliegue, o la máquina de desarrollo que se supone que debe hacer una última comprobación para determinar si algún requisito de desarrollo se usa incorrectamente para el software real.
El comando no instalará o desinstalará activamente los requisitos de desarrollo declarados en el archivo composer.lock.
Si no le importa implementar componentes de software de desarrollo en un servidor de producción, ejecutar la composer install hará el mismo trabajo, pero simplemente aumentará la cantidad de bytes que se mueven y también creará una declaración de autocargador más grande.
Composer tiene la opción de cargar varias dependencias solo mientras está en desarrollo, por lo que las herramientas no se instalarán en producción (en el servidor activo). Esto es (en teoría) muy útil para scripts que solo tienen sentido en el desarrollo, como pruebas, herramientas de datos falsos, depuradores, etc.
El camino a seguir es agregar un bloque require-dev adicional con las herramientas que necesita en dev:
"require-dev": {
"codeception/codeception": "1.6.0.3"
}
y luego (teóricamente) cargar estas dependencias a través de
composer install --dev
Problema y pregunta:
Composer ha cambiado radicalmente el comportamiento de la install y la update en 2013, require-dev dependencias require-dev están ahora instaladas por defecto (!), Puede crear un composer.json con un bloque require-dev y realizar una composer install para reproducir.
Como la forma más aceptada de implementar es presionar al compositor. lock (que contiene la configuración actual de tu compositor) y luego realiza una composer install en el servidor de producción, esto también instalará el desarrollo.
¿Cuál es la forma correcta de implementar esto sin instalar las dependencias -dev?
Nota: Estoy tratando de crear una Q / A canónica aquí para aclarar la extraña implementación de Composer. Siéntase libre de editar esta pregunta.
Ahora require-dev está habilitado de forma predeterminada, para el desarrollo local puede hacer la composer install composer update y la composer update sin la opción --dev .
Cuando desee implementar en producción, deberá asegurarse de que composer.lock no tenga ningún paquete que provenga de require-dev .
Puedes hacer esto con
composer update --no-dev
Una vez que haya probado localmente con --no-dev , puede implementar todo en producción e instalarlo en base al composer.lock . Necesita la --no-dev nuevamente aquí; de lo contrario, el compositor dirá "El archivo de bloqueo no contiene información de requerimiento de desarrollo" .
composer install --no-dev
Nota: ¡ Tenga cuidado con cualquier cosa que tenga el potencial de introducir diferencias entre dev y producción! Por lo general, trato de evitar require-dev siempre que sea posible, ya que incluir herramientas de desarrollo no es un gran sobrecarga.
Creo que es mejor automatizar el proceso:
Agregue el archivo composer.lock en su repositorio git, asegúrese de usar composer.phar install --no-dev cuando lo libere, pero en su máquina dev puede usar cualquier comando de compositor sin preocupaciones, esto no irá a producción, el la producción basará sus dependencias en el archivo de bloqueo.
En el servidor, selecciona esta versión o etiqueta específica, y ejecuta todas las pruebas antes de reemplazar la aplicación; si pasan las pruebas, continúe la implementación.
Si la prueba depende de las dependencias dev, ya que el compositor no tiene una dependencia de alcance de prueba, una solución no muy elegante podría ejecutarse con las dependencias dev ( instalación de composer.phar ), eliminar la biblioteca del proveedor, ejecutar composer.phar - instalar --no-dev nuevamente, esto usará dependencias en caché, por lo que es más rápido. Pero eso es un truco si conoces el concepto de ámbitos en otras herramientas de compilación
Automatiza esto y olvida el resto, ve a tomar una cerveza :-)
PD .: Como en el comentario de @Sven a continuación, no es una buena idea no verificar el archivo composer.lock, porque esto hará que la instalación del compositor funcione como la actualización del compositor.
Podrías hacer esa automatización con http://deployer.org/ es una herramienta simple.
En los servidores de producción cambio el nombre de vendor a vendor vendor-<datetime> , y durante la implementación tendrá dos directorios de proveedores.
Una cookie HTTP hace que mi sistema elija el nuevo proveedor autoload.php , y después de probarlo, hago un cambio totalmente atómico / instantáneo entre ellos para deshabilitar el viejo directorio del proveedor para todas las solicitudes futuras, luego borro el directorio anterior unos días después.
Esto evita cualquier problema causado por los cachés del sistema de archivos que estoy usando en apache / php, y también permite que cualquier código PHP activo continúe usando el directorio anterior del proveedor.
A pesar de otras respuestas que recomiendan en contra, personalmente ejecuto la composer install en el servidor, ya que esto es más rápido que rsync desde mi área de preparación (una máquina virtual en mi computadora portátil).
Yo uso --no-dev --no-scripts --optimize-autoloader . Debe leer los documentos de cada uno para verificar si esto es apropiado en su entorno.
Por qué
Hay en mi humilde opinión una buena razón por la cual Composer usará el indicador --dev por defecto (en la instalación y actualización) hoy en día. Composer se ejecuta principalmente en escenarios donde este es el comportamiento deseado:
El flujo de trabajo básico de Composer es el siguiente:
- Se inicia un nuevo proyecto:
composer.phar install --dev, json y lock files están comprometidos con VCS. - Otros desarrolladores comienzan a trabajar en el proyecto: pago de VCS y
composer.phar install --dev. - Un desarrollador agrega dependencias:
composer.phar require <package>, add--devsi desea el paquete en la secciónrequire-dev(y commit). - Otros van de la mano: (checkout y)
composer.phar install --dev. - Un desarrollador desea versiones más nuevas de dependencias:
composer.phar update --dev <package>(y confirmación). - Otros van de la mano: (checkout y)
composer.phar install --dev. - Proyecto implementado:
composer.phar install --no-dev
Como puede ver, el indicador --dev se utiliza (más) que el indicador --no-dev , especialmente cuando aumenta el número de desarrolladores que trabajan en el proyecto.
Despliegue de producción
¿Cuál es la forma correcta de implementar esto sin instalar las dependencias "dev"?
Bueno, el archivo composer.json y composer.lock debe estar comprometido con VCS. No omita composer.lock porque contiene información importante sobre las versiones del paquete que se deben usar.
Al realizar una implementación de producción, puede pasar el indicador --no-dev a Composer:
composer.phar install --no-dev
El archivo composer.lock puede contener información sobre dev-packages. Esto no importa El indicador --no-dev se asegurará de que esos paquetes dev no estén instalados.
Cuando digo "despliegue de producción", me refiero a un despliegue destinado a ser utilizado en producción. No estoy discutiendo si una composer.phar install debe hacer en un servidor de producción, o en un servidor de transición donde las cosas se pueden revisar. Ese no es el alcance de esta respuesta. Simplemente estoy señalando cómo composer.phar install sin instalar dependencias "dev".
Fuera de contexto
El --optimize-autoloader también puede ser deseable en producción (genera un mapa de clase que acelerará la carga automática en su aplicación):
composer.phar install --no-dev --optimize-autoloader
O cuando se realiza la implementación automatizada:
composer.phar install --no-ansi --no-dev --no-interaction --no-progress --no-scripts --optimize-autoloader