1) Configuración separada del resto del código. El resto del código debería poder ejecutarse en las 3 ubicaciones sin modificaciones.Un archivo de configuración típica podría ser:
<?
$db = "main_db"; $db_user="web1"; $db_pass = "xyz123";
$site ="example.com";
$htroot = "/var/www/prod/htdocs"
?>
Y para el entorno de prueba:
<?
$db = "test_db"; $db_user="web1"; $db_pass = "xyz123";
$site ="test.example.com";
$htroot = "/var/www/test/htdocs"
?>
No incluya los archivos de configuración con las contraseñas en la base de código. La base de código puede copiarse a través de conexiones inseguras o almacenarse en servidores de hospedaje de código de terceros más adelante (ver a continuación). Y es posible que no quiera sus contraseñas en todos sus discos de copia de seguridad del código.
También puede crear un archivo de configuración única y utilizar un interruptor en función del entorno se ejecuta el código:
<?
$site = $_SERVER["HTTP_HOST"];
if ($site == "example.com";) {
$db = "main_db"; $db_user="web1"; $db_pass = "xyz123";
$htroot = "/var/www/prod/htdocs";
}
if ($site == "test.example.com") {
$db = "test_db"; $db_user="web1"; $db_pass = "xyz123";
$htroot = "/var/www/test/htdocs";
}
?>
Pero ahora usted podría tener la tentación de ponerlo de nuevo en la base de código, que es menos seguro como se explicó anteriormente. Y si no lo colocas allí, tienes que actualizar 3 archivos, o usar una ubicación fija por servidor, y debes asegurarte de que el código encuentre el archivo en cada servidor. Yo personalmente prefiero la solución de un archivo por sitio desde arriba.
2) Ya tiene "versiones". Hay una versión corriendo en prod ahora. Dale un nombre y número únicos, que nunca volverán a cambiar. Puede usar ese nombre de versión cuando haga una copia de seguridad del código y cuando se refiera a la versión o cuando la mueva a algún lugar, debe nombrar el subdiectorio que lo contendrá después de la versión.
La versión que colocará en prod en un futuro próximo es una versión diferente, y si realiza cambios de nuevo, esta también es una versión diferente.
Como regla general: aumente el número de versión cuando mueva o exporte el código, cuando intercambia o cambia o actualiza entre ubicaciones, cuando hace una demostración, y después de cada función o hito y cada vez que lo hace una copia de seguridad completa.
Tenga en cuenta que los archivos de configuración (3, uno para prod, test y dev) NO son parte de las versiones. Entonces puedes "mover las versiones" pero no los archivos de configuración. Si puede, coloque los archivos de configuración FUERA del árbol con el resto del código, para que no tenga que separarlos y tenga cuidado cuando pase las versiones más adelante. Puede mover el directorio config one "arriba" y acceder a ellos desde los archivos como este:
"include ../config.php";
3) Si desea usar sistemas de control de versiones, hacen un gran trabajo, pero necesita tiempo para acostumbrarse y si tiene prisa con su actualización probablemente no sea el momento adecuado para comenzar en vivo. con eso ahora. Pero en el futuro recomendaría utilizar un sistema de control de versiones distribuidas de última generación. Distribuido significa que no necesita configurar un servidor y muchas más ventajas. Voy a nombrar bazar, si es necesario actualizar a través de ftp puede hacerlo. Tenga en cuenta que un sistema de control de versiones hace que el intercambio de una versión sea muy rápido, ya que solo se escriben las diferencias entre las versiones. Bazar tiene una comunidad y documentación que hace que sea fácil comenzar. También está Git, que tiene el sitio de alojamiento comercial más actualizado: http://github.com. Puede ver el código en línea y comparar entre las versiones y hay muchas más funciones útiles, incluso si usted es el único programador, pero en un grupo es incluso mejor. La elección entre los sistemas no es fácil. No puedo recomendar CVS, que está desactualizado. Además SVN no es la última generación del sistema de control de versiones distribuidas, no recomendaría su uso si no hay una razón específica, y contaminará todos sus subdirectores con subdirectorios especiales, lo que puede ser molesto. Para gente que ya está acostumbrada y que ya tiene código, está bien, pero para empezar, yo diría que no.
Hay también Mercurial y Darcs entre los sistemas de control de versión de código distribuidos y abiertos. Mercurial también tiene un gran sitio comercial para la colaboración y la vista de código en línea (http://bitbucket.org).
4) Mientras no uses un sistema de control de versiones, ¿qué tal si usas enlaces simbólicos?
Puede tener un directorio en el servidor src/versions/somewhere y colocar las versiones nombradas allí, cada una en su propio subdirectorio. Solo agregará versiones (porque una versión que existe no se cambiará, si la cambia se convierte en una nueva versión)
Puede tener src/versions/v001/src/versions/v002/src/versions/v003/o cualquier esquema de nombres que use.
Ahora aquí viene el truco:/var/www/prod/htdocs es un enlace simbólico a src/versiones/V001/
Cuando se actualiza a v002 que acaba de hacer lo siguiente:
- apagado Apache
- eliminar los viejos enlace simbólico/var/www/prod/htdocs (en este punto el Webroot Apache se ha ido!)
- crear el nuevo enlace simbólico/var/www/prod/htdocs ser un enlace a src/versiones/v002
- s Apache tarta
También puede escribir un guión para esto con parámetros y lo llaman así:
upgrade-web prod 002
Esto hace que la brecha aún más corto.
A veces hay que hacer un "retroceso", cuando descubres que la nueva versión tiene errores en la producción y tienes que volver atrás. Esto sería fácil (porque no eliminas los directorios anteriores, simplemente dejas apache, borras el enlace simbólico y lo vuelves a crear en la ubicación anterior, en este caso src/versions/v001)
Y si prueba y dev está en el mismo servidor, puede, por supuesto, vincular simbólicamente los mismos directorios, por lo que no habría ninguno para mover o copiar.
5) Si lo hace manualmente sin enlaces simbólicos, ¿por qué no se mueve en lugar de copiar?
(Cuando los archivos no están aún en el mismo servidor, puede copiarlos en algún lugar cercano, y luego comenzar con la migración, por lo que no tiene que detener el servidor por un tiempo tan ling)
Si hay varios directorios en el nivel raíz del proyecto, puede moverlos uno a la vez. Asegúrese de NO MOVER los archivos de configuración. O encuentra alguna estrategia para traerles bakc.Flujo de trabajo sería:
- Parar Apache
- quite todos los directorios prod actuales y los archivos en el directorio raíz, excepto archivo (s) de configuración
- Mover todos los nuevos directorios prod y archivos a nivel de la raíz, excepto el archivo de configuración (s)
- iniciar Apache
6) tratar de encontrar su archivo individuo perfecto y la estructura de directorios y flujo de trabajo perfecto. Esto lleva algún tiempo y algo de reflexión, pero vale la pena. Hazlo en una hoja de papel hasta que encuentres la mejor solución. Esto podría significar que tiene que refactorizar su código y cambiar los archivos de configuración del servidor, pero para el futuro su vida es más fácil cuando realiza la administración y las actualizaciones. Desde mi experiencia: no esperes tanto con este paso. Su diseño debe hacer que sea fácil y seguro actualizarlo. Actualizar no es algo extraordinario, es una rutina y debe ser seguro y simple de hacer.
7) Si nombra sus entornos de servidor y estación de trabajo (supongo que el sistema operativo del servidor es linux, pero ¿es un servidor alojado o raíz, tiene acceso ftp o también shell (ssh), o sftp? ¿dónde se desarrolla, en una máquina de Windows o en un Mac?), entonces las personas pueden nombrar las herramientas para copiar y mover. También es interesante: ¿el servidor de prueba y el de desarrollo son la misma máquina? Si no es así, ¿cómo están conectados o no? De lo contrario, realizaría una transferencia de 3 vías (cópielo en su estación de trabajo local y luego en el servidor).
8) Piense en los permisos de archivos. Si mueve los archivos o los copia, tal vez los permisos de los archivos cambien, y si la aplicación depende de algunos de ellos, debería haber una manera de verificar y quizás cambiar. Ejemplo: algunas aplicaciones necesitan directorios modificables donde colocan archivos cargados o archivos de sesión o caché de plantillas. Otras aplicaciones no permiten que algunos archivos de seguridad sean escribibles.
me acabo de enterar de que Teddy parece haberse ido :-) esta pregunta se hizo hace 5 meses, por lo que probablemente no acepte una respuesta. Es un buen hilo, cualquier cosa. – user89021