¿Cómo agrego control de versiones a mi flujo de trabajo?


11

Desarrollo temas, muchos de ellos. Me dan un PSD, codifico el HTML / CSS, coloco el código en Wordpress y hago correcciones a medida que reciben QC. Una vez en vivo, los clientes pueden editar publicaciones de blog como normal o subir fotos usando un complemento personalizado.

A veces tengo que hacer cambios en el tema o en el contenido de la página / publicación, lo que significa que los hago en vivo o tengo que descargar y configurar el sitio en un entorno de desarrollo para que el cliente lo apruebe. No tengo copia de seguridad, no tengo control de versiones, y me doy cuenta de que esto debe cambiar.

Se han sugerido Git y Mercurial, y me gustaría aprovechar estas herramientas, pero estoy confundido acerca de cómo encajarlas en un flujo de trabajo.

¿Debo solicitar todos los cambios en un sitio en un servidor de desarrollo y luego enviarlos una vez aprobados? ¿Qué hay de escribir publicaciones de blog? Parece excesivo escribir publicaciones en dev y enviar los cambios en vivo, pero entonces, ¿cómo sincronizo las bases de datos si se editan en el sitio en vivo? He buscado en internet. Se agradecería alguna orientación.


Creo que esto califica como una pregunta de ecosistema fuera de alcance. Ver aquí para una discusión en curso .
Chip Bennett

44
@ChipBennett No estoy de acuerdo. Las dependencias específicas de WordPress entre temas, complementos y bases de datos y cómo afectan la práctica general del desarrollador son bienvenidas.
fuxia

@toscho Ciertamente podría estar convencido de eso; Es por eso que señalé la discusión Meta. :)
Chip Bennett

Respuestas:


9

En primer lugar, debe reconocer que hay dos flujos de trabajo aquí: el suyo y el cliente.

Su flujo de trabajo

  • Recibir PSD
  • Código HTML / CSS
  • Código de plantilla de WordPress
  • Implemente el tema para vivir el sitio de WordPress

Su flujo de trabajo

  • Diseñe los cambios necesarios y envíele un correo electrónico
  • Escribir publicaciones
  • Subir fotos

La cuestión

La implementación del control de versiones aquí no tiene absolutamente nada que ver con el flujo de trabajo de sus clientes. Se trata de realizar un seguimiento del código que usa para el tema de WordPress. Todos sus archivos de tema, complementos personalizados, etc. deben estar en un sistema de control de versiones (Git, Mercurial, Subversion o lo que elija usar).

Su flujo de trabajo se convierte en:

  • Escribir código
  • Confirmar cambios en el sistema de control de versiones
  • Empujar cambios al sitio de producción
  • Reciba comentarios del cliente
  • Escribir código
  • Cometer cambios
  • Escribir código
  • Cometer cambios
  • Empujar cambios al sitio de producción

Recuerde, se trata de mantener un historial de control de versiones para su código . El código es algo que sus clientes no deberían cambiar, y nunca debe cambiar el código en un sitio de producción mientras está en producción.

Pero los cambios en el contenido (publicaciones, fotos, etc.) están fuera del alcance de su sistema de control de versiones. En otras palabras, no realiza cambios en el desarrollo y luego empuja la base de datos a producción. Esa es una mala práctica de desarrollo. Si necesita que las bases de datos de desarrollo y producción estén sincronizadas, entonces debe extraer una copia de seguridad de la caja de producción y restaurar su versión local a partir de esa copia de seguridad.

El código cambia el flujo del desarrollo a la producción.
Los cambios en la base de datos fluyen de la producción al desarrollo.


Realmente no puede sincronizar las bases de datos fácilmente a menos que tenga un script especial que gestione cómo se almacenan los datos de contenido en la base de datos. Es por eso que separa el código del contenido en su flujo de trabajo, la alternativa es usar un servidor de ensayo o intentar usar uno de los scripts de sincronización de db o escribir el suyo propio.
Wyck

@EAMann Gran respuesta, ¡gracias! Lo único que agregaría al flujo de trabajo que describió sería escribir código, confirmar cambios, enviar al sitio de desarrollo, recibir comentarios del cliente, ... No había considerado dos flujos de trabajo separados porque regularmente tendremos que cambiar el contentarnos con los clientes. Ocasionalmente, tendremos que poner HTML en el contenido para acomodar solicitudes especiales dentro del contenido (estilos especiales, etc.). A veces requieren la aprobación del cliente antes de lanzarse, por lo que las bases de datos tendrían que sincronizarse. ¿Existen mejores prácticas para este tipo de configuración?
cfree

@Wyck En lugar de soltar contenido junto con la temática, tiene sentido separar los dos procesos. Me gusta la idea de un área de desarrollo para temas y un área de preparación para que el contenido caiga independientemente uno del otro. El único problema que veo es que a los clientes les gusta ver tanto el tema como el contenido (el sitio en su totalidad; páginas estáticas) antes de lanzarlo en vivo.
cfree

Por lo general, no se trata de sincronizar los cambios en la base de datos. Lo que quise decir es que tomas un volcado de tu base de datos de producción y reemplazas tu base de datos de desarrollo local con ella. Es cierto, puede automatizarlo con un script ... pero es probable que no lo haga con mucha frecuencia.
EAMann

3
Todavía no existe, es realmente una espina en el costado de WordPress, pero no es específicamente un problema de WordPress, ya que muchos CMS tienen este problema, puede leer sobre esto aquí wordpress.stackexchange.com/questions/119/... más en profundidad, algunos los scripts existen, pero la mayoría de ellos están en casa porque son específicos de un determinado entorno.
Wyck

1

Puede usar software que sincronice las bases de datos. Pero también existe la opción de versionar los datos en sí mismos con algo como http://chronicdb.com


Esto se ve interesante; puede resolver bastantes problemas. Voy a ver esto, gracias.
cfree

1

Acabo de escribir una respuesta exhaustiva a esto en otra pregunta. Personalmente uso git y es fantástico. En términos de comenzar con esto, recomendaría visitar http://gitref.org/ y http://help.github.com/mac-set-up-git/ . Si eres del tipo de libro, he leído este y definitivamente vale la pena el precio del libro electrónico de $ 22. Hazte hacerlo, no te arrepentirás de esa decisión.


Gracias, tendré que volver a consultarlo. La configuración de la base de datos maestro / esclavo suena interesante. Gracias por la orientación
cfree
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.