Comenzando con Subversion, Git o un sistema de control de versiones similar para mantener un historial de mis archivos. [cerrado]

No estoy seguro de cuánto sabes acerca del uso del control de versiones, pero recientemente cambié de SVN a GIT y creo que eso es genial.

Aunque depende de tu servidor en vivo, el servidor tiene GIT instalado (o te lo permitirá). También tengo una configuración de GIT en el servidor en vivo, ejecutando una rama llamada algo como production . Cuando termino de implementar / arreglar algo localmente, lo fusiono en la rama production , luego SSH en el servidor del sitio activo y presento los cambios. No es necesario arrastrar archivos a través de FTP cuando nunca se sabe si está sobrescribiendo cambios, etc.

Recomendaría que le dediquemos un poco de tiempo a obtener un GAT (si es que aún no lo ha hecho), lo encuentro mucho más fácil y menos problemático que SVN cuando se trata de cambiar / agregar cargas de archivos (y, a diferencia de SVN, no lo hace). Ponga la carpeta .svn estúpida en todas partes ).

Entonces:

Claro, estoy en una Mac, lo siento si no se aplica ninguno de estos.

Editor de código: Coda GIT instalado a través de puertos (utilizando Porticus) Git: GitX

Si tuviera que configurar todo de nuevo, lo haría:

1. Instale Coda

2. Instale Porticus (que requerirá que instale Puertos, pero hay información en esa página)

3. Una vez que hayas instalado Porticus, ábrelo, busca "git-core" e instala eso.

4. Descargue e instale GitX 7-5

5. Hay una buena guía sobre cómo configurar un git repo aquí , pero en su versión básica: 1. Abrir Terminal . 2. cd a donde desea que resida su sitio. $: mkdir mysite && cd mysite 3. $: git init y eso es todo! Si agrega archivos a esta carpeta, continúe con el siguiente paso

6. Una vez que hayas configurado un repositorio GIT localmente (artículo anterior), si abres ese directorio en GitX podrás comprometer cosas, etc., etc.

Configurar todo en el servidor puede ser un poco complicado, tengo un MediaTemple y una cuenta Dreamhost que ambos tienen GIT fuera de la caja. El enlace en 5. le dice cómo agregar un repositorio remoto, ¿no tiene que hacerlo hasta que quiera llevar su sitio en vivo a la ecuación? Recomendaría que todo funcione localmente primero (a diferencia de SVN, GIT no requiere un repositorio remoto, por lo que, por el momento, puede hacer que todo funcione en su máquina)

Uso SVN para el control de versiones con todo que hago en el desarrollo de WordPress. De hecho, comencé de esta manera porque necesitaba SVN para el desarrollo de complementos ... una vez que empecé allí, fue una extensión natural seguir utilizando SVN para temas y scripts personalizados en los sitios de los clientes.

Complementos

Ya que los complementos ya están alojados en el servidor de WordPress, simplemente reviso un complemento directamente al directorio /wp-content/plugins/ de mi instalación local de WordPress (ejecuto WAMP en mi cuadro de desarrollo). Luego realizo cambios en mi copia local y, cuando está listo para el showtime, me comprometo con el repositorio. Allí es un proceso sin problemas, sin carga / descarga y verificación instantánea de que mis cambios funcionaron.

Temas

Los temas son un poco diferentes, especialmente cuando se crean para un cliente. Creo un repositorio local (tengo una partición R en mi disco duro específicamente para este propósito) y reviso el repositorio vacío directamente en mi directorio /wp-content/themes . Luego realizo los cambios necesarios y desarrollo hasta que esté listo, realizando las revisiones a medida que avanzo.

Cuando estoy listo para publicar el tema en el servidor de producción de un cliente, exporto el repositorio, lo comprimí y uso los Temas nativos > > Añadir nueva funcionalidad dentro de WordPress. Esto funciona con complementos personalizados (que no están alojados por WordPress) también.

Herramientas

Como dije, uso WAMP en mi máquina local para ejecutar una instalación de desarrollo de WordPress. Funciona perfectamente en mi caja y me permite ejecutar tantas instancias de WordPress como necesite para un proyecto en particular.

Para SVN, uso SVN de tortuga . Es gratis, muy fácil de usar y se integra con la estructura de archivos y comandos de Windows. La actualización, la confirmación y la exportación son simples operaciones de comando con clic derecho y selección. El uso de "Exportar" le permite enviar la carpeta completa (sin las molestas carpetas .svn ) directamente a cualquier ubicación de su elección; frecuentemente exporto al escritorio. Comprimir la carpeta también es una operación de clic con el botón derecho, y WordPress se encarga de la carga.

Transferir archivos manualmente puede ser una molestia, especialmente si sigues cambiando un archivo pero no todos. Si en cambio, transfiere FTP a todo el directorio con "sobrescribir todo" seleccionado, es mucho más fácil reemplazar los archivos antiguos (y no tiene que hacer un seguimiento de los cambios y los que no). Es como la antigua instalación de 5 minutos que solía tener WordPress, simplemente reemplaza todo con la nueva versión.

Personalmente, creo que es un ejercicio divertido instalar SVN / GIT y administrarlo, pero si puedes pagar $ 15 por mes, Beanstalk vale cada centavo. Ellos gestionan todo el servidor por ti. enlace Las herramientas de implementación de FTP son increíbles. El mío implementa automáticamente la versión en mi servidor de pruebas cuando me comprometo, por ejemplo,

Otra forma de obtener algunas versiones de archivos personales es usar el cuadro desplegable. Cada vez que guarda un archivo en su Dropbox, rastrea la versión, y puede restaurar a cualquier versión anterior más adelante. Usted y otro desarrollador, o grupo, pueden compartir una carpeta de buzón. Por supuesto, esto no hace trunks, fusiones, etc., pero sí hace que sea muy fácil para un equipo distribuido trabajar en un sitio web. Simplemente no puedes trabajar exactamente en los mismos archivos a la vez.

Mantenemos nuestra copia de trabajo de SVN en dropbox, luego confirmo los archivos cuando se escribe el tiempo. Mis diseñadores no enviarán archivos ni se ocuparán de SVN, por lo que esta es la clave.

Prefiero SVN porque no necesito todos los enlaces para los que GIT es tan bueno y hay mejores herramientas GUI disponibles de SVN.

Me gusta mucho Aptana , tiene subversión integrada y puedes conectarte a tu servidor con ftp / sftp fácilmente y enviar archivos Hasta ahora, otra gran característica que tiene es que si creas un nuevo proyecto php e incluyes la carpeta "completa" de WordPress (con wp-admin, wp-includes) obtienes el código completo en tus archivos de tema.

En mi configuración, el repositorio es local.

Pides "pero estoy buscando ejemplos específicos de configuraciones / flujos de trabajo que las personas usan para mantener un historial de versiones de archivos editados en un sitio de WordPress" pero también mencionas productos :)

Se obtiene arriba como respuesta a una lista de herramientas y algunas mejores prácticas, pero me centraré aquí en los flujos de trabajo: NO SON ESPECIALES DE WORDPRESS:

Pero para los ejemplos generales / configuraciones / flujos de trabajo:

Para empezar: HAY patrones CM, tan independientes de las herramientas. Google en CM Patterns, una gran cantidad de libros por ahí, incluso comunidades de wiki, por ejemplo. enlace .

También hay guías para configurar una estrategia de transmisión válida (estrategia de transmisión de Google), etc ...

No creo que haya nada especial en las implementaciones de WordPress en comparación con CM Management incluido el desarrollo paralelo distribuido en grandes fábricas de Siebel, SAP, Informatica, Java, etc. Es realmente casi por defecto.

Lo que falta, creo, es que nadie ha escrito un plan CMplan para el desarrollo de WordPress (todavía) (IEEE). Una vez que alguien haya hecho eso (herramienta independiente). Los requisitos se pueden completar, creo, con cualquier herramienta.

Creo que la razón por la que no se ha escrito el plan es que casi todas las implementaciones de WordPress todavía están a cargo de 1 persona con una configuración simple de desarrollo y producción, por lo que no con varios desarrolladores / diseñadores en la fase de compilación que tienen que implementar diferentes versiones ejecutándose en el entorno de prueba, por ejemplo.

el plan CMP comienza con la identificación de todos los CI en otras palabras: haga una lista de todos los tipos de CI presentes en una implementación de WordPress, incluidas las aplicaciones, complementos, base de datos, documentación, ayuda, contenido, archivos de configuración, notas de la versión (!) , etc ...). Este es un buen comienzo. Luego, decide cuáles quieres incluir en CM.

A continuación, decida qué causa los cambios en estos CI, por ejemplo. una llamada del cliente para una corrección de errores, o una actualización que se necesita. Si se hace correctamente, esto conduce a una situación en la que tiene la sensación de que las cosas están bajo control.

Las decisiones como la fusión de la producción al desarrollo y la forma de manejar eso es parte de ese capítulo (2 patrones principales aquí) (aunque, por supuesto, debe tratar de minimizar estas revisiones).

Solo busque más adelante una herramienta para hacer CM en un lado (que incluye la administración de versiones como una de las herramientas) y herramientas de administración de cambios en el otro lado (lo que lo mantiene sano).

Creo que ese es el mejor flujo de trabajo para comenzar, ya que en lo que respecta a Google, nadie lo ha hecho todavía. Creo que una vez que la primera persona ha escrito un plan de WordPress CM (de acuerdo con IEEE), cualquier otra persona de WordPress del mundo puede copiar ese plan y hacer ajustes e implementar los patrones en sus herramientas.

¿No es demasiado trabajo / demasiado pesado? Depende de si tienes una empresa o no: te puede salvar el culo un buen día para tener un buen plan de CM.

Estoy en un host compartido, así que no puedo instalar SVN ni nada de eso. Uso Mercurial para controlar la versión de mi máquina doméstica. Utilizo la sincronización FTP de Beyond Compare para mantener sincronizadas las carpetas locales y remotas.

Estoy usando git. es sencillo. solo tiene que entender un comando simple como clonar, comit, push, pull y ya está listo para comenzar. eso es lo básico.

aunque, si usas git it más como coordinar un equipo para trabajar en un producto, entonces es otro nivel. pero al final, valió la pena utilizar git o cualquier control de versión. Hay confiables cuando pasan cosas.