Project Guardrails: de la escritura a la producción
En los últimos artículos, hablé sobre un par de cosas (salvadas para escribir en producción) que ayudan a ejecutar un proyecto exitoso:
- Los peligros del " diseño por comité "
- Consideraciones para el aprovisionamiento de un entorno.
Lo último que quiero abordar sobre el aprendizaje que he experimentado hasta ahora es sobre cómo mantener las claves proverbiales del reino de la escritura en producción y por qué eso es importante.
Escritura a producción
La idea de escribir para producción puede parecer la barrera protectora más dogmática de las mencionadas porque generalmente está bien para aquellos que están creando la solución y conocen los entresijos de cómo funciona.
Es probable que las otras partes interesadas no lo hagan (pero si lo hacen y el equipo de desarrollo está de acuerdo con que los demás usen el control de versiones para manejar esto, entonces adelante).
¿Quién tiene permiso para administrar estas cosas, en realidad?
Recuerde, sin embargo, como se mencionó anteriormente en esta serie, la forma en que estamos implementando nuestros proyectos ha cambiado ahora, por lo que a menudo tenemos una implementación continua y una integración continua.
Y, a menudo, estos servicios están conectados a un repositorio de código fuente, como GitHub, y un sistema de mensajería (que, a su vez, puede estar conectado a Slack, lo que me resulta útil).
Para que las personas del equipo estén al tanto de lo que se implementó y cuándo, y sepan cómo obtener el código (que es del repositorio, no de descargarlo a través de S/FTP) si es necesario.
Cuando se necesita una revisión, aún debe haber un procedimiento en su lugar. Tal vez alguien esté de guardia y haya un proceso mediante el cual se utilicen bifurcaciones, fusiones, etiquetas y versiones semánticas.
Independientemente, no se trata tanto de cómo funciona el proceso; es que está en su lugar y que se sigue.
Por supuesto, estas cosas no se implementan para complicar el desarrollo (aunque entiendo que pueda parecer así). Es al contrario. Es por una variedad de razones:
- para mantener el despliegue continuo, ya sabes, continuo,
- contar con pruebas integradas,
- para medir continuamente los estándares de codificación o la calidad del código,
- para evitar la codificación de vaqueros,
- y más.
No se trata tanto de mantener a otras personas fuera, pero si es responsabilidad de los desarrolladores impulsar el código, ¿alguien más debería tener acceso de escritura al servidor?
Y ese es el resultado final: si está trabajando en un equipo donde los procesos que tiene implementados pueden socavar por completo el trabajo que está haciendo, ¿cuál es el propósito del proceso, de todos modos?
Porque en cualquier momento, alguien más puede venir y esto ignorar todo lo que has hecho. Entonces eres, como mínimo:
- atrapados con tener que extraer sus cambios probablemente a través de S/FTP,
- compararlo usando una herramienta diff con una rama en la que alguien está trabajando,
- implementar los cambios (dejemos saber por qué se hicieron),
- y luego volver a trabajar en los requisitos.
Suena agitado cuando lo pones así, pero eso es exactamente lo que sucede.
la comida para llevar
Entonces, ¿cuál es el propósito de las últimas publicaciones? Si tuviera que resumirlo lo más sucintamente posible sería:
Cuando se trata de un proyecto, conozca sus responsabilidades y no se salga de ellas. De lo contrario, corre el riesgo de descarrilar todo.
Esto se aplica a desarrolladores, diseñadores, clientes, especialistas en marketing, gerentes de proyectos, etc. Cómo se designan los roles, no sé mucho (quiero decir, generalmente está claro quién debe ser quién en los roles anteriores), pero me refiero en términos de quién es la persona de contacto real, el propietario del proyecto, para todo el proyecto.
No seas así.
Y dependiendo de cómo vaya todo lo anterior, el proyecto puede ser un conjunto relativamente sencillo de trabajo diario.
Tanto como sea posible, ¿no queremos disfrutar de lo que estamos haciendo?