Presentamos mejores prácticas en un proyecto Django, cuyo objetivo es inspirar la idea de que crear software puede ser satisfactorio y hasta divertido.
Herramienta CLI personalizada para proyecto Django
Una de las grandes ventajas de Django es que puede reducir grandes cargas de trabajo como por ejemplo, en lugar de escribir:
python3 -m venv env
source env/bin/activate
pip install -r requirements.txt
python3 manage.py makemigrations
python3 manage.py migrate
python3 manage.py collectstatic
python3 manage.py runserver
Se podría escribir:
make start
Se puede hacer esto con un Makefile autodocumentado. Aquí hay uno que se puede usar al desarrollar aplicaciones Django, como ApplyByAPI.com:
SHELL := /bin/bash
include .env
.PHONY: help
help: ## Show this help
@egrep -h ‘\s##\s’ $(MAKEFILE_LIST) | awk ‘BEGIN {FS = “:.*?## “}; {printf “\033[36m%-20s\033[0m %s\n”, $$1, $$2}’
.PHONY: venv
venv: ## Make a new virtual environment
python3 -m venv $(VENV) && source $(BIN)/activate
.PHONY: install
install: venv ## Make venv and install requirements
$(BIN)/pip install -r requirements.txt
migrate: ## Make and run migrations
$(PYTHON) manage.py makemigrations
$(PYTHON) manage.py migrate
db-up: ## Pull and start the Docker Postgres container in the background
docker pull postgres
docker-compose up -d
db-shell: ## Access the Postgres Docker database interactively with psql
docker exec -it container_name psql -d $(DBNAME)
.PHONY: test
test: ## Run tests
$(PYTHON) $(APP_DIR)/manage.py test application –verbosity=0 –parallel –failfast
.PHONY: run
run: ## Run the Django server
$(PYTHON) $(APP_DIR)/manage.py runserver
start: install migrate run ## Install requirements, apply migrations, then start development server
Se puede notar la presencia de la línea de arriba include .env. Esto asegura que make tenga acceso a las variables de entorno almacenadas en un archivo llamado .env.
A su vez, permite que se utilicen las variables en los comandos, por ejemplo, el nombre de un entorno virtual, o para pasar en $(DBNAME) a psql.
Un Makefile como éste brinda una línea de comandos de alias que se puede registrar en el proyecto Django. Es muy útil siempre que se pueda recordar cuáles son todos esos alias.
El comando help anterior, que se ejecuta de forma predeterminada, imprime una lista útil de comandos disponibles cuando ejecuta make o make help:
help Show this help
venv Make a new virtual environment
install Make venv and install requirements
migrate Make and run migrations
db-up Pull and start the Docker Postgres container in the background
db-shell Access the Postgres Docker database interactively with psql
test Run tests
run Run the Django server
start Install requirements, apply migrations, then start development server
Todos los comandos habituales de Django están cubiertos, y se tiene un comando test que ejecuta pruebas con las opciones preferenciales.
Ganchos de confirmación previa
Un área que es una obviedad es usar ganchos de confirmación previa al código antes de registrarlo, lo cual ayuda a mantener la calidad del código que registran los desarrolladores. Pero lo más importante es que garantiza que nadie en el equipo pierda tiempo tratando de recordar si debe ser entre comillas simples o dobles o dónde poner un salto de línea.
El framework de compromiso previo de nombre confuso es una buena forma de mantener los ganchos (que no se incluyen en los repositorios clonados) consistentes en los entornos locales.
Aquí el archivo de configuración .pre-commit-config.yaml, para proyectos de Django:
fail_fast: true
repos:
– repo: https://github.com/pre-commit/pre-commit-hooks
rev: v3.1.0
hooks:
– id: detect-aws-credentials
– repo: https://github.com/psf/black
rev: 19.3b0
hooks:
– id: black
– repo: https://github.com/asottile/blacken-docs
rev: v1.7.0
hooks:
– id: blacken-docs
additional_dependencies: [black==19.3b0]
– repo: local
hooks:
– id: markdownlint
name: markdownlint
description: “Lint Markdown files”
entry: markdownlint ‘**/*.md’ –fix –ignore node_modules –config “./.markdownlint.json”
language: node
types: [markdown]
Estos ganchos comprueban hay confirmaciones secretas accidentales, dan formato a archivos de Python con Black y dan formato a fragmentos de Python en archivos de Markdown con blacken-docsy también archivos de Lint Markdown. Es probable que haya ganchos aún más útiles disponibles para caso particular.
Gitignores útiles
Una forma poco apreciada de mejorar la experiencia de desarrollo en equipo es asegurarse de que el proyecto utilice un archivo .gitignore completo .
Esto puede ayudar a evitar que se confirmen archivos que contienen secretos y, además, puede ahorrar a los desarrolladores horas al garantizar que no se revisen los archivos git diff generados.
Para crear eficientemente un gitignore para proyectos de Python y Django, gitignore.io. Puede ser un buen recurso para generar un archivo robusto .gitignore.
Aún así, se recomienda examinar los resultados generados para asegurarse de que los archivos ignorados se adapten en caso de uso y que no se comente nada que desee ignorar.
Pruebas con acciones de GitHub
Si el equipo trabaja en GitHub, hay que configurar un proceso de pruebas con Actions.
Las pruebas que se ejecutan en un entorno coherente en cada solicitud de extracción ayudan a eliminar los enigmas de “funciona en mi máquina”. También garantizan que nadie espere a que se ejecute una prueba localmente.
Un entorno de CI alojado como GitHub Actions también puede ayudar cuando se ejecutan pruebas de integración que requieren el uso de recursos de servicios administrados.
Se puede usar secretos encriptados en un repositorio para otorgar acceso al corredor de Actions a los recursos en un entorno de prueba, sin preocuparse por crear recursos de prueba y claves de acceso para que cada uno de sus desarrolladores.
Para los proyectos de Django, aquí hay un flujo de trabajo de acciones de GitHub simple que ejecuta pruebas con una versión de Python consistente.
name: Run Django tests
on: push
jobs:
test:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v2
– name: Set up Python
uses: actions/setup-python@v2
with:
python-version: ‘3.8’
– name: Install dependencies
run: make install
– name: Run tests
run: make test
Para los comandos de instalación y prueba, se utilizó el Makefile que se ha registrado en el repositorio.
Una ventaja de usar sus comandos Makefile en sus flujos de trabajo de prueba de CI es que solo necesita mantenerlos actualizados en un solo lugar, en el propio Makefile.
Leíste: Mejores prácticas en un proyecto Django, te recomendamos: Cómo manipular datos con migraciones de Django
Te invitamos a que nos sigas en nuestras redes sociales: Facebook, Twitter, Instagram y Youtube con el perfil: @tortugacode
