 A continuación voy a presentar a Marco Ruso, que es una persona de perfil técnico que vive en la consola, la conoce muy bien, tiene un manejo de la consola brutal en cuanto a herramientas de despliegue y integración continua domina bastante, es muy buen técnico, es compañero mío de trabajo actualmente y os aseguro que os va a gustar la ponencia, ¿vale? Y más os dejo con Marco y que empiece. Bueno, muchas tardes, muchas gracias, buenas tardes. Mi nombre es Marco Ruso, trabajo con algunas, se oye, de las personas que están actualmente, trabajamos en una empresa en la Unión. Mi trabajo actualmente es que soy el líder técnico, no decido qué hay que hacer, pero sí cómo. Entonces, otras personas deciden qué hay que hacer y yo, pues, según las tecnologías o el proyecto que tengamos, pues, decide más o menos qué hay que hacer. Soy de PHP, estoy con PHP de 2001 y otras tecnologías, pero básicamente, pues, PHP. Y hoy voy a hablar de KIT. Ok. En principio, pues, es un sistema de control de versiones, segundo. Para saber esto, os voy a explicar qué es un sistema de control de versiones. Es un servicio o un software que nos permite volver el tiempo en un desarrollo, el que sea. Puede ser incluso algún diseñador que tenga unas imágenes o está haciendo alguna plantillas o algo y quiera ver en el tiempo, como ha ido el progreso, de esos cambios, por si en algún momento necesita volver a algún lugar específico y cambiar algo. Pero realmente es la función o el poder de lo que sea un sistema de control de versiones. Anteriormente, las empresas inconscientemente hacían esto, guardando todo por carpetas y le ponían los años y, dentro de las carpetas con años, pues, tenían meses y iban guardando todos sus documentos de esa forma. Si tenían que revisar tal vez algún contrato de trabajo de cómo se hacían en el 2004 en la fecha de junio, pues, navegaban por las carpetas, llegaban hasta ese lugar y veían la diferencia con lo que tienen ahora. Lo único que luego salieron software que se encargan de hacer todo esto sin necesidad de que nadie lo está haciendo manualmente. Entonces, Git es un sistema de control de versiones. Es el más popular actualmente. Hay otros que están al mismo nivel de Git, pero vamos a hablar hoy de Git únicamente. OK, ¿para qué nos sirve Git? Pongamos un ejemplo. Tenemos un software o el mismo WordPress o el mismo desarrollo de lo que es el frango o la herramienta de WordPress. Ellos van llevando todos los cambios de todas las personas y Git puede almacenar todos esos cambios para, me equivocé, para precisamente poder en algún momento volver a actualizar esa parte. Ahora, existen tres tipos de sistema de control de versiones. Tenemos el tipo de versión que sería local, donde tenemos un proyecto en nuestra máquina local y vamos guardando todos los cambios que vamos haciendo a medida que vaya a recorrer. Al estar en nuestra máquina, pues, no podemos compartirlo con nadie. Si quisiéramos compartirlo, habría que darle una copia de esto y ya sería algo, cada quien tendría su propia copia, pero no podríamos sincronizarlas. Esto sería, pues, un versionado local. Un versionado centralizado, que es con el que funcionan casi todos los sistemas de control de versiones, que existe en algún lugar, un servidor propiamente, un repositorio principal. Y todas las personas que están en el proyecto, pues, hacen copia de eso. Una vez que tienen esos cambios listos, los suben a ese servidor. Y todos contenemos los mismos cambios en nuestras máquinas, por así decirlo. Y el tercero, que es el que utiliza Git y otro sistema, es que el repositorio no necesariamente tiene que estar ubicado en un sitio específico. Si por casualidad el servidor principal tuviese un fallo y se rompiera o se cayera, pues el resto puede seguir trabajando entre ellos o asignar a cualquiera de las personas como principal, hasta que el servidor vuelva a estar en funcionamiento. Y luego otra vez, todas las copias volverían al servidor principal. Es una de las grandes ventajas. Incluso, estando el servidor activo, yo no necesitaría ir hasta él o que otra persona haya hecho su cambio o lo suba el servidor, puedo yo directamente pedir el cambio a su repositorio, desde su máquina. Y en algún momento, pues, se sincronizará con el servidor principal. De bueno, hasta el esquema de cómo sería este caso. Ahora, Git lo podemos tener en nuestra máquina local, en un servidor propio, o podemos utilizar algunos de los servidores existentes que prestan el servicio para que almacenes tu proyecto de Git. Está GitLab, que es una herramienta que podéis instalar en vuestros servidores, la versión típica, la versión gratuita y la versión de pago que tienen funcionarias hechuras. Él permite tener todo el control de todo el repositorio, de todas las personas que las están subiendo. Luego, hasta Bitbucket, que también es muy potente y muy poderoso, se utiliza mucho para desarrollos de software. Problema con ellos, que tiene que ser en sus servidores. Y hay empresas que no quieren compartir su código, pasa. Y luego tenemos a GitHub, que es el más popular de los primeros y realmente es una herramienta muy robusta. Problema también, hay que subir el código a su servidor, pero tiene dos modalidades. La que no es de pago, es la que tu código queda libre, porque es software libre lo que hacemos y todo el mundo lo puede ver. Y una versión de pago para mantener tu código privado. Igual, el código no está en la empresa, sino que estaría en el servidor de ellos. Pero bueno, son tres herramientas muy buenas. Hay más, pero estas son los mejores actualmente. Git, o por lo menos yo lo suelo trabajar desde línea de comandos. Es un costumbre. Tenes tu línea, escribes tus cosas, haces tus cambios, entiendes lo que, el montón de cosas que te dice Git. Y la subes. Pero también hay entornográficos. Por lo menos está Git Kraken, que es cojonulísimo, es súper chulo. De las ventanitas redondeadas, que eso es brutal. Luego está Git Station, Smart Git, Git Hub, Git K, Git G. El propio Git tiene uno que se llama Git K, que es simplemente poder ver la relación de lo que está hecho en Git. Con comentarios que también vamos a ver a futuro que son. Y bueno, son herramientas que a nivel visual son muy útiles, porque me permite ver quién ha hecho, qué, en qué momento y dónde. Para típico, para escoger el teléfono. Oye, tío, ¿qué has hecho? No, que no fui yo, que sí. Son herramientas muy poderosas. Ahora, la pregunta, ¿hay un plugin para WordPress? Claro, es una WorkCamp. Entonces, pillé el primero que encontré, ¿vale? Y lo instalé y funcionó la primera, así que, guay. ¿Qué hace este plugin? Bueno, si hacemos algún cambio dentro de nuestro WordPress, ejemplo, instaló un plugin, otro plugin y lo guardo. Él me va a detectar los cambios a nivel de archivos. Si hace algún PHP nuevo, un CSS, un JS, cualquier cosa, va a detectar el cambio. Trae una funcionalidad que, honestamente no he probado, pero si funciona sería la leche, que es actualizar las bases de datos, o sea, mantener un respaldo de las bases de datos. En la empresa de nosotros, esto no funcionaría la base de datos, pesas y gigas. No, pero con páginas más, con menos contenido, pues tal vez funcionaría muy bien. Porque agregan a ellos esta funcionalidad. WordPress tendrá a guardar todas las páginas y guardarlo todo en bases de datos. Así que, aunque yo respalde el código, si no he activado el plugin, no me sirve nada. Porque eso se guarda en base de datos. Este plugin permite guardarlo también. Y hacer copias exactas de esa funcionalidad. ¿Cómo puedo yo o qué beneficio puedo yo tener de esto? Supongamos, en el mismo caso, instalo un plugin. Funciona según lo esperado, mal. Pero decido probarlo en producción. Hago el cambio en mi local, hago un commit, lo envío. Aquí ya intervendrían otras herramientas, pero en el lado del servidor perfectamente podría tener algo que despliegue ese código en nuestro servidor de producción. Resulta que ahí, pues, peta todo. No solo el error que nosotros teníamos. Aquí es donde viene realmente el poder de un sistema de control de versiones. Yo tengo que poder descagarla de manera rápida, porque eso está en producción. Y la gente no lo ve. Yo debería poder decir, vale, quiero volver a la versión anterior estable y que él actualice los códigos de PHP, actualice los CSS, los JS, e incluso la base de datos que estaba en esa versión estábua. Ya tendremos tiempo de cabrear a alguien o de echarle la bronca a alguien y de corregir el error. Pero realmente esta es la funcionalidad o el poder de un subperzo. Hay quienes lo utilizan como backup. No, hay herramientas de backup que se encargan de hacerlo y lo hacen muy bien. Esto es un sistema de control de versiones. Y esto, pues, es una idea muy chula, sobre todo cuando desarrollas. Poder volver y poder probar y volver. A veces también ocurre que el entorno que tenemos en local no es igual al del servidor. Y eso mortal. Utiliza algo, resulta que la versión de PHP que está arriba no es la que tú tienes, entonces no funciona. Hay que volver. ¿Qué otras cosas puedo hacer con Git? Con Git puedo ignorar archivos. A veces hay cosas que no quiero que se tomen en cuenta. En el caso de WordPress, el WP config. Esto apunta, pero no se ve en la tele, ¿vale? Es el WP config, es el archivo donde tener la conexión de base de datos, usuario, no sé qué. Eso suele cambiar por cada entorno. No usamos el mismo usuario y no utilizamos a root. No. Entonces puedo decirle a Git, no tomes en cuenta este archivo, porque va a cambiar en el otro lugar. Entonces cuando tú despliegues o hagas cambios, esto no debes tomarlo en cuenta. Al igual que la carpeta tal vez la de Upload. Yo hago mis pruebas, subo la foto de un elefante o lo que sea para hacer mis pruebas, pero no quiero que esto se vaya al servidor de producción o que lo vean mis compañeros. Entonces yo la carpeta la ignoro. Es una de las tantas cosas que se pueden hacer con Git. Ahora, Git trabaja o todos los sistemas de control de versiones trabajan con ramas. Gracias a tu chiste de atarse por las ramas, pero me dijeron que no. Entonces sería nuestro proyecto y las ramas. Algo que deben tener las ramas es un nombre. Y en Git, por la lenguatura general, la rama principal se llama Master. Y otras ramas, pues ya dependiendo de la filosofía que se sigue en cada empresa o en cada desarrollo, tendrán unos nombres. Esto es una foto real de un proyecto en el que estoy. Y estas son las ramas que se hacen y cómo se van uniendo las ramas contra otras ramas para tener un desarrollo correcto. Serían las ramas, por lo menos Master, que sería la roja. Y otras han sido diferentes desarrollos que se han ido haciendo contra esa rama y los comentarios que va haciendo cada uno. He quitado a las personas. Entonces ahí se puede tener realmente un control de todo lo que ha ocurrido en el proyecto. Entonces, una explicación molona es la que daba Doc con el tiempo. Es precisamente eso. Las ramas son esas, son bifurcaciones que hacemos en algún momento para cambiar algo. Hablando de Git y de la peli, esta es la explicación, según ramas de Git, de todo lo que ocurrió en las tres pelis. Es un pago friki, pero mola. Vuelve, vuelve al mismo lugar, vuelve al otro lado, se vuelve a cambiar, vuelve otra vez al año anterior y está bueno. Hay determinator en Google también y de otras pelis. Aparte de esto, Git también permite crear tags, crear etiquetas. Esto es muy importante a la hora de volver precisamente en el tiempo. Tengo ejemplo versión 1, versión 0, 1. Estos han sido otros cambios que se han hecho. Supongamos que en este cambio, bueno, esta ramarroza es un hot fit, pero es lo mismo, es una ramada. Supongamos que ese cambio hay un error y no funciona. No podemos corregir el error al momento porque es realmente complicado. ¿Qué tenemos que hacer? Volver a la versión estable. Volver a lo último que funcionaba y que se veía bien. Lo que ayer estaba bien, pues, que hoy este es lo de ayer, punto. Entonces, tenemos etiquetas que nos pueden decir, mira, este punto es estable, ha funcionado, se ha probado con todo y vamos, los clientes llegan. Entonces, volveríamos a esa versión. Para eso la parte de tag es importante. Pero vamos a hablar lo que sería realmente o cómo funcionaría Git. Lo primero que tengo que hacer es clonar un repositorio. Git está en algún lugar y yo quiero agarrar una copia de lo que hay ahí. Es Git, clon y la ruta. Que nos den si tenemos un proyecto en GitHub, pues la ruta de GitHub. Y ya tendríamos en local nuestro proyecto. Para actualizar nuestro repositorio en local hacemos un pull, el comando es git pull. Con las herramientas gráficas seguramente le dicen, cobrarse un botón que dice pull, internamente hacen lo mismo. No hacen nada diferente a las herramientas gráficas al código. Y es simplemente agarrar lo que haya en ese repositorio, en ese instante, en esa rama y traerme lo a mi local. Aquí es donde hay diferencia por otros sistemas de control de versiones. Cuando nosotros, sistemas de control de versiones, aceptan un cambio, el cambio se envía al servidor. En Git no. En Git, cuando aceptamos un cambio es solo eso. Acepto ese cambio en mi máquina. Luego tengo que enviar esa información al servidor. ¿Qué sería un push? ¿Por qué se hace de esta forma? Porque alguien pudo en algún momento haber cambiado eso que yo también intente cambiar. Por equis motivo, por otro desarrollo o por lo que sea. Git revisa que la versión que está en el servidor es una copia de la que yo modifique. Si no es así, me va a decir que no. Entonces por eso tiene ese doble paso. Que a veces cuando cambias de subversión o de otro sistema control de versiones aquí, dices, oh, es que yo antes hacía un commit y ya me olvidaba. Ahora ya no. Pero es beneficioso porque es proteger realmente el código principal. Y ahora, las ramas se fusionan. Es eso realmente. Eso es un merge. Es coger dos ramas y unirlas en. Y unirlas contra algo principal. Sí, bueno. Pero para todo esto, para que todo esto funcione, debo seguir unos pasos o unas pautos. A ver, lo principal, repito, es volver, descagarla de manera eficiente. Es el principal objetivo de un control de versiones. Entonces yo debo ser ordenado. Ordenado en qué? Tal vez no en el código, ni en las carpetas, ni nada de eso, sino en la metodología que utilizo para poder volver a este punto. Tengo que ser ordenado en ese aspecto. No tiene que ver con orden de carpetas. Una habitácora descriptiva es importantísimo o que os mostré antes que salía las ramas y traía un montón de textos. Es simplemente decir qué se hizo en ese cambio. Porque no quiero abrir el código y tener que enterarme de qué hay ahí. Quiero poderle decir, hemos instalado el plugin de pasarela de pago. Why? Eso ya es algo descriptivo, una habitácora. Yo podría volver a ese punto o un punto anterior. No necesitaría saber más de eso. Y coincidencia en la metodología y filosofía de trabajo que todos trabajen igual. Hay quienes dicen, no es que yo trabajo solo en mi rama, que tiene mi nombre y no la toco. Pero otras personas, tal vez, tienen diferentes desarrollos por tickets, por algún sistema de ticket tengo lo que sea, y van creando ramas por tickets. Todos debemos trabajar de la misma forma. Siempre. Llegar un consenso entre todos, o todos en la misma rama, o todos en ramas diferentes, o diferentes formas. Eso nos va a permitir, como dije antes, volver de manera segura a un punto. Y nos permitirán, en algún momento, hacer despliegues controlados, que ya es el sueño. Hago un cambio, lo envío y eso, en algún momento, se va a desplegar en un servidor de producción y va a funcionar. Se va a poder revisar el código fuente. Eso se está utilizando mucho, sobre todo en el lado de desarrolladores, alguien suba un código fuente. Y otras dos personas revisen el código, un junior y un master. Si están de acuerdo con que la forma o la metodología de desarrollo está buena, aunque el código funcione, pues dan su visto bueno y eso se puede emergir contra una rama principal. Esto es, bueno, lo puse un poquito de extra. Git tiene una opción que se llama Cherry Peak, que es la capacidad de tomar un punto o un cambio específico de algún lugar y traérmelo a este lugar, sin tener que traerme toda esa rama. Da conflictos, tal vez no está muy visto actualmente, pero es una herramienta poderosa. Ya hemos terminado. Preguntas? Hola, buenas. Muchas gracias por tu proponencia. Me ha gustado mucho. Un tema, el tema de la base de datos. Me queda con ese tema. Es una cosa que siempre haces, si te bajas con Wordpress, pues falta esa subida, esos cambios de la base de datos. Y tú dices que se puede hacer con Git y ese plugin. El plugin tiene la opción. Tiene la opción. Git hace un par de años agregó una nomenclatura especial de ellos, que es simplemente para decirle que ese archivo es una base de datos. Y este tipo de modalidad acepta archivos de 2 gigas, 3 gigas. Bien, pero es suficiente. Sí, lo único es que Git lo trata de otra manera. No hace comparación directamente binaria, sino que lo trata de otra forma. Pero se puede hacer, ¿no? Sí, perfectamente. Tú dices que no lo has probado o...? Sí, pero con base de datos pequeños. Vale, pero funciona. Sí. Vale, pero cojo nudo, muchas gracias. Más, por favor. ¿Y más aquí? Es una curiosidad. Quería saber, bueno, no sé si estás trabajando para empresas o lo estás haciendo con algún equipo. Quería saber cuál era, porque dice que tú tienes... Hay que desarrollarlo según los métodos de la empresa, hacer los cómics, cómo hacer el desarrollo, cómo lo hacéis en vuestra empresa o cómo lo hacéis en vuestra equipo. Más o menos para entrar. ¿Qué ha tiempo? Sí, verdad. OK, a ver, hay una filosofía que tiene mucha fuerza, que se llama GitFlow. Y es una forma o una filosofía de que todos los tíquets o todos los desarrollos deben ir en ramas diferentes. La rama máster es una rama infinita en el tiempo, igual que la rama de desarrollo, pero el resto de ramas son ramas que deben morir, según esta filosofía. Estoy de acuerdo. De hecho, en la empresa empezamos a utilizar GitFlow y funcionó muy bien, un buen inicio. ¿Qué ocurre? Luego nos pusimos y comenzamos con integraciones continuas y hacer despliegues automáticos, hacer despliegues en máquinas virtuales de Docker. Y ya esta filosofía no ha llegado, principal, porque la rama, bueno, no lo tengo. La rama máster, que es infinita en el tiempo, tiene que ser segura. Y para yo poderla ser segura, tengo que protegerla y bloquearla. Nadie puede hacer un mer sobre máster, excepto la herramienta principal. Entonces, ya el GitFlow no funciona. Pero alternativa, podrás crear otra rama, que tal vez es una rama de despliegue, una rama de deploy, y que tenga unas ventanas de despliegue. Los martes a las 3 de la tarde y los jueves en la mañana. Todo lo que la gente haya probado, revisado, con pruebas unitarias y que todo funciona bien, los pueden poner en esa rama y que el despliegue se haga. Es una forma de mantener el control. Esto o todos estos temas que se tienen que pensar muy bien son para precisamente poder con un botón volver. Que hemos subido algo, que lo hemos probado mil veces, pero por lo que se ha apetado en el servidor de producción, con un botón vuelve, tío. Vuelvo a la versión anterior y ya veremos qué ha pasado. Esto es realmente lo importante. ¿Qué da tiempo para otra pregunta, si queréis? ¿Alguien se anima? Bitbucket o Github? Yo estoy usando Github. Bitbucket, por lo menos. Mola porque ellos fueron los que impulsaron la filosofía de los pull requests, que es que cada quien hace un cambio en su rama, lo sube al servidor, otras personas deben revisar el código y aceptarlo. Si lo aceptan, pues entonces se lleva a la rama máster. Si no se hace eso o dos personas no están de acuerdo, no se puede hacer eso. Fue el primero en implantarlo y está realmente muy bueno. Se puede ayudar una empresa a que tanto los junior como los máster estén muy involucrados en lo que hacemos todo sin necesidad de entender exactamente por qué está hecho cada cosa. Y, por lo menos, Github es la que lo implanta también. Genial. Sí, pero Github, para la parte de que dos personas puedan aprobarlo, tienes que pagar. La Common Edition, la principal, se trae, precisamente, aceptar los Mare requests. Le cambiaron el nombre. Te permite aceptar los Mare requests, pero alguien. No tiene esa dificultad, que es muy bueno. ¿Alguna pregunta más? Pues, bueno, si no tenéis más preguntas, podemos dar por finaliz a charla. Muchas gracias. Gracias. Antes de despedir a Marcos y por lo bien que lo ha hecho, le vamos a dar un regalito que es una camiseta de WordPress para la WorkCamp, toda tuya. Como aún quedan 10 minutos para el cambio de charla, si a alguno se le ocurra alguna pregunta, y Marcos creo que no se va a ir aquí, ¿o sí? Como no se va a ir aquí, a alguno se le ocurra alguna pregunta que levante la mano y le damos el micro, ¿vale? O sea, no sé si es muy orientado y tal, pero tengo una duda que siempre me ha carcomeo. Todos los plugins afectan el rendimiento de un WordPress. En plan, por ejemplo, si instaló el plugin este de Github, afectará el rendimiento que el usuario percibe de la carga de la página, por ejemplo, ¿vale? La integración de lo que es el código que tenemos cada uno en el ordenador y la subida producción, ahora que están todos los costings o algunos de ellos, ¿no? Y ofreciendo Gith, ¿crees que eso va a ser la norma o se va a seguir utilizando FTP para hacer la integración? Gith en casa. Me yozca los fríos, dijiste FTP y falle como que... Claro, es lo que habitualmente se autoriza. ¿Piensas que realmente hay una tendencia a ver a ese cambio? ¿Erambientas de despliegue...? Vale. ¿Erambientas de despliegue tienes Jenkins? Es de pago, pero es la mejor. No, no. Me refiero al uso de los proveedores de hosting hoy en día, que sabes que ofrece... Ah, para subir directamente... Claro, para subir directamente... Hombre, yo creo que si lo hacen con Github es una gran ventaja. O sea, tú haces tus cambios en local, lo envías a GitHub y en tu proveedor le dices, actualiza la copia y que él vaya a GitHub y pille la rama master, le da lo correcto y la ponga en el lugar. Yo creo que si van por ese camino es el correcto. Gracias. Buenas. En cuanto al versionado de la base de datos, ¿cuando hacéis el versionado que hacéis la copia de la base de datos? No lo hacemos. O sea, o lo versionado... Se puede hacer, pero no lo hacemos. Si tuvieres que hacer una versión de la base de datos, ¿qué lo haces por copia directa o por algún archivo en plan de configuración, plan IML o algo así? No sería el SQL... La seca, ¿no? Lo que es la copia... El Tom de la base de datos. Puedes hacerte dos, que sería estructura y datos, pero... Sí. Vale, vale. Serías. ¿Alguna pregunta más? Bueno, muchas gracias a todos. Gracias.