 Bueno, ¿tenéis la tripa ya llena de churros y chocolate? Sí, no os dormiréis ninguno, ¿no? Ahora... Espero que no, porque llega con nosotros David Pérez, ¿vale? David Pérez descubrió WordPress en 2010, cuando hacía webs con Joonla. O sea, me suena, hay unos cuantos por aquí que hacía un web con Joonla. ¡Dombre de verdad! Fueron mi inicio, que no quiero reconocer mucho. Y creo su propia agencia, que es el Clubs Marketing, junto con una sofia. Se ocupa del área técnica y de marketing, y está especializado en Génesis Framework. En 2018, ha co-organizado la primera Workand de Granada, y esta es su primera charla en una Workand, donde nos va a hablar de, olvídate del FTP, mejora tu flujo de trabajo con version Control y GitPass. ¿Lo he puesto difícil, título? ¿Eh? ¿Lo he puesto difícil, título? Sí, sí, un poquito, pero bueno, no hay problema. Os dejo con David Pérez, un fuerte aplauso. Bueno, hay gente de Granada. Bueno, pues muchas gracias. Yo voy a empezar con una pequeña historia, y no sé si algunos sonarán. Algunos sí, por aquí y otros no. Yo me aficioné muchísimo a la aventura gráfica, que para el que no la conozca, básicamente era una serie de puzzles que tú tenías que ir con el protagonista, tenías que decirle, coge esto, a esto, a lo otro. Y la verdad es que echábamos ahí la tarde bastante entretenida. Y el que más me gustó con diferencia fue Indiana Jones. Y le he dado la temática a esta presentación, todo con Indiana Jones. Me caracteriza un poquito, no mucho. Pero, falta el lático y a faltar el gorro, pero ya yo llegábamos a nivel de ridículo demasiado. Bueno, básicamente lo que os ha presentado, soy David Pérez. Eso ha estado en la Workand Granada organizando, que también para este año ahora seguramente Workand Granada. Me podéis encontrar DavidPérezCar.com y mi Twitter es DavidPérezMK. Pues, comentaros. Todas las dispositivas las voy a dejar junto a una guía específica, porque es una charla rápida, en una URL que os dejaré al final de la presentación. Bueno, pues básicamente este es un flujo de trabajo que para mí fue, vamos, encontrar un tesoro. Fue un tesoro porque realmente ahorra muchísimo tiempo y muchos crevadores de cabeza. El flujo de trabajo consiste en trabajar en local, trabajar con control de versiones y hacer despliegue de tu código ya cuando lo tienes realizado. Entonces, esos tres factores, realmente es un tesoro porque ahorra muchísimo trabajo y ahorra mucho tiempo. Cuando tú trabajas con un repositor y un control de versiones, aquí tienes una forma de trabajar que es con dos ramas, una rama de desarrollo, de develop y una rama de master. Haciendo despliegue, puedes mandarlo, la de develop, las puedes mandar a un staging o una página de prueba y la master, cuando ya tienes el código depurado y revisado, puedes mandarla directamente a producción. Entonces, siempre y cuando tengan muy bien depurar el código, la rama de master, cuando vaya a hacer un envío de código, un push, como tienes ya depurado el flujo y ya lo tienes configurado directamente, saldría la página de producción. Entonces, en definitiva, puedes trabajar con varias ramas. Yo, cuando hago temas de WordPress, utilizo solo una rama, la master y cuando hago plugin, hago don rama, una de develop y una de master. Y si quiero hacer alguna cosa más, pues pongo alguna rama más, pero básicamente trabajo con una o dos. Ya en desarrollos más completos, con un equipo mucho más grande, yo trabajo con una o dos personas, pues sí puedes trabajar con muchas más ramas. ¿Por qué trabajar con entorno local? Bueno, quien no trabaja en entorno local, trabaja como se llama también vulgarmente en caliente, pues no lo recomiendo, ¿por qué? Porque no es nada seguro, estamos trabajando en una página que, en teoría, tiene tráfico, tiene visitas y pueden encontrarse errores en su navegación. Entonces, eso totalmente descartado. Puedes depurar mucho mejor, trabajando local, puedes hacer pruebas, puedes meter plugin, quitar, poner. En definitiva, estás viendo lo que estás haciendo desarrollando y, a partir de ahí, puedes hacer las pruebas que te haga falta. En definitiva, estás tú trabajando con el código y no tienes problemas para poder seguir trabajando y haciendo pruebas. ¿Por qué trabajar con control de versiones que también con local? Porque hay una forma de trabajar distribuidad de trabajo con código. Cuando hay un equipo de personas, o incluso uno solo, puedes trabajar en equipo porque otra persona está cambiando código y cuando tú te bajas las modificaciones de la otra persona, si ha afectado alguna línea que tú hayas también modificado, te dice el Git, hay conflictos que se llaman. Pues en ese conflicto, aquí me encuentro el tesoro y me quedé detenido jugando un ratillo con el día de hoy otra vez. Y entonces, en definitiva, ve el conflicto y puedes cambiar el código y ya arreglarlo y ponerlo con lo que había modificado la otra persona. En definitiva, hay una seguridad y luego lleva un histórico. Tú vas documentando todo lo que vas haciendo. Entonces, a través de control de versiones, cada vez que modificas, normalmente, ya un poco aquitido de la persona, pero normalmente cuando has modificado varias líneas o tienes varios archivos, modificado hace un comit que se le dice, una notación, un registro de esos cambios y lo subes al repositorio. Entonces, realmente cuando vas al histórico, ves todo lo que se ha modificado de otra persona o la tuya. Ociones de mercado de Git, pues hay un montón. Las más populares son GitHub, que ahora ha sacado un plan nuevo para la persona de personal gratuito, con lo cual podemos trabajar con repositorios privados. También tenemos con Bitback, repositorios privados gratuos y hasta cinco personas. Y la versión OpenSore. En definitiva, yo recomiendo, sobre todo, hay más control de versiones, que son su versión y en unos contos más. Mercurial, a mí el que más me gusta de Git y, de hecho, es un poco la que más se está imponiendo ahora en el mercado, donde más se ve, sobre todo GitHub, que es la versión de Git más popular también. Y, en definitiva, es que vosotros veáis los planes que necesiteis, veáis un poco el equipo que tenéis y trabajéis con carquera de ellas. Una vez que hacemos... Hemos trabajado en local. Hemos trabajado con control de versiones. Estamos documentando todos los cambios. Hacemos un push. Hacemos el despliegue. El despliegue, quiere decir, es que una vez que hemos cambiado los códigos, lo hemos registrado y hacemos push, sube a repositorio y ese repositorio ahí tiene todos los cambios. Pero tú puedes hacer, que es lo que nosotros y en la guía que os dejaré en la URL, podremos hacer un flujo para que eso directamente se suba a la página web. Y, en definitiva, tú cuando estás trabajando en local, edites, registres y hagas push, automáticamente se suba a la página web. Entonces, yo normalmente como trabajo es que edito código, guardo, registro, voy haciendo registros y cuando veo que el código ya está estable y ya funciona bien en local, pues un lago push y subo. Entonces, eso automáticamente, por FTP, se sube. Hay varias formas de hacer despliegue que, bueno, en definitiva puede utilizar varias. A mí, personalmente, la que más me gusta es las de que están en el propio servidor, porque se alimentan de ese repositorio que tenemos ahí guardado y, automáticamente, se despliegan a la página web. Hay distintas versiones. Esta es la de Plasonic, la de Siteground también tiene. Otra menos recomendable que el Kit FTP, que lo que hace es que cuando tú has registrado los cambios tú le dices Kit FTP, push. Entonces, automáticamente, todo lo que hayas cambiado si has borrado archivos, si has cambiado el código, lo subes. Tú no tienes que estar en FTP viendo que acordarte que archivo ya había cambiado o deja varios archivos de registro total. Con Kit FTP es una versión que es más manual porque te crea otro paso más, pero bueno, dentro de cabez es mucho mejor que con este proceso de trabajo. Luego, tenemos también Bitback and Pipelines y también tiene GitHub Actions que el propio repositorio le da una serie de comandos y tú puedas hacer el despliegue desde el propio servidor del repositorio. Y luego hay servicio externo que cuando antes no estaban los del propio servidor yo utilizaba mucho servicio externo y bueno, para ahí también plana de pago y te puedas hacer también despliegue más complicados cuando hay verificaciones de código, etcétera. En definitiva, pues, hay distintas opciones, estas son las más las que yo conozco mejor y os comento. Importante, cuando hacemos un repositorio y guardamos el código muy importante es no poner programaciones externas o de terceros. Es decir, yo el novato al principio metía en mi Kit metía el Wordpress entero o sea, metía el Wordpress en repositorio y todos los plugins. Cada vez que actualizaba el local algún plugin o actualizaba el mismo Wordpress me salían una actuación de no sé cuántos archivos. Claro, eso es, vamos, que no pueden hacer ni seguimiento de lo que has hecho. Yo he pagado eso en novato. Entonces, lo que hacemos es que os dejaré en la guía también un GitHub que yo utilizo para un tema de Wordpress en el que todo lo ignora y sólo lleva el seguimiento del código en Mooplugins, cuando yo utilizo Mooplugin para poner los post types y temas o temas hijos para hacer las verificaciones. Entonces, os recomiendo eso, que no pongáis nada de terceros. Aquí tenéis una guía, evidentemente, por el tiempo que tenemos, pero básicamente en diez pasos podéis hacer el despliegue del Play on in a Bitbacker, también puedes hacer con GitHub, no hay problema, el que más recomiendo hay otra opción, también a través de SiteGroundGit que también da una opción, que tú si le manda el repositorio al que ellos te dan directamente lo subes y se despliega directamente a la página web y por Git FTP tenemos también que tú le ponen el acceso de FTP, el username y el pass, para que haya servicios que a lo mejor a mí me pasa, que lo sigo utilizando porque hay servidores que no tienen el despliegue directamente, por lo que hago es que le pongo Git FTP y bueno, aunque me quiera un plazo más manual, pero ya el flujo de trabajo lo tengo ya planteado, le hago un Git FTP init que lo que hace es que sube por primera vez todos los archivos de tu repositorio al FTP que tú lo has dado le hace un Git FTP push cada vez que va haciendo cambios y registros y finalmente pues eso, que os quedes muy claro que es una forma muy buena de trabajar que para hacer temas y plugins de WordPress, es lo mejor trabajar en local, trabajar con el control de versiones por lo que decía, porque pueda hacer un histórico porque es muy seguro, porque pueda trabajar realmente en equipo, trabajar varias personas sobre el mismo código y finalmente, hacer un flujo de despliegue que el que más se adapta a vosotros, según el servidor que tengáis contratado, si también por precedencia personal, si querés hacer alguna cosa hacer un flujo de despliegue que directamente cuando nosotros hagamos una edición de código hagamos algún cambio, lo registremos un Git FTPush directamente se despliegue en el servidor y con eso te ahorran muchísimo tiempo, tú trabajas tranquilamente en local, con todos los repositores que tú tienes trabajando y directamente lo tienes despliegado puedes hacer despliegue de un mismo repositorio en muchos sitios, yo a lo mejor tengo un plugin de prueba y lo puedo hacer despliegar en varias servidores, así que en definitiva pues bueno, que os recomiendo esta opción y que ahora me tenéis en el happiness bar si tenéis alguna duda o como lo hago yo os enseño cómo funciona pues muchas gracias