Nico - Dapta.ai
Region: US
Friday 30 May 2025 01:58:30 GMT
40027
1613
87
100
Music
Download
Comments
Juancahr_ :
Sería crear una instancia efímera, que se crea al momento de crear el pull request, y de destruye al aprobar el request
2025-05-30 02:36:53
26
David Palacios :
No me queda claro cuál es la necesidad de tener un ambiente para cada feature? Probar antes de integrarlo a dev? Realmente tiene un costo beneficio prudente? Desde mi experiencia el “build” no debería generar despliegue sobre la rama, solo hacer un análisis ESTÁTICO, en donde se evalúen pruebas unitarias, análisis de seguridad, cobertura de código, etc, si estas validaciones ESTÁTICAS pasan, se aprueba el despliegue en ambiente dev, Qa o Pdn, con eso aseguras que el código nuevo no vaya a romper 100% tu app. Para eso estarían los ambientes intermedios usando gitflow.
2025-07-24 04:24:54
2
J.D X El Mundo :
Feature branches
2025-05-30 02:57:19
0
Manuel Guarin :
Súper esos videos me encanta como se hablan de esos temas en procesos reales empresariales
2025-05-30 02:47:41
8
andmar466 :
Cómo está afectando la democratización de los agentes AI como N8N a Dapta?
2025-06-02 21:19:03
0
Cristhian Fernando R :
El sonar es básico, pero una duda como integra las pruebas?
2025-06-04 18:18:08
1
raymundopulidobej :
usen amplify AWS te permite hacer eso mismo para back o front, ademas es sumamente barato
2025-07-03 05:13:19
0
Juan Muñoz :
Invitación a usar Fortidevsec para hacer análisis staticos y dinámicos sobre el ciclo de desarrollo.
2025-06-30 15:43:31
0
Luchesco :
Pues compa, por lo regular uno no genera artefactos o despliegues a ambientes desde features a no ser que sean POC. Con una feature puedes ir haciendo análisis estático con Sonar y ejecutar tareas para compilación de artefactos. Una vez haces merge a rama dev o master ya usas otro pipeline de release management para desplegar esa versión de dev compilada en el entorno de dev. Y todo acompañado de políticas en los agentes. Si dev y qa es el mismo ambiente, pues ya se notifica al tester para que haga sus pruebas automatizadas o E2E y de performance.
2025-06-06 03:59:20
1
Gio :
Soy estudiante y apenas entiendo que estan hablando de Git y GitHub
2025-07-27 19:49:25
0
tmrobaraneda :
por eso trabajo en entorno gitflow, con dos ramas dev y main. El ambiente de qa es mejor cuando todas las integraciones pasaron en dev correcto y generas un release, ese release lo subes como qa en un ambiente dedicado
2025-05-30 18:56:17
1
Agustin Cano Alvarez :
Chimba los ephemeral env, baratos en Kubernetes y demas, si usan Heroku o algun otro PaaS si RIP
2025-08-26 00:56:36
0
David Hernandez :
Me quedé hasta que mordió el durazno 😆
2025-06-01 05:17:14
0
jprubydev :
No toda PR requiere que se despliegue todo un entorno, se puede tener adhoc deploys, donde con un action se requiera solo en caso de ser necesario, o usar conscript si se quiere ser más chat-able. Es mucho más sencillo y al final depende de si es o no necesario desplegar por x cambio
2025-07-09 04:41:31
1
gutemberg :
Se llama preview deployments. Al menos para Frontend pueden empezar por ahí y para backend con ephimeral environment. Si prueban con AI Agents es
2025-05-30 03:01:12
13
LeinerDev | Software Engineer :
Podrían crear un build validation que ejecute los tests, análisis de código estático, análisis de vulnerabilidades, etc. Y si todo eso pasa bien se aprueba el PR
2025-05-30 02:42:02
5
Jonathan Cuspoca :
Lo he trabajado con CI/CD a través de Jenkins y todo el ecosistema de Atlasian, para repositorios back por ejemplo de microservicios o lambdas, generamos el componente o versión a través del mismo feature (una imagen en ECR o el zip de la lambda) y lo desplegamos directamente con el Feature y manejamos el PR como draft, lo que nos permite hacer todo el análisis de código estático (ejecutar todos los pasos del pipeline con el PR Draft) y temas de sonarqube en general pero también despliegas la versión generada directamente por la feature sin necesidad de mezclar o manchar la rama de develop; al tener todo por contenedores en ECS o EKS, disponibilizamos el componente en el ambiente de develop (sea un pod o un service o la versión de la lambda) a través del despliegue de la feature (correr el Pipeline con parámetros haciendo referencia a la rama feature) y tanto el desarrollador como el equipo de QA puede realizar sus respectivas pruebas. Cuando se certifica, se mezcla. Espero te sirva, saludos.
2025-05-30 05:39:37
4
Dym :
CI/CD resolvió estos problemas hace mucho. Feature flags y TBD y te evitas los gastos de ambientes efimeros
2025-05-30 21:25:57
4
jac_castle :
no entendí nada, pero me gusta 😜😜😜
2025-06-25 11:28:30
3
JeanPi :
no se por que se siente tanta fricción en esa llamada si se me hace la manera más normal de trabajar
2025-06-09 21:59:27
2
Emerson Roncancio :
Solo quiero ser uno de ellos
2025-07-09 04:23:02
1
Beto :
Y si tu feature depende de otro feature que aun no se ha puesto tampoco en prod?
2025-05-31 18:49:30
1
Yiyito :
juemadre hablan de tanta vaina y uno que apenas sabe git, dónde se aprende todo esto?
2025-05-31 03:28:37
1
Jc-navarro :
Si es front funciona si es mobile, los reviews de los internal testing empiezan a saturarse
2025-05-30 22:22:50
1
Hans :
El costó debería ser el build/deploy + infra que va a estar en s3/ecs/cluster de desarrollo que permite tener ambientes efímeros. Otro tema es que IMHO ya el tema de las feature branches ramas de desarrollo si están MUY mandadas a recoger si tenemos trunk based development y feature flags
2025-05-30 13:16:16
1
Horus :
si chicos hagamos un ambiente de qa que sea un espejo de prod.
2025-05-30 13:02:32
1
jpgg168 :
Si ya tienen CI debería ser fácil agregar un Job después de los tests del feature branch que haga el build y lo despliegue en cualquier env designado y luego puede correr un script para hacer functional tests
2025-05-30 02:46:16
1
solo funas :
Docker puede ser un contenedor qa y así cada el contraste del código es mantenible
2025-05-30 14:38:15
1
Santiago Vicaría :
Entendí todo! 💪 que no se noten las ganas de resolver lo y saber la respuesta ❤️
2025-05-30 04:56:08
1
Fausto :
mande
2025-07-02 03:07:42
0
chatuz park :
El team de sobre ingeniería 🫢😅😅
2025-08-06 03:48:48
0
nico.rr05 :
Vercel para el frontend genera los builds por cada rama
2025-06-20 05:01:31
0
Jorge I. Mendoza :
Lo que tú necesitas @Nicolas - Dapta.ai son los famosos preview. Que efectivamente son builds que solo duran mientras pruebas y posteriormente los mergeas a Dev
2025-07-26 04:50:23
0
Miguel S. Cortes :
amiguito todo lo solucióna gitflow.
2025-06-25 20:59:45
0
Andrés Cabrera :
pueden tener un ambiente QA que sea el espejo de producción, así QA realizaría pruebas de estrés y funcionalidad de acuerdo a criterios de desarrollo y necesidades, el desarrollador deberá crear su rama de trabajo o hito a partir de la rama de producción, desarrolla, realiza pruebas en local Dev, enviara el PR al ambiente de test del equipo de desarrollo que sirve como ambiente de integración, pruebas y si todo está ok, envía el PR desde la rama que realizó el desarrollo a QA, con kubernetes puede crear el namespace de QA con un build que se ejecuta cuando se acepta el PR, claro este debe ser validado por varias personas expertas, QA prueba y si pasa las pruebas, se enviaría el código del desarrollador a producción. Con esto no manchamos las ramas principales y controlamos posibles revert en caso de ser necesario, además de poder realizar correcciones de código desde la rama que se desarrollo.
2025-06-30 05:14:20
0
sebastiangutierrezdaza :
nosotros hacemos múltiples commits al dia. y tenemos ambientes temporales A y B junto con dev qa y prd. no todos lanzan commits para desplegar pero una vez lo consideramos lo lanzamos a uno de A y B para pruebas integrales desde desarrollo. cada equipo área tiene su ambiente A y B para pruebas internas. al principio era ilimitados pero por costo y métricas vimos que con dos ambientes temporales por equipo era mas que suficiente.
2025-07-23 17:16:24
0
ElTitan :
si no se tiene ambientes de pruebas, lamentablemente se usa el único ambiente que se disponga para las pruebas, usen modelo de branching TBD.
2025-07-05 11:16:28
0
Jonnathan Sanchez :
Demasiado costoso en mi opinión, hacer deploy de la app por cada feature branch? Eso se puede solucionar con una buena cobertura de código, pruebas unitarias de integración y e2e tests, lo mínimo que debería asegurar cada Pull request es que la app compile corra pruebas y mínima calidad de código.
2025-07-06 14:19:21
0
VersusX :
Puro humo directo a producción como macho alfa programador con bolas de acero
2025-05-31 16:12:48
0
patty :
hubiera Sido bueno un esquema para escuchar este video😢
2025-05-31 01:40:06
0
JuanjoB :
Genial. 🔥🔥🔥
2025-05-30 02:17:00
0
ByteBillionaire :
Si es front aws amplify - se configura para genera url únicas por branch. Con microservice namespace con EKS + Helm.
2025-05-30 02:40:41
0
Hernie :
Hey Nico, si llega a necesitar Automation , Pentesting o performance , sería chévere trabajar con uds!
2025-05-30 06:21:09
0
luismora180585 :
Deben tener un ambiente de QA para que los qa verifiquen los features
2025-05-30 06:28:26
0
Alfredoprograma :
😳😳😳
2025-05-30 13:36:25
0
Bryan Cubillos Prieto :
Obvio git branch
2025-05-30 15:19:06
0
oscar_jair_ :
desarrollan varios en la misma feature branch? ... como ven los cambios al codificar? con cada commit un nuevo build?
2025-05-30 18:55:31
0
anjuce_0606 :
Entonces el ambiente de QA no sería necesario... pero igual se necesitaría un ambiente de integración y pruebas de integración , porque no tendría sentido que QA pruebe todos los features por separado pero nunca juntos.
2025-06-06 12:54:28
0
beans :
sigue subiendo ci/cd por favor.
2025-05-31 06:34:30
0
Its_MM :
Terraform
2025-05-31 16:02:09
0
K :
Jaja no entendieron nada es buena idea poder tener build de cada feature pero depende el proyecto puede ser costoso y más cuando agregues análisis de seguridad y de más.
2025-05-30 02:16:04
0
Andrés :
👍👍
2025-05-31 23:41:14
0
To see more videos from user @nicolasimagine, please go to the Tikwm
homepage.
