La biblioteca Python Cookiecutter revoluciona el desarrollo de proyectos al ofrecer un enfoque simplificado para crear proyectos de plantilla y mejorar la experiencia del desarrollador.
cookiecutter permite a los desarrolladores estructurar rápidamente sus proyectos con estructuras predefinidas, configuraciones y mejores prácticas.
Al abstraer las complejidades de la configuración del entorno, cookiecutter permite a los desarrolladores sumergirse directamente en la codificación, lo que reduce significativamente el tiempo y el esfuerzo necesarios para comenzar a trabajar. Adoptar cookiecutter como una herramienta valiosa puede revolucionar la experiencia de incorporación, mejorar la productividad y permitir que los desarrolladores se concentren en lo que mejor saben hacer: crear software innovador y de alta calidad.
En esta publicación, aprenderá a generar plantillas de Python con cookiecutter y a crear nuevos proyectos de plantilla desde cero. Revisaremos ejemplos de uso y seguiremos pasos precisos para ayudarlo a desarrollar su proyecto de plantilla de Python con cookiecutter.
Tabla de contenido
La experiencia del desarrollador y los proyectos de plantilla son importantes
Diré que los proyectos de plantilla son fundamentales para el éxito de su organización.
En mi organización, CyberArk, estábamos en el proceso de adoptar una nueva tecnología: Serverless.
Fui parte de un grupo pionero que trabajaba intensamente para aprender los entresijos de esta nueva tecnología. Finalmente, creamos un nuevo servicio sin servidor con numerosas prácticas recomendadas, como infraestructura como código (AWS CDK), una canalización de CI/CD dedicada y capacidad de observación incorporada.
Fue un servicio excelente y funcionó bien.
Sin embargo, ahora el equipo se enfrentaba a nuevos desafíos: crear el segundo servicio y otro desafío, aún más difícil: ayudar a los equipos de noticias de CyberArk a crear los mismos niveles de servicios sin servidor con las mismas herramientas. Ahí es donde los proyectos de plantilla resultan útiles.
Convertimos el primer servicio, ese servicio de última generación, en un proyecto de plantilla: un servicio simple pero lo suficientemente genérico como para que cualquier equipo pueda usarlo como punto de partida. Era un repositorio completamente funcional con todas las funciones que ayudan a los equipos de desarrollo a centrarse en lo que más importa: el ámbito empresarial. Lea más sobre esto aquí .
En un caso, un equipo que desarrollaba un servicio sin servidor con la plantilla llegó a la etapa de los socios de diseño (cuando un cliente real utiliza el servicio) en solo cuatro meses. Para una empresa como CyberArk, esto era algo inaudito y muy rápido.
Ahora que entendemos el incentivo para los proyectos de plantilla, comencemos generando un nuevo repositorio a partir de una plantilla con cookiecutter y luego procesemos para crear nuestra plantilla.
Instalación de Cookiecutter
Primero, asegúrese de instalar Python 3.
Luego, ejecute el siguiente comando:
pip install cookiecuttero en una mac:
brew install cookiecutterSi necesita más ayuda, lea las pautas de instalación oficiales.
Cookicutter - La experiencia del usuario
Antes de crear plantillas, debemos entender qué tipo de experiencia de usuario obtendrán nuestros desarrolladores. Debemos esforzarnos por hacerla sencilla, rápida y eliminar tantos pasos manuales como sea posible.
Crear un nuevo entorno de trabajo para desarrolladores es uno de los desafíos más complejos a los que se enfrentan los desarrolladores. Podemos usar cookiescutter para crear nuestro proyecto y configurar el entorno de desarrollo; más información al respecto en la sección "ganchos".
Creemos un nuevo servicio sin servidor a partir de mi proyecto sin servidor cookiecutter, basado en mi proyecto de libro de recetas del controlador AWS Lambda.
La plantilla de servicio sin servidor tiene numerosas características:
Infraestructura CDK con pruebas de infraestructura y pruebas de seguridad.
Canalizaciones de CI/CD basadas en acciones de Github que se implementan en AWS con linters de Python, controles de complejidad y formateadores de estilo.
Makefile para una experiencia de desarrollador sencilla.
El controlador AWS Lambda incorpora las mejores prácticas sin servidor y tiene todas las características necesarias para un controlador listo para producción.
Arquitectura de tres capas del controlador AWS Lambda: capa del controlador, capa lógica y capa de acceso a datos.
Cuenta con indicadores y configuración basados en AWS AppConfig.
Pruebas unitarias, de infraestructura, de seguridad, de integración y E2E.
Y el diagrama de arquitectura:
La configuración
Ejecute este comando:
cookiecutter gh:ran-isenberg/cookiecutter-serverless-pythonResponda las siguientes preguntas para estructurar el proyecto:
Cookiecutter comenzará a estructurar el proyecto e inicializará un entorno de trabajo.
Una vez completado, aparecerá un mensaje: "Proyecto inicializado exitosamente".
¡Eso es todo! Así de simple, puedes comenzar a desarrollar tu nuevo y atractivo servicio sin servidor e implementarlo en AWS.
Si te gustó el proyecto y la experiencia no seas ajeno y dale una estrella :)
Crea tu propia plantilla
Ahora que entendemos lo que queremos lograr, vamos a construirlo.
Estructura del repositorio
Comience con un repositorio vacío. Deberá agregar cuatro archivos en el nivel superior del proyecto:
Archivo Léame: explica el propósito del proyecto y proporciona instrucciones de configuración.
cookiecutter.json: este archivo proporciona a cookiecutter la configuración y los parámetros de estructura que se deben utilizar al clonar un nuevo proyecto. Más información al respecto a continuación.
La carpeta raíz del proyecto de plantilla que desea proporcionar.
Carpeta Hooks: se utiliza para casos de uso avanzados; consulte a continuación.
Así que terminas con algo parecido a esto:
Repasemos la carpeta principal, la carpeta hooks y los archivos cookiecutter.json.
cortador de galletas.json
En este archivo, se definen los parámetros de estructura de Cookiecutter que afectan las preguntas que se le presentan al usuario durante la configuración inicial. Puede elegir lo que desee, pero yo utilizaría el siguiente ejemplo como punto de partida:
Los valores proporcionados son predeterminados si el usuario presiona Enter como respuesta y no proporciona ninguna otra entrada.
La parte "_copy_without_render" ayuda a agregar archivos y carpetas que no quieres que cookiecutter recorra y copie tal como están.
Las partes de autor, correo electrónico y descripciones se pueden inyectar en el archivo README de la plantilla y en la sección de descripciones de poetry.toml.
También hay soporte para opciones de opción múltiple como se describe aquí .
Carpeta de plantilla principal
Esta es la carpeta de entrada para su proyecto de plantilla. Debe cambiarle el nombre a un nombre que cookiecutter pueda reconocer y utilizar como estructura. Se agregarán y utilizarán como estructura todos los archivos que se encuentren debajo.
En mi plantilla, le cambié el nombre a '{{cookiecutter.repo_name}}'. Observe que 'repo_name' es el parámetro definido en el archivo cookiecutter.json.
Generalmente, debajo de la carpeta principal, agregarías otra carpeta para el nombre del servicio, que definí como '{{cookiecutter.service_name}}'.
Así que podría verse así:
No todas las carpetas requieren soporte de andamiaje, y usted puede decidir qué carpetas permanecen constantes y cuáles se renombran.
Observa cómo la carpeta interna tiene su archivo .toml para poesía, .github para flujos de trabajo de CI/CD, carpeta CDK para implementación, carpeta de pruebas y otras carpetas necesarias. Puedes agregar lo que desees.
Un aspecto crucial que debes conocer es que el andamiaje rompe la ruta de importación de Python. Dado que la carpeta principal es dinámica y la determina el usuario cuando responde a preguntas repetidas, significa que las declaraciones de la ruta de importación de Python también requieren que las editemos.
He aquí un ejemplo de cómo superarlo:
Observe las líneas 10 a 12 y cómo importamos los archivos con soporte de andamiaje.
El archivo completo se puede encontrar aquí .
Puede utilizar este método para cambiar el nombre de cualquier valor en cualquier archivo.
Carpeta de ganchos
La carpeta de ganchos es opcional, pero te sugiero que la implementes también.
Los ganchos son códigos que se ejecutan antes del proceso de cambio de nombre de Cookiecutter o después de que este finaliza.
Puede usarlo para realizar la validación de entrada en las preguntas y configurar un entorno de desarrollo completo una vez que el proyecto esté estructurado.
Pre-gancho
Puede utilizar el pre-hook para validar la entrada en las cadenas del usuario. Si recuerda, algunas de estas cadenas se utilizan como nombres de servicios o repositorios. Se utilizan en la ruta de importación de los archivos de repositorio generados, por lo que deben cumplir con la convención de nombres de Python.
Puedes utilizar el siguiente ejemplo:
Gancho para poste
Aquí es donde ocurre la magia. Hemos hablado mucho sobre la importancia de la experiencia del desarrollador y el gancho de publicación es donde puedes marcar la diferencia.
Puede escribir scripts e inicializar el entorno del desarrollador para que éste pueda comenzar a escribir código nuevo en lugar de perder tiempo en configuraciones manuales y tediosas del entorno.
Aquí hay un ejemplo de mi script post-hook donde inicializo git, instalo todas las dependencias de poetry e instalo pre-commit para que todas las comprobaciones se ejecuten antes de que un PR pueda funcionar.
Pruebas y depuración local
Suena bastante simple, ¿verdad?
Sin embargo, no te funcionará la primera vez. Nunca lo hace. Por lo tanto, tendrás que depurar, corregir y depurar nuevamente.
cookiecutter admite la ejecución desde una carpeta local, no solo desde una URL de repositorio de GitHub.
Puedes desarrollar el nuevo repositorio de plantillas localmente, realizar cambios y luego ejecutar cookiecutter desde la terminal y ver si funciona:
cookiecutter {path-to-project-on-local-disk}Para obtener más consejos y trucos, lea los documentos oficiales: https://cookiecutter.readthedocs.io/en/stable/