Un pipeline a la medida del proyecto
Decide qué reutilizar de un pipeline de Terraform según los riesgos y la escala del nuevo proyecto.
La decisión que vas a investigar
Un escenario ficticio: lee la evidencia y compara enfoques. Cada recomendación responde a las restricciones del caso. No se ejecuta nada en sistemas reales. El avance se reinicia al salir o recargar.
Un equipo ficticio necesita un pipeline de Terraform para un servicio interno pequeño. Le ofrecen un repositorio de plataforma como referencia. Tu tarea es elegir un enfoque que el equipo pueda operar.
Criterio técnico
Etapa 1 / 4
Inspeccionar el requerimiento
Evidencia disponible
- Tarea
- Crear CI/CD para Terraform. Usar el repositorio de plataforma como referencia.
- Contexto del proyecto
- Dos responsables, una cuenta AWS y un entorno. Hay un bucket compartido cuyos datos deben sobrevivir a los despliegues. Los cambios se aplican desde equipos locales.
Revisa el trade-off y prueba otro enfoque
La longitud no explica quién controla el estado, los accesos ni los cambios destructivos. Empieza por las restricciones operativas.
Respaldado por la evidencia
Estas respuestas definen los controles necesarios, aunque solo exista un entorno.
Revisa el trade-off y prueba otro enfoque
El proyecto necesita un entorno. Añadir más importaría un requerimiento que hoy no existe.
Empezar por las restricciones
Un proyecto pequeño puede tener riesgos importantes. El alcance y el riesgo son entradas distintas para el diseño.
Entender la referencia
Evidencia disponible
- Repositorio de referencia
- Ocho cuentas, matrices regionales, bloqueo de estado remoto, identidad federada para CI, revisión del plan y un coordinador de releases entre equipos.
- Respuesta del equipo
- El nuevo proyecto necesita cambios serializados y revisión del plan. No tiene releases regionales ni dependencias entre equipos.
Respaldado por la evidencia
Conservas protecciones relevantes y dejas fuera la estructura que pertenece a otro modelo operativo.
Revisa el trade-off y prueba otro enfoque
La consistencia ayuda cuando las necesidades coinciden. Aquí la matriz y el coordinador añaden dependencias sin resolver un problema identificado.
Revisa el trade-off y prueba otro enfoque
Los datos compartidos siguen necesitando protección. Tener pocos recursos no vuelve aceptable un destroy accidental.
Reutilizar decisiones con intención
Relaciona cada control con una restricción. La referencia explica otro sistema; todavía hay que evaluar qué aplica al nuevo.
Elegir el cambio
Evidencia disponible
- Enfoque acordado
- El equipo acepta estado remoto con bloqueo, un rol de CI acotado, applies serializados y revisión humana del plan.
- Restricción de entrega
- Solo puede aplicarse el plan revisado de la revisión aprobada. Un commit nuevo invalida la aprobación anterior.
Revisa el trade-off y prueba otro enfoque
El nuevo plan puede incluir cambios sin revisar. La aprobación debe seguir ligada a la revisión y al plan que se aplican.
Revisa el trade-off y prueba otro enfoque
El equipo ya necesita cambios controlados y trazables. La cantidad de cuentas no determina esa necesidad.
Respaldado por la evidencia
La implementación conserva el límite de revisión acordado sin añadir un coordinador de releases.
Llevar el acuerdo al comportamiento
Los controles sirven cuando hacen lo que las personas creen estar aprobando.
Verificar el resultado
Evidencia disponible
- Prueba inicial
- Un cambio inocuo funciona en un entorno de prueba desechable. Todavía no se ha probado una ejecución simultánea ni una revisión nueva.
- Criterios de aceptación
- Evitar applies simultáneos, rechazar aprobaciones desactualizadas y documentar quién se encarga de la recuperación.
Revisa el trade-off y prueba otro enfoque
El camino exitoso no ejercita las protecciones que motivaron este diseño.
Respaldado por la evidencia
Verificas las restricciones reales y que el equipo pueda operar el resultado.
Revisa el trade-off y prueba otro enfoque
Tener la misma cantidad de jobs no demuestra seguridad ni responsabilidad operativa.
Verificar el motivo del diseño
La aceptación debe demostrar el comportamiento requerido, incluidos los fallos que importan.
El pipeline tiene un porqué
Elegiste controles según el contexto, alineaste el enfoque y definiste evidencia de operación segura.
Lección
Reutiliza el razonamiento de una referencia. Conserva los controles que exigen tus restricciones y deja fuera la complejidad ajena.
Repasar el razonamiento
-
Inspeccionar el requerimiento
¿Quién puede aplicar cambios, cómo se protege el estado y qué no debemos destruir?
Un proyecto pequeño puede tener riesgos importantes. El alcance y el riesgo son entradas distintas para el diseño.
-
Entender la referencia
Conservar protección del estado, identidad acotada y revisión; omitir la matriz regional y el coordinador.
Relaciona cada control con una restricción. La referencia explica otro sistema; todavía hay que evaluar qué aplica al nuevo.
-
Elegir el cambio
Aplicar el plan revisado de la misma revisión; pedir otro plan y revisión si cambia.
Los controles sirven cuando hacen lo que las personas creen estar aprobando.
-
Verificar el resultado
Probar concurrencia y cambios de revisión de forma segura, y pedir a un responsable que siga las notas de recuperación.
La aceptación debe demostrar el comportamiento requerido, incluidos los fallos que importan.
Leer la nota que acompaña este lab
Antes de implementar, entender el problema
Una solución puede funcionar y aun así resolver el problema equivocado. Notas sobre contexto, referencias y criterio antes de empezar a implementar.
Labs relacionados
Avanzar mientras se revisa el enfoque
Decide qué necesita alineación, qué puedes investigar ahora y cuándo basta la revisión habitual para un cambio pequeño.
¿Repararlo o retirarlo?
Investiga una sincronización que falla y decide si todavía responde a una necesidad antes de reconstruirla.
El ALB con instancias sanas y sin tráfico
Diagnostica un Application Load Balancer de AWS cuyo health check todavía usa una ruta eliminada.