SVN pago o export para el entorno de producción?

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 repository SVN o como una export?

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 files con el grupo / propietario y permissions del process svn (esto es en un sistema operativo Linux, entonces esas cosas importan), y también teniendo los directorys .svn en la producción parecen ellos están algo sucios

Además, si se trata de un process de pago, ¿cómo se introducen las características individuales en la producción sin include el código de desarrollo? ¿Usas tags o twigs para cada function? 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 compilation completa (que lleva mucho más time que una simple actualización) solo para implementar soluciones críticas.

Las preguntas frecuentes de Subversion parecen abogar por la implementación como un process 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 label. 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 label y el script actualizará su sitio en vivo con la actualización de svn.

En mi humilde opinión, debe crear una twig / label donde tenga el subset (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 less que esté cambiando los files en su entorno de producción y no desea sobrescribir esos files.

Solo mi $ 0.02

Sin duda, exportar

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

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

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

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

  • Exportar no tiene en count los files eliminados (a less que su solución sea eliminar todo en el directory y ENTONCES exportar, lo que creo que es mucho peor). Checkout eliminará los files eliminados.
  • El pago es más rápido. Período. La cantidad de files que se actualizan significa less time de inactividad / transición, y una export tira hacia abajo y sobrescribe TODO, no solo los files 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.

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

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

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

Yo uso 'make' y 'checkinstall'. Creo un pequeño Makefile que usa el command del sistema 'install' para copyr todos los files necesarios a los directorys apropiados en el server web, y tengo preinstall y postinstall scripts de shell que se ejecutarán en el server.

Cuando llega el momento de la implementación, simplemente ejecuto 'checkinstall', que crea un package (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 packages de distribución de Linux (rpm, dpkg, pkgtool). Por supuesto, si desea rastrear dependencies 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 serveres de destino. Y cosas como desinstalar, volver a una versión anterior, etc. son muy fáciles porque tiene un package 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 comstackr. Sin embargo, para crear scripts (como PHP que hago), crear un package (de más de 300 files 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 directorys ".svn" en mi entorno de producción, está muy sucio pero, al mismo time, 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.

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 comstackciones … copy cualquier file de configuration 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 directory de compilation. se tarda less time 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 less que uses tu DB cada vez que altera las tablas.

Aquí hay algunas opiniones –

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

¿Pagar o exportar? mi enfoque … Definitivamente uso tags y twigs: es peligroso conectar un server 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 label reutilizable (digamos _producción y _estadificación) y al comienzo de mi configuration compruebo cada una en el server correspondiente. Luego locking todos los accesos para modificar los contenidos del server en vivo y en etapas. A partir de entonces, el server DEV está vinculado a la cabeza del tronco. Cuando el código es lo suficientemente estable para QA / staging, creamos una label y le cambiamos el nombre a _staging para permitir que el server de transición se sincronice con ella (el script ejecuta 'svn up') siempre que vea cambios en esa label. Una vez que estamos contentos con _staging, le cambiamos el nombre a _production y eso hace que el código se implemente en el server en vivo. Alternativamente, puede crear tags / twigs con diferentes nombres y usar 'svn cambiar URL' para apuntar el server a una nueva label / twig (punto fijo). Todo lo anterior hace que sea muy fácil de implementar sin time de inactividad y si la reversión es necesaria, puede cambiar rápidamente el nombre de la antigua label archivada o usar 'svn switch OLD_URL' para deshacer inmediatamente los nuevos cambios sin preocuparse por cada file pequeño y cambios de línea.

Permisos y propiedad Si comprende y sabe cuáles son los permissions para los files, 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 server 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 queuepsará en una gran stack o posts de error sin la posibilidad de realizar ejecuciones en seco o 'svn status -u' para garantizar que la implementación modifique solo aquellos files que necesitan ¿cambio? Verificar el estado me permite incluso saber si alguien se abrió paso e hizo un 'cambio rápido' directamente en el server: sabes que las personas tienden a eludir las reglas por cosas que les parecen rápidas.

Imaging ¿hay un error en el server 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 build una réplica honesta de esa configuration revisando la misma label / versión en un server de espacio de testings donde puede solucionar problemas de manera segura.

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 download tu código fuente, ¡qué bueno es eso! muy abierto 🙂