Difiero en lo que dices de CI/CD. Porque se pierde el standard, construir un buen pipeline requiere de varios team, como networking, seguridad, dev, sre... A parte de un tema de credenciales sensibles que requiere un manejo de secretos y un buen almacen de credenciales. Mas en un cluster productivo. Construir una buena estrategia de deploy, canary, blue green, una buena estratrgia rollback etc... un conjunto de ambientes como dev, stage, prod... hacer las pruebas de pentesting etc... lleva tiempo... quizas cuando trabajas por proyecto puedas tener esa capacidad de construir pipeline sencillos. Pero una empresa un poco mas grande que ofrezca producto, es bueno contar con un pipeline centralizado. El trabajo DevOps es facilitar y agilizar el proceso de desarrollo mediante la automatizacion para mejorar el time to market y entregar valor comercial... no creo que sea conveniente sobrecargar al equipo de desarrollo con este tipo de cosas que se pueden automatizar y ser stardard. Que con solo un template en su proyecto o un solo archivo .yaml pueda configurar todo lo necesario para su proyecto. Como cpu, memoria, path ingress, variables de entorno, etc... con solo key/value. De igual forma ellos pueden interactuar con la infra desde su pipeline y tener el ownership, De esa manera es donde se logra que el equipo de desarrollo se enfoque en lo que realmente sabe hacer, que es construir software de calidad. No me parece que los devs tengan que aprender cualquier tecnologia que este hoy de moda como kubernetes, terraform etc. Eso tiene que ser transparente para ellos. Necesitamos mas especialistas y no un poquito de cada cosa.
Debo admitir que teniendo al dueño del canal como una persona que sabe de lo que habla, consideré fuertemente lo que menciona... Pero visto el CI/CD desde esta perspectiva, en realidad tiene mucho sentido. Aunque también es cierto que cuando se trabaja en múltiples proyectos, se aprende a hacer de todo un poco. Esto es solo la perspectiva de un backend que sabe hacer despliegues sencillos.
Con más de 13 años de experiencia entre ser desarrollador senior y DevOps manager, liderando proyectos grandes y reales en empresas de producto y consultoras, concuerdo completamente con este comentario.
Te imaginas haciendo un pipeline por proyecto, los desarrolladores montando pruebas estáticas, pruebas de seguridad, manejo de versiones, rollbacks, monitoreo y demás. Un devops potencia el trabajo de desarrolladores y sre.
En una start-up de pocos desarrolladores, puedes tener razón… En una empresa grande como puede ser un banco por ejemplo, con muchas decenas de desarrolladores, varios departamentos, tecnologías, aplicaciones, etc el ci/cd tiene que ir hacia un standard y tiene que ser un equipo especialista el que lo defina, lo monte, y ayude a adoptarlo
En mi entorno de trabajo existe otra figura además del SRE llamada SCM que es soporte para la configuración en base a un estándar y definir plantillas de pipelines de la mejor manera y el mantenimiento de estos, y configura a base de las necesidades del equipo de desarrollo, pero no deslinda al team dev la responsabilidad de llevar cualquier evolutivo a producción ya que el equipo de desarrollo es el mas experto de lo que construye.
mi opinión y lo que he visto que funciona es: el equipo de devops configura el pipeline de CI dependiendo el tipo de artefacto. Así se asegura la calidad y el de CD lo prepara el desarrollador ya que él sabe las variables y tareas necesarias para el despliegue
De acuerdo con eso, DevOps es una cultura, una forma de trabajar que adopta un developer, la CI, el automation, un perfil solo devops creo que queda algo inconcluso en el 90% de los casos
Soy DevOps y sigo viendo que es bien ambiguo en cada negocio, estoy deacuerdo con tu definición de que el dev es debe también ser familiar a la metodología DevOps y el puesto DevOps a la mejor seria mas como estratégico del negocio.
Estoy de acuerdo le mas facil al desarrollador que conoce el codigo como montar los pipelines, para el deploy, la compilacion las prueba unitarias eso lo conoce mas el desarrollador
pues comparto el mismo criterio, un SRE tiene que montarme el Jenkins, dígase software para hacer el CI/CD, darle los permisos que requiero como desarrollador para montar el entorno en pre, y pues el entorno lo tengo que montar yo para hacer mis despliegues en pre, ya luego un SRE se encarga de despliegue en producción, sin embargo hay lugares donde este proceso es tan grande que existe el DevOps, quien solo se encarga de ese proceso y no de programar directamente el software.
Totalmente en desacuerdo, los desarrolladores no tienen que tener acceso a los pipelines, si tu creas una buena pipeline ya no hablo de coger el código y desplegarlo a producción, si no de pruebas unitarias, pruebas de estres, pruebas de codigo estático, de imagenes docker etc... Sería una locura tener que gestionar todo eso a nivel de proyecto. Es MUY mala práctica crear una pipeline por proyecto, debería de haber una pipeline maestra que sea dinámica y obtenga los datos necesarios para hacer el despliegue ya que si el dia de mañana quieres implementar un sonarqube y imaginate que tienes mas de 200 servicios, vas a ir uno por uno añadiendo el sonarqube?
Hablar de oídas es siempre lo peor. No existe ni sre ni devops. No confundas las herramientas con el trabajo. Y es que hay mucho paleta suelto que se cree que hacer edificios es poner ladrillos.
Incluso el desarrollador debe ser capaz de montar su propia infraestructura porque para la aplicaciones en la nube la infraestructura es un código mas.
Jaja, es el hambre de conocimiento, pero por ahí difiero un poco de betatech. Alguien más en los comentarios menciona, que esto es sobrecarga de trabajo al desarrollador y si. Finalmente separar responsabilidades tiene sentido al momento de entregar un producto de software de calidad donde más de uno quedará completamente satisfecho. Hay que compartir jaja
Es una libreria que te permite definir infraestructura. Por ejemplo, AWS CDK te permite definir recursos de aws con Codigo (tipo Terraform pero usando Typescript o Python)
No estoy de acuerdo. Para mi, DevOps es la mentalidad de que el *equipo de desarrollo* no se encarga sólo de *desarrollar* y punto, sino que tiene que ser capaz de llevar a término la mayoría de las *tareas de "Ops"* que vienen después y hacerlo con *suficiente autonomía*. Esto no significa que todo el mundo tenga que ser capaz de hacer absolutamente todo y de forma 100% autónoma, sino que la calve es que el equipo sea capaz de ser lo suficientemente autónomo aunque falte la mitad porque son vacaciones, por ejemplo.
Es exactamente lo que quería transmitir, que no debe haber un “equipo de DevOps” que si por lo que sea no está no se puede hacer despliegue, por ejemplo. Lo que el equipo crea el equipo despliega
Difiero en lo que dices de CI/CD. Porque se pierde el standard, construir un buen pipeline requiere de varios team, como networking, seguridad, dev, sre... A parte de un tema de credenciales sensibles que requiere un manejo de secretos y un buen almacen de credenciales. Mas en un cluster productivo. Construir una buena estrategia de deploy, canary, blue green, una buena estratrgia rollback etc... un conjunto de ambientes como dev, stage, prod... hacer las pruebas de pentesting etc... lleva tiempo... quizas cuando trabajas por proyecto puedas tener esa capacidad de construir pipeline sencillos. Pero una empresa un poco mas grande que ofrezca producto, es bueno contar con un pipeline centralizado. El trabajo DevOps es facilitar y agilizar el proceso de desarrollo mediante la automatizacion para mejorar el time to market y entregar valor comercial... no creo que sea conveniente sobrecargar al equipo de desarrollo con este tipo de cosas que se pueden automatizar y ser stardard. Que con solo un template en su proyecto o un solo archivo .yaml pueda configurar todo lo necesario para su proyecto. Como cpu, memoria, path ingress, variables de entorno, etc... con solo key/value. De igual forma ellos pueden interactuar con la infra desde su pipeline y tener el ownership, De esa manera es donde se logra que el equipo de desarrollo se enfoque en lo que realmente sabe hacer, que es construir software de calidad. No me parece que los devs tengan que aprender cualquier tecnologia que este hoy de moda como kubernetes, terraform etc. Eso tiene que ser transparente para ellos. Necesitamos mas especialistas y no un poquito de cada cosa.
Debo admitir que teniendo al dueño del canal como una persona que sabe de lo que habla, consideré fuertemente lo que menciona... Pero visto el CI/CD desde esta perspectiva, en realidad tiene mucho sentido.
Aunque también es cierto que cuando se trabaja en múltiples proyectos, se aprende a hacer de todo un poco.
Esto es solo la perspectiva de un backend que sabe hacer despliegues sencillos.
Con más de 13 años de experiencia entre ser desarrollador senior y DevOps manager, liderando proyectos grandes y reales en empresas de producto y consultoras, concuerdo completamente con este comentario.
No entendí una pipa xd 😔
Mejor redactado imposible, totalmente de acuerdo, yo también soy devops y tienes mis 10
Vine a saber que es un devops y terminé más confundido.😅
X2
Te imaginas haciendo un pipeline por proyecto, los desarrolladores montando pruebas estáticas, pruebas de seguridad, manejo de versiones, rollbacks, monitoreo y demás. Un devops potencia el trabajo de desarrolladores y sre.
You build it, you run it. Filosofía startup.
En una start-up de pocos desarrolladores, puedes tener razón… En una empresa grande como puede ser un banco por ejemplo, con muchas decenas de desarrolladores, varios departamentos, tecnologías, aplicaciones, etc el ci/cd tiene que ir hacia un standard y tiene que ser un equipo especialista el que lo defina, lo monte, y ayude a adoptarlo
Es que si, DevOps es un complemento al perfil del desarrollador.
En mi entorno de trabajo existe otra figura además del SRE llamada SCM que es soporte para la configuración en base a un estándar y definir plantillas de pipelines de la mejor manera y el mantenimiento de estos, y configura a base de las necesidades del equipo de desarrollo, pero no deslinda al team dev la responsabilidad de llevar cualquier evolutivo a producción ya que el equipo de desarrollo es el mas experto de lo que construye.
mi opinión y lo que he visto que funciona es: el equipo de devops configura el pipeline de CI dependiendo el tipo de artefacto. Así se asegura la calidad y el de CD lo prepara el desarrollador ya que él sabe las variables y tareas necesarias para el despliegue
Concuerdo totalmente !!!
De acuerdo con eso, DevOps es una cultura, una forma de trabajar que adopta un developer, la CI, el automation, un perfil solo devops creo que queda algo inconcluso en el 90% de los casos
Soy DevOps y sigo viendo que es bien ambiguo en cada negocio, estoy deacuerdo con tu definición de que el dev es debe también ser familiar a la metodología DevOps y el puesto DevOps a la mejor seria mas como estratégico del negocio.
Estoy de acuerdo le mas facil al desarrollador que conoce el codigo como montar los pipelines, para el deploy, la compilacion las prueba unitarias eso lo conoce mas el desarrollador
pues comparto el mismo criterio, un SRE tiene que montarme el Jenkins, dígase software para hacer el CI/CD, darle los permisos que requiero como desarrollador para montar el entorno en pre, y pues el entorno lo tengo que montar yo para hacer mis despliegues en pre, ya luego un SRE se encarga de despliegue en producción, sin embargo hay lugares donde este proceso es tan grande que existe el DevOps, quien solo se encarga de ese proceso y no de programar directamente el software.
Completamente de acuerdo
Totalmente en desacuerdo, los desarrolladores no tienen que tener acceso a los pipelines, si tu creas una buena pipeline ya no hablo de coger el código y desplegarlo a producción, si no de pruebas unitarias, pruebas de estres, pruebas de codigo estático, de imagenes docker etc... Sería una locura tener que gestionar todo eso a nivel de proyecto.
Es MUY mala práctica crear una pipeline por proyecto, debería de haber una pipeline maestra que sea dinámica y obtenga los datos necesarios para hacer el despliegue ya que si el dia de mañana quieres implementar un sonarqube y imaginate que tienes mas de 200 servicios, vas a ir uno por uno añadiendo el sonarqube?
Estoy de acuerdo 👌🏻
Totalmente de acuerdo
Sabrías programar una pipe bender? Necesito una urgente
Hablar de oídas es siempre lo peor. No existe ni sre ni devops. No confundas las herramientas con el trabajo. Y es que hay mucho paleta suelto que se cree que hacer edificios es poner ladrillos.
Incluso el desarrollador debe ser capaz de montar su propia infraestructura porque para la aplicaciones en la nube la infraestructura es un código mas.
No entendí ni vergas, y me gustaría 😢. Ya estudiaré
De acuerdo
De que están hablando¿?
Ah... ya. Seguro que estan empleando un lenguaje desconocido :'(
Jaja, es el hambre de conocimiento, pero por ahí difiero un poco de betatech. Alguien más en los comentarios menciona, que esto es sobrecarga de trabajo al desarrollador y si. Finalmente separar responsabilidades tiene sentido al momento de entregar un producto de software de calidad donde más de uno quedará completamente satisfecho. Hay que compartir jaja
Ayuda! Que alguien me explique que es un DevOp
que es cdk?
Es una libreria que te permite definir infraestructura. Por ejemplo, AWS CDK te permite definir recursos de aws con Codigo (tipo Terraform pero usando Typescript o Python)
@@BettaTech Gracias!
No estoy de acuerdo. Para mi, DevOps es la mentalidad de que el *equipo de desarrollo* no se encarga sólo de *desarrollar* y punto, sino que tiene que ser capaz de llevar a término la mayoría de las *tareas de "Ops"* que vienen después y hacerlo con *suficiente autonomía*.
Esto no significa que todo el mundo tenga que ser capaz de hacer absolutamente todo y de forma 100% autónoma, sino que la calve es que el equipo sea capaz de ser lo suficientemente autónomo aunque falte la mitad porque son vacaciones, por ejemplo.
Es exactamente lo que quería transmitir, que no debe haber un “equipo de DevOps” que si por lo que sea no está no se puede hacer despliegue, por ejemplo. Lo que el equipo crea el equipo despliega