svn - create - tortoise merge

SVN pago o exportación para el entorno de producción? (10)

En un proyecto en el que estoy trabajando, tenemos una discusión en curso entre el equipo de desarrollo: ¿debe implementarse el entorno de producción como una salida del repositorio SVN o como una exportación?

El entorno de desarrollo obviamente es un pago, ya que se actualiza constantemente. Para la producción, personalmente estoy revisando la troncal principal, ya que hace que las futuras actualizaciones sean más fáciles (solo ejecute svn update). Sin embargo, algunos de los desarrolladores están en contra, ya que svn crea archivos con el grupo / propietario y permisos del proceso svn (esto es en un sistema operativo Linux, entonces esas cosas importan), y también teniendo los directorios .svn en la producción parecen ellos están algo sucios

Además, si se trata de un proceso de pago, ¿cómo se introducen las características individuales en la producción sin incluir el código de desarrollo? ¿Usas etiquetas o ramas para cada función? alguna alternativa?

EDITAR: Puede que no haya sido claro: uno de los requisitos es ser capaz de implementar correcciones constantemente en el entorno de producción. Queremos evitar una compilación completa (que lleva mucho más tiempo que una simple actualización) solo para implementar soluciones críticas.

Aquí hay algunas opiniones -

Los archivos .svn en producción están sucios? Si los directorios .svn están intactos y no están corruptos, están lejos de ser sucios, en realidad son un salvavidas. Para mayor seguridad, puede decirle a apache que no los explore.

¿Pagar o exportar? mi enfoque ... Definitivamente uso etiquetas y ramas: es peligroso conectar un servidor de producción al trunk y rezar para que nadie ejecute svn up justo después de que alguien haya ingresado un código defectuoso en el trunk para ver qué hace en DEV. Tengo una etiqueta reutilizable (digamos _producción y _estadificación) y al comienzo de mi configuración compruebo cada una en el servidor correspondiente. Luego bloqueo todos los accesos para modificar los contenidos del servidor en vivo y en etapas. A partir de entonces, el servidor DEV está vinculado a la cabeza del tronco. Cuando el código es lo suficientemente estable para QA / staging, creamos una etiqueta y le cambiamos el nombre a _staging para permitir que el servidor de transición se sincronice con ella (el script ejecuta ''svn up'') siempre que vea cambios en esa etiqueta. Una vez que estamos contentos con _staging, le cambiamos el nombre a _production y eso hace que el código se implemente en el servidor en vivo. Alternativamente, puede crear etiquetas / ramas con diferentes nombres y usar ''svn switch URL'' para apuntar el servidor a una nueva etiqueta / rama (punto fijo). Todo lo anterior hace que sea muy fácil de implementar sin tiempo de inactividad y si la reversión es necesaria, puede cambiar rápidamente el nombre de la antigua etiqueta archivada o usar ''svn switch OLD_URL'' para deshacer inmediatamente los nuevos cambios sin preocuparse por cada archivo pequeño y cambios de línea.

Permisos y propiedad Si comprende y sabe cuáles son los permisos para los archivos, puede hacer que se ejecute el script después de cada implementación para configurar CHOWN y CHMOD según lo que desee.

Miedo contra conocimiento He oído que muchas personas temerosas descartan la presencia de SVN en el servidor de producción. Lo opuesto es realmente muy aterrador. ¿Cómo le asegura al equipo de productos y a los clientes que la aplicación no colapsará en una gran pila o mensajes de error sin la capacidad de realizar ejecuciones en seco o ''svn status -u'' para garantizar que la implementación modifique solo aquellos archivos que necesitan ¿cambio? Verificar el estado me permite incluso saber si alguien se abrió paso e hizo un ''cambio rápido'' directamente en el servidor: sabes que las personas tienden a eludir las reglas por cosas que les parecen rápidas.

Imaging ¿hay un error en el servidor en vivo? con .svn, puede identificar la versión exacta con la que está sincronizado (svn info) y luego verificar si es verdadera para esa url (sv status -u). Luego puede construir una réplica honesta de esa configuración revisando la misma etiqueta / versión en un servidor de espacio de pruebas donde puede solucionar problemas de manera segura.

Buscaría algún software de implementación como Capistrano (es un programa de ruby)

Yo personalmente usaría la exportación de una copia etiquetada de la línea troncal en lugar de solo exportar la línea troncal si va a utilizar su propia solución o manualmente.

En mi humilde opinión, debe crear una rama / etiqueta donde tenga el subconjunto (deseado) del dev env que utiliza para la producción. Alguien debería mantener esto de forma manual o automática utilizando scripts. Entonces, debe exportar (en lugar de pagar). Las actualizaciones incrementales no son un problema, a menos que esté cambiando los archivos en su entorno de producción y no desea sobrescribir esos archivos.

Solo mi $ 0.02

He estado luchando con esto, y creo que finalmente decidí pagar. Sí, hay basura adicional allí, pero ...

Exportar no tiene en cuenta los archivos eliminados (a menos que su solución sea eliminar todo en el directorio y ENTONCES exportar, lo que creo que es mucho peor). Checkout eliminará los archivos eliminados.
El pago es más rápido. Período. La cantidad de archivos que se actualizan significa menos tiempo de inactividad / transición, y una exportación tira hacia abajo y sobrescribe TODO, no solo los archivos que necesitan una actualización.

No digo que funcionará para todos, pero estas dos cosas influyeron en mi decisión. La mejor de las suertes con tu decisión.

Lo despliego como una copia. No es manual, por supuesto.

Yo uso ''make'' y ''checkinstall''. Creo un pequeño Makefile que usa el comando del sistema ''install'' para copiar todos los archivos necesarios a los directorios apropiados en el servidor web, y tengo preinstall y postinstall scripts de shell que se ejecutarán en el servidor.

Cuando llega el momento de la implementación, simplemente ejecuto ''checkinstall'', que crea un paquete (RPM, DEB o TGZ, según la distribución de Linux a la que apunte). Lo instalo utilizando las herramientas comunes proporcionadas por un administrador de paquetes de distribución de Linux (rpm, dpkg, pkgtool). Por supuesto, si desea rastrear dependencias también, puede usar yum, apt-get, etc.

Lo hace realmente fácil si desea distribuir una nueva versión de su aplicación web. a múltiples servidores de destino. Y cosas como desinstalar, volver a una versión anterior, etc. son muy fáciles porque tiene un paquete listo para usar para cada versión que implementó.

Sin embargo, esto podría no ajustarse a su estrategia de "empujar a menudo" si usa algunas cosas que necesita compilar. Sin embargo, para crear scripts (como PHP que hago), crear un paquete (de más de 300 archivos PHP) lleva unos 20 segundos en mi máquina. Y casi tanto para instalarlo en cualquier sistema de destino.

Para separar el código "para publicación" del código "en desarrollo", utilizo la ramificación. Con Git, es realmente fácil, ya que la bifurcación es barata y rápida.

Personalmente, siempre tengo dudas sobre la solución de este problema, prefiero no tener directorios ".svn" en mi entorno de producción, está muy sucio pero, al mismo tiempo, exportar es muy tedioso con aplicaciones web de gran tamaño (especialmente si usa algunas "Componentes" de terceros como Extjs, FCKeditor, etc.).

Creo que no hay "soluciones asesinas" en este momento.

Sin duda, exportar

No estarías haciendo actualizaciones, por lo que no hay razón para solicitar el pago. Simplemente estarías desplegando basura.

Yo diría que cualquier entorno debería ser solo una exportación; solo usa el proceso de pago localmente cuando se está desarrollando. Por supuesto, también usamos scripts de compilación, por lo que actualizar la implementación es tan simple como ejecutar el script.

En cuanto al código de desarrollo, cree ramas para cualquier trabajo que se realice. Solo comprométase con el troncal cuando esté listo para su implementación en el entorno de desarrollo.

déjame ver ..... ¿ls? para que se puede usar?

/var/www/www.my-prod-site.com/public/ /var/www/www.my-prod-site.com/builds/Rev 1/ /var/www/www.my-prod-site.com/builds/Rev 2/ /var/www/www.my-prod-site.com/builds/Rev 3/ /var/www/www.my-prod-site.com/builds/Rev 99/

svn exportar a los directores de tus compilaciones ... copia cualquier archivo de configuración de / public que sea tu enlace simbólico a tu versión de lanzamiento anterior, y luego simplemente cambia el enlace simbólico de public a apuntar a tu nuevo directorio de compilación. se tarda menos tiempo fuera de línea que cualquiera de las cosas que he visto publicado aquí, y también hace que VUELVA MUCHO MÁS RÁPIDO a menos que uses tu DB cada vez que altera las tablas.

Las preguntas frecuentes de Subversion parecen abogar por la implementación como un proceso de finalización de compra, automatizado con scripts de enlace post-commit. Impiden que Apache exporte carpetas .svn (probablemente sea una buena idea) agregando lo siguiente en httpd.conf:

# Disallow browsing of Subversion working copy administrative dirs. <DirectoryMatch "^/.*//.svn/"> Order deny,allow Deny from all </DirectoryMatch>

Soy extremadamente nuevo para svn, pero tal vez podría desencadenar un script de gancho cuando cree una nueva etiqueta. De esta forma, cuando esté listo para actualizar el sitio en vivo, solo debe confirmar sus últimos cambios en el enlace troncal, crear la nueva etiqueta y el script actualizará su sitio en vivo con la actualización de svn.

EXPORTAR

Eso es. No tiene ninguna buena razón para poner basura adicional en el sistema de producción.

Expondrás tu código fuente
Si esta es una aplicación web aún peor, tus visitantes pueden descargar tu código fuente, ¡qué bueno es eso! muy abierto :)