Project Guardrails: entornos de aprovisionamiento
Esta serie de artículos breves se compone de algunas cosas que aprendí en los últimos años al ejecutar proyectos basados en el área en la que estamos (asumiendo que estás leyendo esto viniendo de la misma parte de la industria que yo 🙂) trabajar.
Si simplemente te estás topando con esto, la serie cubre algunos factores que son importantes para un proyecto :
- No debe haber un " diseño por comité”. “
- Nadie más que el equipo central de desarrollo debería poder proporcionar el desarrollo, la puesta en escena y la producción.
- Nadie debería poder escribir en producción excepto el equipo de desarrollo (e incluso entonces, debería haber un proceso de implementación).
Realmente no me gusta hacer reglas estrictas y rápidas como esta, porque las cosas cambian con el tiempo, ya sea por necesidad o por más experiencia. Por eso me gustan las "directrices".
Pero en el momento de escribir este artículo, estas son las cosas que veo que se están desarrollando.
Entornos de aprovisionamiento
En los últimos años, hemos progresado mucho en la rapidez con la que podemos aprovisionar nuestros sistemas para que todos se reflejen entre sí (o en general). Esto incluye nuestras cajas de desarrollo, cómo nuestras máquinas locales reflejan la puesta en escena y cómo la puesta en escena refleja la producción.
Aprovisionando un nuevo entorno, más o menos. Rueda con eso.
Eso es si "funciona en mi máquina" en realidad debería ser cierto. No es una excusa para no poder reproducir un error.
Y cuando es cierto, es probable que sea cierto en las máquinas de otros, en la puesta en escena y en la producción. Y esto es bonito, ¿verdad? Quiero decir, activamos nuestras cajas, implementamos nuestros scripts o hacemos lo que hacemos y luego tenemos la configuración que necesitamos.
Entonces, ¿qué significa aprovisionar entornos? Depende del entorno al que te refieras.
¿Cómo es esto realmente?
Si está trabajando en WordPress, que supongo que es si está leyendo esto, entonces se supone que está ejecutando un servidor web, una base de datos y PHP como mínimo.
Un entorno de desarrollo puede tener el siguiente aspecto:
- Apache de Nginx ,
- MySQL que es el más común,
- Al menos PHP 5.2.4 (se recomienda PHP 7.1),
- O algo comparable.
También puede estar usando algo como Laravel Valet o algo como VVV. Todo depende de la naturaleza de su trabajo.
Además, dependiendo de la naturaleza de su negocio, puede tener un IDE asignado junto con varios archivos de configuración para hacer cumplir ciertas reglas.
¿Y el Resto de los Ambientes?
Como siempre:
- el desarrollo se refiere a la configuración en su máquina local,
- puesta en escena se refiere al área en la que usted y las partes interesadas pueden probar,
- y producción es donde reside la aplicación.
Pero esto también se ve diferente dependiendo de dónde trabaje, cómo esté organizado su trabajo, etc. No se trata tanto de cómo se usa, sino de cómo se usa.
Puesta en escena
Por lo general, esto se aprovisionará en un servidor (o grupo de servidores según el tamaño del proyecto) en el que puede implementar su código más reciente para realizar pruebas. Puede incluir funcionalidad parcial, datos de prueba y solo un subconjunto de información de la producción (si opta por extraer esa información, es decir, la base de datos, del entorno de producción).
Esto le brinda a usted y a las demás partes interesadas la capacidad de revisar lo que sucede y cómo funcionará en la producción sin tener que preocuparse por destruir nada sensible.
El código generalmente se implementa desde una rama, generalmente maestra, desde su repositorio de Git (si eso es lo que está usando). Y herramientas como DeployBot, CircleCI, Travis CI, GrumPHP, Behat, etc. también se utilizan para evaluar la calidad del código, ejecutar cualquier prueba automatizada y finalmente implementar el código.
Al final, cada entorno se aprovisionará de manera que se pueda duplicar rápidamente en las máquinas locales, los servidores de ensayo y los servidores de producción. Además, debería ser fácil empujar y extraer datos entre ellos para facilitar el trabajo con los datos.
Producción
Finalmente, la producción tiene que ver con el proyecto de funcionamiento real; Esto significa que el servidor, la aplicación y la base de datos se ejecutan conjuntamente y los usuarios los utilizan.
Esto también significa que el código está en un lugar estable. Es probable que existan mecanismos de registro que notificarán al equipo de desarrollo sobre cualquier problema. No se debe realizar ningún cambio de código en este entorno sin que pase primero el control de calidad o la prueba.
¿Y los procesos en marcha?
Bien, supongamos que está trabajando con una configuración tradicional, a falta de un término mejor, donde todas sus implementaciones se realizan a través de S/FTP en un entorno de producción (o incluso de ensayo). De esta manera, los usuarios pueden bajar archivos, hacer los cambios y volver a subirlos.
Eso no es bueno.
Esto significa que cualquier persona con las credenciales puede iniciar sesión, realizar los cambios y omitir el control de fuente, la integración continua, las herramientas de control de calidad, etc., y realizar los cambios que desee.
Socava todos los procesos puestos en marcha. Esto no solo evita el procedimiento estándar (que existe por una razón, por supuesto), sino que termina descifrando el código que un desarrollador o equipo de desarrolladores tiene en sus máquinas principalmente porque lo que está en producción ya no está sincronizado con el repositorio de código.
Además, este código podría extenderse a través de sucursales que aún no se han fusionado o implementado. Esto nos deja con una variedad de situaciones en las que los desarrolladores y los clientes han roto alguna parte del proceso de construcción y, por lo tanto, todo el proyecto.
Cuando llega el momento de verificar la producción, no está sincronizado con el desarrollo y la puesta en escena, y nadie sabe por qué. Cuando llega el momento de implementar, los cambios se sobrescriben y los responsables han perdido lo que pensaban que iban a ver.
¿Qué debe hacer un equipo?
No sé si hay una respuesta correcta a esto, pero cuanto más tiempo trabajo en esta industria, más creo que la empresa, o empresas, responsables de crear la solución para el cliente deben tener control sobre el proceso desde el final. para terminar.
- Los diseñadores son responsables de administrar sus áreas de creación de conceptos, simulacros, creación de plantillas de demostración y solicitud de comentarios.
- Los gerentes de proyecto son responsables de comunicarse con los departamentos,
- Los desarrolladores son responsables de implementar la solución y vincular el trabajo de los diseñadores con el back-end funcional,
- El cliente es responsable de revisar los cambios, proporcionar comentarios y proporcionar cualquier otra información necesaria para completar la tarea.
Esto significa que cuando se trata de configurar el dominio, el alojamiento, los entornos, el control de versiones, el proceso de compilación y la integración continua, y todo lo demás que he olvidado mencionar, recae directamente en el equipo de desarrollo.
Permanezca en las trincheras, manténgase en el objetivo (pero tenga en cuenta a quienes lo rodean).
En pocas palabras, estas no son responsabilidades del cliente ni deberían serlo. Los límites de la responsabilidad deben establecerse, mantenerse y respetarse en todos los equipos, no solo en los desarrolladores y los clientes o los clientes y los diseñadores o los diseñadores y los desarrolladores, etc.
¿Que sigue?
En la próxima publicación, hablaré sobre las responsabilidades que tienen los desarrolladores (y otras partes interesadas) en el mantenimiento de entornos para el código.
Es decir, quién debe ser responsable de qué y quién tiene acceso para leer y escribir qué datos y cómo puede afectar en última instancia al resultado del proyecto.