septiembre 30, 2020

Mejores prácticas en un proyecto Django

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