Duda al hacer Deploy

[coderyoruga]

Buenas, estoy trabajando en un proyecto web el cual estoy cuando lo subo a un repositorio GitHub hay un archivo en el cual se encuentran datos como por ejemplo de acceso a la BD. Este archivo este no lo subo al repositorio, (esto lo indico en .gitignore).
La pregunta puntual es cual sería la manera mas conveniente subirlo cuando toca modificarlo para no tener que hacerlo de manera manual desde el administrador de archivos del hosting, y teniendo en cuenta que al repositorio no se sube.

Cabe aclarar que desde el hosting siempre utilizo Git Pull desde una terminal.

Se que hacerlo de manera manual sería lo mas sencillo, pero imagino que hoy en día en equipos de trabajo se debe hacer de otra manera.

[Thalios]

Cada uno tiene una copia local de la db? porque no debería cambiar sino.

En un principio lo dejaría en el gitignore y que lo actualice un responsable cuando corresponda

[Master of the Wind]

Me pincharon por la cucaracha, y vuelvo a dejar un par de aportes en topics que valen la pena, ya que los politicamente correcto no aparecen en estos threads. No sirven para nada. Vuelvo a escribir por ellos, para demostrarles lo inutiles que son, porque por lo que veo desde el bardo que se armo, mas de uno no volvio a escribir una letra siquiera.


En tu caso, no tenes otra que hacerlo manual.


Ahora, lo mejor que puodes hacer es usar Github Actions. No es dificil de configurar.

Con eso podes lograr tres cosas: primero que al pushear a una rama puntual, puedas disparar acciones determinadas para ramas especificas, por ejemplo, que al pushear a master, se conecte al servidor y haga un git pull donde este el deployment de esa rama.

Lo otro que ganas, es que en el repo podes poner variables. Con esas variables (por ejemplo, credenciales de la DB), podes tener el archivo de config en el repo (lo que se suele hacer, ponele que se llame config, guardas config.example), sin valores asignados, y con un script de bash en las actions haces que en cada deployment se borre ese archivo y se genere de nuevo con los valores correspondientes. Con esto tenes en github mismo esos datos y no dependes de un ser humano. Si cambias los valores de las credenciales, simplemente ejecutas las actions nuevamente de forma manual y listo. Si el codigo no cambio, el git pull no te va a tocar nada, pero si vas a tener actualizado el archivo de configuracion.

Por ultimo, las Actions tienen un dashboard de reportes en Github, entonces cada vez que se ejecuten vas a tener un detalle de que commits/ramas se estan trabajando, el resultado de las actions, si algo fallo, no fallo, que te mande un reporte, etc.


Yo hace tiempo que no dejo nada manual. No hay peor cosa que depender de un ser humano, asi sea uno mismo.

[SEndero Luminoso]

@Master of the Wind

[coderyoruga]

Cada uno tiene una copia local de la db? porque no debería cambiar sino.

En un principio lo dejaría en el gitignore y que lo actualice un responsable cuando corresponda

Este proyecto lo estoy haciendo solo, de todas maneras era mas que nada para ir agarrándole la mano al tema.

Me pincharon por la cucaracha, y vuelvo a dejar un par de aportes en topics que valen la pena, ya que los politicamente correcto no aparecen en estos threads. No sirven para nada. Vuelvo a escribir por ellos, para demostrarles lo inutiles que son, porque por lo que veo desde el bardo que se armo, mas de uno no volvio a escribir una letra siquiera.

No entendí si fué por el topic o por algo que no entendí jajaja

En tu caso, no tenes otra que hacerlo manual.


Ahora, lo mejor que puodes hacer es usar Github Actions. No es dificil de configurar.

Con eso podes lograr tres cosas: primero que al pushear a una rama puntual, puedas disparar acciones determinadas para ramas especificas, por ejemplo, que al pushear a master, se conecte al servidor y haga un git pull donde este el deployment de esa rama.

Lo otro que ganas, es que en el repo podes poner variables. Con esas variables (por ejemplo, credenciales de la DB), podes tener el archivo de config en el repo (lo que se suele hacer, ponele que se llame config, guardas config.example), sin valores asignados, y con un script de bash en las actions haces que en cada deployment se borre ese archivo y se genere de nuevo con los valores correspondientes. Con esto tenes en github mismo esos datos y no dependes de un ser humano. Si cambias los valores de las credenciales, simplemente ejecutas las actions nuevamente de forma manual y listo. Si el codigo no cambio, el git pull no te va a tocar nada, pero si vas a tener actualizado el archivo de configuracion.

Por ultimo, las Actions tienen un dashboard de reportes en Github, entonces cada vez que se ejecuten vas a tener un detalle de que commits/ramas se estan trabajando, el resultado de las actions, si algo fallo, no fallo, que te mande un reporte, etc.


Yo hace tiempo que no dejo nada manual. No hay peor cosa que depender de un ser humano, asi sea uno mismo.

Paaahhh, me falta aprender pila de GitHub aún, ya tengo una idea por donde va la cosa al menos y como buscar. Gracias

[Everybody]

Pero si la idea era no subir credenciales al repo, tenerlo en github actions es casi lo mismo, no?
Alguien con acceso al repo va a poder obtener esa data, o me perdí de algo?

[coderyoruga]

Pero si la idea era no subir credenciales al repo, tenerlo en github actions es casi lo mismo, no?
Alguien con acceso al repo va a poder obtener esa data, o me perdí de algo?

Mmm es verdad. Voy a seguir el topic porque como verán soy nuevo en esto, mientras tanto seguiré buscando algún curso al respecto.

[Master of the Wind]

Lo que NO se puede hacer es versionar credenciales, primero porque quedan como texto plano en el repo por seguridad, y segundo porque las credenciales no son codigo de la aplicacion, sino que son configuraciones de entorno. Eso no se versiona en un repo.



Ahora, vos en el repo si las metes como variables son algo aparte del codigo fuente, en el caso de github, si bien se guardan como un archivo de config especial dentro del proyecto, no es que esta metido en el codigo, e incluso podes configurar que se omita en los clone si no me equivoco.

Ademas, vos podes meter variables sensibles (que en Github se llaman Secrets) y se almacenan encriptadas. Salvo en el momento que las usas en los Actions, en la interfaz de Github nadie puede volver a ver su valor original desde la interfaz de Gitlab, que hasta de hecho, todas las variables que quieras usar las podes almacenar de esta forma.

[coderyoruga]

Lo que NO se puede hacer es versionar credenciales, primero porque quedan como texto plano en el repo por seguridad, y segundo porque las credenciales no son codigo de la aplicacion, sino que son configuraciones de entorno. Eso no se versiona en un repo.



Ahora, vos en el repo si las metes como variables son algo aparte del codigo fuente, en el caso de github, si bien se guardan como un archivo de config especial dentro del proyecto, no es que esta metido en el codigo, e incluso podes configurar que se omita en los clone si no me equivoco.

Ademas, vos podes meter variables sensibles (que en Github se llaman Secrets) y se almacenan encriptadas. Salvo en el momento que las usas en los Actions, en la interfaz de Github nadie puede volver a ver su valor original desde la interfaz de Gitlab, que hasta de hecho, todas las variables que quieras usar las podes almacenar de esta forma.

¿Te puedo consultar donde se puede aprender todo eso?, se que hay mucho curso a la vuelta, pero mas o menos para ir a algo confiable. Ya que en lo que me queda del Bachillerato de Informática dudo que se den estos temas...

[Everybody]

Ademas, vos podes meter variables sensibles (que en Github se llaman Secrets) y se almacenan encriptadas. Salvo en el momento que las usas en los Actions, en la interfaz de Github nadie puede volver a ver su valor original desde la interfaz de Gitlab, que hasta de hecho, todas las variables que quieras usar las podes almacenar de esta forma.

Ahora tiene mas sentido, no conocia los Secrets.

en la interfaz de Github nadie puede volver a ver su valor original desde la interfaz de Gitlab

Y no, como vas a ver desde Gitlab las variables de Github

[BloodElf]

[...] sino que son configuraciones de entorno. Eso no se versiona en un repo.

A menos que el repo sea de la configuracion de entorno ajajaj

[mbr386]

Me pincharon por la cucaracha, y vuelvo a dejar un par de aportes en topics que valen la pena, ya que los politicamente correcto no aparecen en estos threads. No sirven para nada. Vuelvo a escribir por ellos, para demostrarles lo inutiles que son, porque por lo que veo desde el bardo que se armo, mas de uno no volvio a escribir una letra siquiera.


En tu caso, no tenes otra que hacerlo manual.


Ahora, lo mejor que puodes hacer es usar Github Actions. No es dificil de configurar.

Con eso podes lograr tres cosas: primero que al pushear a una rama puntual, puedas disparar acciones determinadas para ramas especificas, por ejemplo, que al pushear a master, se conecte al servidor y haga un git pull donde este el deployment de esa rama.

Lo otro que ganas, es que en el repo podes poner variables. Con esas variables (por ejemplo, credenciales de la DB), podes tener el archivo de config en el repo (lo que se suele hacer, ponele que se llame config, guardas config.example), sin valores asignados, y con un script de bash en las actions haces que en cada deployment se borre ese archivo y se genere de nuevo con los valores correspondientes. Con esto tenes en github mismo esos datos y no dependes de un ser humano. Si cambias los valores de las credenciales, simplemente ejecutas las actions nuevamente de forma manual y listo. Si el codigo no cambio, el git pull no te va a tocar nada, pero si vas a tener actualizado el archivo de configuracion.

Por ultimo, las Actions tienen un dashboard de reportes en Github, entonces cada vez que se ejecuten vas a tener un detalle de que commits/ramas se estan trabajando, el resultado de las actions, si algo fallo, no fallo, que te mande un reporte, etc.


Yo hace tiempo que no dejo nada manual. No hay peor cosa que depender de un ser humano, asi sea uno mismo.

Parece interesante, inclusive si no me quedo claro del todo (voy a googlear). Lo que si entendí con una búsqueda rápida es que parece que no hay un similar en gitlab (al menos lo que encontré).

[Master of the Wind]

Parece interesante, inclusive si no me quedo claro del todo (voy a googlear). Lo que si entendí con una búsqueda rápida es que parece que no hay un similar en gitlab (al menos lo que encontré).

En Gitlab lo tenes, por cada repo se configura en la parte de CI/CD de cada repo. De hecho, los Actions en Github son bastante nuevos, el Gitlab y Bitbucket esta hace muchisimo mas, antes si tenias todo en Github, tenias que tener una herramienta como Travis, Jenikins o CircleCI integrado a Github, sino no tenias otra forma.

Incluso, respondiendo a Everybody, me confundi ahi, quise decir Github en vez de Gitlab, porque en el laburo por muchisimo tiempo (del 2016 hasta este año) todo esto lo haciamos con Gitlab. Ahora pasamos a usar Bitbucket, primero porque Gitlab estaba autohosteado y estaba cansado de mantenerlo y queria algo que este en la nube, y segundo porque tiene integracion con Jira que lo usamos mucho.

A menos que el repo sea de la configuracion de entorno ajajaj

Mugriento barbaro. Cosa de negre

¿Te puedo consultar donde se puede aprender todo eso?, se que hay mucho curso a la vuelta, pero mas o menos para ir a algo confiable. Ya que en lo que me queda del Bachillerato de Informática dudo que se den estos temas...

Porque no me tuviste a mi de docente jeje, yo enseño estas cosas de DevOps porque se que el mundo va para ahi.

Cursos ni idea, no soy muy de meter cursos. Yo aprendi viendo documentaciones oficiales, mucho stack overflow y algun video en youtube, despues todo metiendo mano. Tambien, ahora hay una ventaja que es que esta todo mucho mas cocido. Yo llevo 4 años de ingeniero DevOps, cuando empece con esto todo estaba muy verde, sobretodo el tema de Docker y Kubernetes, y podias meter investigar toda la mano que quieras, pero dependia mucho del boca a boca. Por ejemplo, yo me miraba todas las conferencias que empezaron a haber del tema para ver experiencia de otras personas para perfeccionar, y en un momento en el laburo contrataron una empresa (NetLabs, unas bestias) para darnos una mano con una migracion de base de datos, y conversando con los locos les dije que habia empezado con el tema de DevOps, y se colgaron a darme tremenda mano y compartirme mucha de su experiencia.

Ahora encontras todo muuuucho mas digerido y uniforme. Tenes cursos en udemy, tutoriales enormes en youtube, etc (hasta yo enseñandolo en la UTU jeje). Pero, una dificultad que tiene, es que es un rol para el que necesitas tanto conocimientos de infra, servidores, como de desarrollo, un poco de todo. Si sos un desarrollador que sube el codigo a un repo y se desentiende, o un sysadmin que considera que el servidor es una caja negra que lo que corre adentro no le importa, es un poco mas jodido agarrarle la mano.

Lo bueno que todo lo que es DevOps es relativamente nuevo, y es mas un set de practicas, formas de pensar y disciplina, que tecnologias, entonces aprendiendo las metodologias despues con cualquier herramienta, que hay miles estas del otro lado.


Buscate un canal en Youtube, de Pelado Nerd, que es un DevOps/SRE (lo mismo practicamente), que la rompe y habla mucho del tema, explica muy bien, y toca bastantes cosas interesantes. El tipo tiene mucha experiencia en el tema, y se enfoca en gente que no sabe, no es que te habla en chino. Obviamente, tenes que seguir el hilo de algunos videos para entender ciertas cosas, pero te lo aclara en cada video cuales tenes que ver antes, y son videos cortos, ninguno llega a los 15 minutos creo.

Por otro lado, si te dan las bolas, y queres aprender MUCHISIMO de deployments, hay un video de un ingeniero de Red Hat que esta tremendo: https://www.youtube.com/watch?v=ZpbXSdzp_vo

Si, esta en ingles, y dura 3 PUTAS HORAS, pero te muestra como hacer todo lo basico con contenedores y deployment de apps en contenedores con Kubernetes bien facil, se te pasan volando las 3 hs, y todo lo que muestra ahi lo comparte en un repo de Github bien explicado.


Como tambien te dije, te recomiendo que metas mucho docker, primero porque la industria esta fuerte ahi hace tiempo y no hace mas que instaurarse con mas fuerza, y segundo, porque tambien porque esta cambiando el rol del desarrollador fuerte. Antes era un tipo que solo escribia codigo, ahora se pretende que el desarrollador tenga responsabilidad no solo sobre su codigo, sino en donde se ejecuta, y es normal que el tema de crear el contenedor* sea responsabilidad del desarrollador y no de la gente de sistemas/DevOps, un desarrollador tiene que saber en que entorno TIENE que correr su codigo, que librerias necesita, y como configurar el contenedor para que todo eso aplique.


Cualquier cosa tirame MP (vos o cualquiera), estoy en un momento de mi vida que ayudo al que venga con esto, trato de que esta "cultura" y disciplinas se extiendan, estoy podrido de que la mayoria de las empresas y empleados del sector IT en Uruguay sigan viviendo en los 2000.

Hay muchas cosas como DevOps, enfasis fuerte en Clean Code, o considerar lo imprescindible que es la arquitectura de software, y que es mas necesario tener un arquitecto de software en lugar de 50 testers que las planteas e incluso se te rien en la cara.

De hecho, cuando empezo la pandemia, la primer semana que no estaba dando clase porque se estaba resolviendo que se hacia en la educacion, abri un canal de discord, lo publique en facebook, y luego de las 18 que terminaba de trabajar se metia bastante gente y me dedicaba por unas 3 hs a explicar y enseñar estas cosas (que tengo pensasdo revivir eso, o capaz que me hago el youtuber y armo un canal).


* por si no lo manejas mucho, un contenedor es como una maquina virtual, pero muchiiiiiiiiisimo mas liviana, y que se construye con codigo.

[Turco]

y yo pensando que era algo del battlefield o call of duty

[coderyoruga]

En Gitlab lo tenes, por cada repo se configura en la parte de CI/CD de cada repo. De hecho, los Actions en Github son bastante nuevos, el Gitlab y Bitbucket esta hace muchisimo mas, antes si tenias todo en Github, tenias que tener una herramienta como Travis, Jenikins o CircleCI integrado a Github, sino no tenias otra forma.

Incluso, respondiendo a Everybody, me confundi ahi, quise decir Github en vez de Gitlab, porque en el laburo por muchisimo tiempo (del 2016 hasta este año) todo esto lo haciamos con Gitlab. Ahora pasamos a usar Bitbucket, primero porque Gitlab estaba autohosteado y estaba cansado de mantenerlo y queria algo que este en la nube, y segundo porque tiene integracion con Jira que lo usamos mucho.



Mugriento barbaro. Cosa de negre



Porque no me tuviste a mi de docente jeje, yo enseño estas cosas de DevOps porque se que el mundo va para ahi.

Cursos ni idea, no soy muy de meter cursos. Yo aprendi viendo documentaciones oficiales, mucho stack overflow y algun video en youtube, despues todo metiendo mano. Tambien, ahora hay una ventaja que es que esta todo mucho mas cocido. Yo llevo 4 años de ingeniero DevOps, cuando empece con esto todo estaba muy verde, sobretodo el tema de Docker y Kubernetes, y podias meter investigar toda la mano que quieras, pero dependia mucho del boca a boca. Por ejemplo, yo me miraba todas las conferencias que empezaron a haber del tema para ver experiencia de otras personas para perfeccionar, y en un momento en el laburo contrataron una empresa (NetLabs, unas bestias) para darnos una mano con una migracion de base de datos, y conversando con los locos les dije que habia empezado con el tema de DevOps, y se colgaron a darme tremenda mano y compartirme mucha de su experiencia.

Ahora encontras todo muuuucho mas digerido y uniforme. Tenes cursos en udemy, tutoriales enormes en youtube, etc (hasta yo enseñandolo en la UTU jeje). Pero, una dificultad que tiene, es que es un rol para el que necesitas tanto conocimientos de infra, servidores, como de desarrollo, un poco de todo. Si sos un desarrollador que sube el codigo a un repo y se desentiende, o un sysadmin que considera que el servidor es una caja negra que lo que corre adentro no le importa, es un poco mas jodido agarrarle la mano.

Lo bueno que todo lo que es DevOps es relativamente nuevo, y es mas un set de practicas, formas de pensar y disciplina, que tecnologias, entonces aprendiendo las metodologias despues con cualquier herramienta, que hay miles estas del otro lado.


Buscate un canal en Youtube, de Pelado Nerd, que es un DevOps/SRE (lo mismo practicamente), que la rompe y habla mucho del tema, explica muy bien, y toca bastantes cosas interesantes. El tipo tiene mucha experiencia en el tema, y se enfoca en gente que no sabe, no es que te habla en chino. Obviamente, tenes que seguir el hilo de algunos videos para entender ciertas cosas, pero te lo aclara en cada video cuales tenes que ver antes, y son videos cortos, ninguno llega a los 15 minutos creo.

Por otro lado, si te dan las bolas, y queres aprender MUCHISIMO de deployments, hay un video de un ingeniero de Red Hat que esta tremendo: https://www.youtube.com/watch?v=ZpbXSdzp_vo

Si, esta en ingles, y dura 3 PUTAS HORAS, pero te muestra como hacer todo lo basico con contenedores y deployment de apps en contenedores con Kubernetes bien facil, se te pasan volando las 3 hs, y todo lo que muestra ahi lo comparte en un repo de Github bien explicado.


Como tambien te dije, te recomiendo que metas mucho docker, primero porque la industria esta fuerte ahi hace tiempo y no hace mas que instaurarse con mas fuerza, y segundo, porque tambien porque esta cambiando el rol del desarrollador fuerte. Antes era un tipo que solo escribia codigo, ahora se pretende que el desarrollador tenga responsabilidad no solo sobre su codigo, sino en donde se ejecuta, y es normal que el tema de crear el contenedor* sea responsabilidad del desarrollador y no de la gente de sistemas/DevOps, un desarrollador tiene que saber en que entorno TIENE que correr su codigo, que librerias necesita, y como configurar el contenedor para que todo eso aplique.


Cualquier cosa tirame MP (vos o cualquiera), estoy en un momento de mi vida que ayudo al que venga con esto, trato de que esta "cultura" y disciplinas se extiendan, estoy podrido de que la mayoria de las empresas y empleados del sector IT en Uruguay sigan viviendo en los 2000.

Hay muchas cosas como DevOps, enfasis fuerte en Clean Code, o considerar lo imprescindible que es la arquitectura de software, y que es mas necesario tener un arquitecto de software en lugar de 50 testers que las planteas e incluso se te rien en la cara.

De hecho, cuando empezo la pandemia, la primer semana que no estaba dando clase porque se estaba resolviendo que se hacia en la educacion, abri un canal de discord, lo publique en facebook, y luego de las 18 que terminaba de trabajar se metia bastante gente y me dedicaba por unas 3 hs a explicar y enseñar estas cosas (que tengo pensasdo revivir eso, o capaz que me hago el youtuber y armo un canal).


* por si no lo manejas mucho, un contenedor es como una maquina virtual, pero muchiiiiiiiiisimo mas liviana, y que se construye con codigo.

Paaah!!, y yo contento por estar aprendiendo a manejar Codeigniter jajaja.. ahora ya se por que no me llaman de los laburos
Metele al canal de Youtube

Voy a aprovechar el Verano a meterle a eso.

[Rogmaniacs]

master me encanta que te guste el bardoo vos no seras hincha de nacional? pasame algun canal, tu discord o algo quee estoy trabajando en una empresa con 3 desarolladores yo soy el sysadmin y hace pila de temas que te vengo leyendo en silencio y me interesa aprender tambien.
para aportaar al tema lo unico que diria es que no gastaria plata en ninguna clase de curso que exista en la fazz de la tierra con el vendito youtube en la vuelta ahi se encuentra todoo

saludos