tutorial - ¿Cuál es su flujo de trabajo de implementación de aplicaciones web favorito con SVN?
svn tutorial español (11)
Cuando trabajaba en un pequeño equipo de desarrollo (pequeño significando yo, otro programador y el jefe), era un desastre bastante caótico. Sin embargo, encontramos que la asignación de un tipo de proceso de "guardián" funcionó para nosotros.
El portero fue la persona que hizo más trabajo en la aplicación (en este caso, tuve 2 proyectos que desarrollé desde cero, tuvo como 4).
Básicamente, cada vez que tenía que trabajar en mis proyectos, me avisaba que estaba haciendo un trabajo, me aseguraba de que el repositorio estuviera actualizado y se pudiera compilar, luego bajaba, hacía los cambios y luego se comprometía . Él me informaría que ya estaba hecho, que desplegaría, construiría y desplegaría. Si hubo cambios en la base de datos, teníamos una carpeta DB Change con todos los scripts que corregirían la base de datos.
Obviamente tiene muchos agujeros, pero el proceso funcionó para nosotros y nos impidió construir uno sobre el otro.
Actualmente estamos usando una configuración de implementación algo complicada que involucra un servidor SVN remoto, 3 ramas SVN para DEV, STAGE y PROD, promocionando el código entre ellas mediante parches, etc. Me pregunto qué usas para la implementación en una pequeña situación de equipo de desarrollo ?
Una simple rama de tronco contiene el código más actual, luego corta una rama cada vez que entramos en funcionamiento. Esto parece funcionar bastante bien. Puede ir fácilmente a la bifurcación anterior cuando falla la bifurcación actual que corta para el sistema en vivo. Además, es fácil corregir errores en la rama que está actualmente activa, y dado que la rama efectivamente muere cuando se corta una nueva, solo hay una rama real en la que se necesita trabajar (y luego fusionar correcciones de allí a la rama viva).
No usamos sucursales para organizar material relacionado con la web; solo para probar cosas experimentales que tomarán mucho tiempo (léase: más de un día) para volver a fusionarse en el tronco. El tronco, en el estilo de "integración continua", representa un estado actual (con suerte) de trabajo.
Por lo tanto, la mayoría de los cambios se confirman directamente en trunk. Un servidor CruiseControl.NET se actualizará automáticamente en una máquina que también ejecuta IIS y tiene copias actualizadas de todos los recursos de sitios adicionales disponibles, por lo que el sitio puede ser completamente probado de manera limpia internamente. Después de la prueba, los archivos se cargan en el servidor público.
No diría que es el enfoque perfecto, pero es simple (y por lo tanto adecuado para nuestro personal relativamente pequeño) y relativamente seguro, y funciona muy bien.
Usamos la bifurcación de liberación, esto parece ser más eficiente para nosotros que la función de bifurcación que estábamos haciendo.
No hagas diferentes ramas para los diferentes entornos.
tronco para el desarrollo y una rama (producción) para el material de producción.
En mi máquina local, tengo un VirtualHost que apunta a la rama del enlace troncal, para probar mis cambios.
Cualquier compromiso con el tronco desencadena un enlace de confirmación que realiza una exportación svn y se sincroniza con la URL dev del servidor en línea, por lo que si el sitio es .com, este enlace actualiza automáticamente dev..com
Luego utilizo svnmerge para unir los parches seleccionados del tronco a la producción en mis registros locales. Tengo un VirtualHost nuevamente en mi máquina local apuntando a la rama de producción.
Cuando confirmo los cambios fusionados en la rama de producción, nuevamente un gancho de exportación SVN actualiza la exportación de producción (en vivo) y el sitio está en vivo.
No he tenido ningún problema con la organización common tags / branches / trunk.
El desarrollo general en curso ocurre en el tronco.
El mantenimiento de un lanzamiento en producción ocurre en la rama de lanzamiento apropiada.
Los cambios en la rama de publicación que todavía son relevantes para el enlace troncal se fusionan.
Cuando una nueva versión está lista para el despliegue, se etiqueta desde el tronco, luego se crea una rama a partir de esa etiqueta. La nueva rama de la versión se comprueba en el servidor, en paralelo a la versión actual. Cuando es hora de cambiar, las rutas se hacen juegos malabares ("mv appdir appdir.old && mv appdir.new appdir").
Los desarrolladores que apoyan la versión de producción, luego svn cambian su copia de trabajo a la nueva rama, o hacen una nueva salida de la misma.
Personalmente trabajo localmente (desarrollo), agrego / corrijo funciones y cuando pienso que está listo me comprometo con trunk (producción). En el servidor de producción solo hago una actualización svn.
Trabajo con una situación similar a la que tienes actualmente. Me encargaron encontrar una solución ''mejor'' y me encontré con algo parecido a lo siguiente.
La rama activa representa los servidores en su estado actual.
Cualquier trabajo de desarrollo debe hacerse en una rama que se toma de vivo. Este podría ser un trabajo de media hora de una persona o un proyecto de equipo múltiple de un año. Con la frecuencia que desee, los cambios en la vida se pueden fusionar en estas ramas de desarrollo.
Antes de que una pieza de trabajo se active, los cambios de Live se fusionan nuevamente y se etiquetan como una posible versión. Esta versión se prueba en el entorno de ensayo intermedio y, si supera la prueba, el nuevo directo se tomará de la etiqueta.
Es posible fusionar varias piezas de trabajo en una sola versión si eso funciona mejor.
Esto significa que es bastante simple mantener las ramas de desarrollo actualizadas en vivo y si una pieza de trabajo en desarrollo se descarta, hay un mínimo de preparación.
Para pasar de trabajar en un proyecto a otro, un desarrollador puede simplemente cambiar su entorno de trabajo local a una rama diferente.
Uno de los problemas que hemos tenido con el sistema como usted describe es que DEV puede desaparecer con PROD con bastante rapidez, por lo que no se está desarrollando en contra de la transmisión en vivo y no es fácil detectar las dependencias cruzadas hasta la etapa. La solución anterior resuelve estos problemas sin dejar de ser bastante ligera.
Trunk contiene la base de código de desarrollo "principal" actual.
Un desarrollador a menudo creará una sucursal individual para cualquier proyecto de mediano y largo plazo que pueda manguera la base de códigos troncales y se interponga en el camino de los otros desarrolladores. Cuando esté completo, se fusionará con el tronco.
Creamos un etiquetado de lanzamiento cada vez que empujamos el código a la producción. La carpeta en / tags es simplemente el número de versión.
Para implementar en producción, estamos haciendo una exportación de SVN a etapas. Cuando eso es satisfactorio, utilizamos una rsync simple para implementarla en los clusters de producción.
Recomiendo encarecidamente el libro (actualmente en cortes generales) Entrega continua , que describe un proceso completo para administrar la entrega de software, basado en principios de integración continua (entre otros).
No me gusta mucho el enfoque de ramificación y fusión, ya que puede ser muy complicado, y es bastante derrochador ya que terminas pasando tiempo en actividades que en realidad no ofrecen ningún valor nuevo. Ya ha desarrollado, probado y reparado su código una vez, ¿por qué crear una situación (copiar el código a otra rama) que requiere que vuelva a hacer este trabajo?
De todos modos, la forma de evitar la bifurcación y la fusión es construir sus artefactos desplegables desde el tronco y promover los artefactos construidos (en lugar de la fuente) a medida que pasan las pruebas, etapas, etc. De esta manera, está 100% seguro de que lo que está poner en producción es lo mismo que has probado.
Si tiene diferentes funciones que pueden necesitar ser publicadas en diferentes programaciones, cambiar su enfoque de cómo implementarlo (hacer que la funcionalidad sea configurable, o mejor aún, modular) puede ayudarlo a mantener un solo tronco de desarrollo.
Tres ramas solo suenan como trabajo extra.
Las diferencias ambientales se pueden manejar teniendo diferentes versiones de los archivos relevantes en el tronco. es decir, database.yml y database.yml.prod. El proceso de implementación debe ser respetuoso con el medio ambiente y simplemente copie los archivos por ambiente sobre los predeterminados.