Lección 3.1 Publicar y mantener el control
Separar ambientes y aprobaciones
Definir dónde se prueba un cambio, quién autoriza su avance y qué condiciones se conservan.
Una receta nueva puede probarse sin cambiar de golpe el menú del restaurante. El lugar donde experimentas y el lugar donde atiendes cumplen responsabilidades distintas. Separarlos permite aprender antes de comprometer la operación.
En software, un ambiente reúne código, configuración, datos y accesos destinados a un uso. No es simplemente «otro servidor»: dos aplicaciones en equipos diferentes siguen compartiendo riesgos si utilizan la misma base de datos o las mismas credenciales.
Tres ambientes, tres preguntas
| Ambiente | Pregunta principal | Condición importante |
|---|---|---|
| Desarrollo | ¿Podemos construir y comprender el cambio? | Datos ficticios y margen para experimentar. |
| Validación | ¿Esta entrega satisface las condiciones acordadas? | Configuración representativa y resultados identificables. |
| Producción | ¿Puede atender a personas reales con continuidad? | Accesos limitados, seguimiento y recuperación. |
Los nombres pueden cambiar según la organización. Lo importante es saber qué se permite, qué información se utiliza y quién responde por cada ambiente. Un entorno de validación tampoco demuestra por completo el comportamiento bajo tráfico real.
Una aprobación necesita algo que revisar
Para nuestro pedido ficticio, quien autoriza debería reconocer la entrega, ver las comprobaciones de importes y conocer el destino. También necesita saber qué ocurrirá si falla. Un botón de aprobación sin esa información registra una decisión, pero aporta poco a su calidad.
GitHub Actions permite asociar trabajos a ambientes y configurar protecciones. La disponibilidad de algunas reglas depende del plan y de la visibilidad del repositorio. El principio puede implementarse con otras herramientas: la autorización debe estar relacionada con una entrega concreta y las condiciones revisadas.
Si después de aprobar cambian el paquete o un parámetro que afecta al pedido, hay que evaluar ese cambio. La aprobación anterior no se extiende automáticamente a cualquier resultado que lleve el mismo nombre.
El cambio que ocurrió después del visto bueno
Se aprobó «demo-1» con datos ficticios. Antes de activarla, alguien cambió la conexión hacia una base real. ¿Sigue siendo la misma decisión?
La condición que cambió
El paquete puede ser idéntico, pero ahora tiene otros datos y consecuencias. Corresponde revisar accesos, compatibilidad y efectos sobre esa base. La aprobación debe considerar el entorno en el que se usará la entrega.