Acabo de comenzar un nuevo trabajo el mes pasado y parece que NO tienen control de fuente para su código. Confían en las copias de seguridad que su proveedor de hosting toma para ellos.
Después de hablar un poco, convencí a mi jefe de que definitivamente deberíamos usar el control de fuente y después de dar un breve seminario sobre él, todo el equipo está a bordo; ellos amaban a Mercurial.
Así que ahora esta es la forma en que trabajamos:
º----------BitBucket
º---------/
º--------/Yo y los otros tres desarrolladores hg pullde BitBucket, hacemos nuestros cambios, luego hg pusha BitBucket.
Ahora para la implementación, alguien necesitaría enviar por FTP los últimos archivos hacia el servidor de producción.
Estaba pensando en instalar Mercurial en nuestro servidor, y usar hg clone(posteriormente hg pull) para mantener las versiones actualizadas en producción.
º---push->-----BitBucket----<-pull-----º (production server)
º---push->----/
º---push->---/¿Es esta una buena idea? ¿Alguna dificultad potencial que no esté viendo? ¿Alguien aquí ha hecho algo similar? ¿Cómo se implementa una gran aplicación de marco PHP (estamos usando Moodle)?
fuente
Respuestas:
Esta es ciertamente una buena idea y es un método común para usar para la implementación. Es posible que desee utilizar una rama estable para fines de implementación mientras mantiene el tronco para el desarrollo continuo para que pueda probar la rama estable antes de implementarla en producción.
El único problema puede surgir cuando tiene información confidencial en su base de código (como claves de API, etc.) que no desea cargar en servidores de terceros (en su caso, sería Bitbucket). En este caso, una secuencia de comandos simple que se ejecuta una vez que ha extraído los datos del repositorio para restaurar los datos confidenciales en el lugar correcto resolverá ese problema.
fuente
Tenga en cuenta que esta estrategia de implementación no es atómica. Puede suceder que algunos archivos ya estén actualizados, mientras que otros archivos aún podrían estar en el estado anterior mientras se aplicaba la aplicación. Esto puede causar efectos secundarios inesperados.
Una forma de hacer despliegues atómicos es, por ejemplo, usar enlaces simbólicos. Cree un directorio que contenga los nuevos archivos. cuando todo esté listo, cambie un enlace simbólico para el directorio utilizado. Si mantiene la versión anterior, también puede revertir fácilmente.
fuente
Otra posibilidad (en mi opinión mejor) : usar un servidor de compilación / servidor de integración continua.
Breve explicación breve: este es un servidor (puede ser interno, no necesita estar en Internet) que configuró para monitorear sus repositorios, y cada vez que hay nuevos conjuntos de cambios en los repositorios, el servidor construye su código ( AFAIK esto no es necesario en PHP) , ejecuta pruebas unitarias e implementa su código en el servidor web.
Para obtener más información, consulte estos enlaces:
Existen muchos productos diferentes para CI , pero el único que he usado hasta ahora es TeamCity . Muy fácil de configurar ... de hecho, es el primero que probé, y me gustó tanto que me quedé con él.
Solución barata alternativa:
Si configurar un servidor de compilación es demasiado esfuerzo o si desea tener más control sobre cuándo se implementa exactamente su sitio, simplemente configure un archivo de script (Batch / Powershell en Windows, o algo similar en Linux / Mac) que extraiga el versión más reciente de su repositorio y FTP en el servidor de producción.
Básicamente, es lo mismo que un servidor de compilación, pero más simple.
No importa cómo lo resuelva exactamente al final ... ¡asegúrese de automatizarlo de alguna manera!
Desea poder implementar con un solo clic / escribiendo un solo comando, para que TODOS puedan hacerlo sin tener que saber nada especial y sin cometer errores, incluso en caso de desastre o bajo estrés.
fuente
Hacemos esto o cosas similares a esto. El ángulo no atómico de @johannes menciona que es un problema, aunque en términos realistas sucede tan rápido que debería estar bien y hay formas de evitarlo, como él señala.
Probablemente, más importante que esta no atomicidad sería "cómo se gestionan las actualizaciones del esquema de la base de datos": la implementación de código incorrecto de esta manera facilita la reparación. El gran problema es cuando implementa una actualización que cambia la base de datos que desea revertir. O si está realizando malas actualizaciones y corrompiendo datos.
El otro problema que tuvimos con las herramientas DCVS (a diferencia del uso de SVN) es que ahora tiene una copia de toda la base de código en la máquina en algún lugar que un atacante podría obtener. Y también que esa base de código DCVS puede ser bastante pesada en cuanto al tamaño, lo que podría importar si está pagando por el almacenamiento y / o la copia de seguridad. Todavía estamos usando SVN para la implementación final por estos motivos.
fuente
Es una gran idea, sin embargo, tenga en cuenta lo siguiente:
hg update -Cno afecte la producción (es decir, elimine archivos importantes)hg statussalida limpia en el servidor (esto lo ayudará a asegurarse de que está ignorando cosas como caché)Finalmente, creo que lo más valioso para agregar un DVCS a su proceso de implementación es que esto agregará seguridad a su implementación, a veces los piratas informáticos inyectan código malicioso a sus cosas y realmente no tiene medios para detectarlo fácilmente sin algo como el control de versiones ( especialmente distribuido, ya que el aspecto distribuido a VCS hace que sea más fácil verificar la integridad de sus archivos).
Algunas veces me han hackeado algunos sitios, y Mercurial me ayuda a deshacer literalmente estos hacks simplemente emitiendo un
hg update -Cen el servidor (por supuesto, es posible que desee hacerhg statusy obtener los archivos afectados para un análisis posterior).fuente