Práticas recomendadas do projeto Django que manterão seus desenvolvedores felizes

Você quer que sua equipe desfrutar seu fluxo de trabalho de desenvolvimento? Você acha que a construção de software deveria ser divertido e existencialmente gratificante? Se sim, esta é a postagem para você.

Há anos desenvolvo com Django e nunca estive mais feliz com meu projeto Django estabelecido do que agora.

Neste artigo, explicarei como faço de um dia de desenvolvimento com Django a experiência de desenvolvimento mais relaxante e agradável possível para mim e minha equipe de engenharia.

Em vez de digitar:

python3 -m venv envsource env/bin/activatepip install -r requirements.txtpython3 manage.py makemigrationspython3 manage.py migratepython3 manage.py collectstaticpython3 manage.py runserver

Não seria muito mais agradável digitar:

make start

… E tudo isso aconteceu para você? Acho que sim!

Podemos fazer isso com um Makefile autodocumentável. Aqui está um que eu uso com frequência ao desenvolver meus aplicativos Django, como ApplyByAPI.com:

SHELL: = / bin / bash include .env .PHONY: help help: ## Mostra esta ajuda @egrep -h ' s ##  s' $ (MAKEFILE_LIST) |  awk 'BEGIN {FS = ":. *? ##"};  {printf " 033[36m%-20s33[0m %sn", $$1, $$2}'.PHONY: venvvenv: ## Make a new virtual environment    python3 -m venv $(VENV) && source $(BIN)/activate.PHONY: installinstall: venv ## Make venv and install requirements    $(BIN)/pip install -r requirements.txtmigrate: ## Make and run migrations    $(PYTHON) manage.py makemigrations    $(PYTHON) manage.py migratedb-up: ## Pull and start the Docker Postgres container in the background    docker pull postgres    docker-compose up -ddb-shell: ## Access the Postgres Docker database interactively with psql    docker exec -it container_name psql -d $(DBNAME).PHONY: testtest: ## Run tests    $(PYTHON) $(APP_DIR)/manage.py test application --verbosity=0 --parallel --failfast.PHONY: runrun: ## Run the Django server    $(PYTHON) $(APP_DIR)/manage.py runserverstart: install migrate run ## Install requirements, apply migrations, then start development server

You’ll notice the presence of the line include .env above. This ensures make has access to environment variables stored in a file called .env.

This allows Make to utilize these variables in its commands, for example, the name of my virtual environment, or to pass in $(DBNAME) to psql.

What’s with that weird “##” comment syntax? A Makefile like this gives you a handy suite of command-line aliases you can check in to your Django project. It’s very useful so long as you’re able to remember what all those aliases are.

The help command above, which runs by default, prints a helpful list of available commands when you run make or make help:

help                 Show this helpvenv                 Make a new virtual environmentinstall              Make venv and install requirementsmigrate              Make and run migrationsdb-up                Pull and start the Docker Postgres container in the backgrounddb-shell             Access the Postgres Docker database interactively with psqltest                 Run testsrun                  Run the Django serverstart                Install requirements, apply migrations, then start development server

All the usual Django commands are covered, and we’ve got a test command that runs our tests with the options we prefer. Brilliant.

You can read my full post about self-documenting Makefiles here, which also includes an example Makefile using pipenv.

Save your brainpower with pre-commit hooks

I previously wrote about some technical ergonomics that can make it a lot easier for teams to develop great software.

One area that’s a no-brainer is using pre-commit hooks to lint code prior to checking it in.

This helps maintain the quality of the code your developers check in. But most importantly, it ensures that no one on your team is spending time trying to remember if it should be single or double quotes or where to put a line break.

The confusingly-named pre-commit framework is an otherwise fantastic way to keep hooks (which are not included in cloned repositories) consistent across local environments.

Here is my configuration file, .pre-commit-config.yaml, for my Django projects:

fail_fast: truerepos:  - 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: ganchos locais: - id: markdownlint nome: markdownlint descrição: "Lint Markdown files" entrada: markdownlint '** / *. md' --fix --ignore node_modules --config "./.markdownlint.json" idioma : tipos de nós: [markdown]

Esses ganchos verificam se há commits secretos acidentais, formata arquivos Python usando Preto, formate snippets Python em arquivos Markdown usando blacken-docs, e Arquivos Markdown lint também.

Provavelmente, existem ganchos ainda mais úteis disponíveis para o seu caso de uso específico: consulte ganchos suportados explorar.

Gitignores úteis

Uma forma pouco apreciada de melhorar a experiência de desenvolvimento diária de sua equipe é garantir que seu projeto use uma .gitignore Arquivo.

Isso pode ajudar a evitar que arquivos contendo segredos sejam confirmados e, além disso, pode poupar horas de tédio aos desenvolvedores, garantindo que você nunca esteja peneirando um git diff de arquivos gerados.

Para criar de forma eficiente um gitignore para projetos Python e Django, De Toptal gitignore.io pode ser um bom recurso para gerar um robusto .gitignore Arquivo.

Eu ainda recomendo examinar os resultados gerados você mesmo para garantir que os arquivos ignorados se adequem ao seu caso de uso e que nada que você queira ignorar seja comentado.

Teste contínuo com ações do GitHub

Se sua equipe trabalha no GitHub, configurar um processo de teste com Actions é uma tarefa fácil.

Os testes executados em um ambiente consistente em cada solicitação pull podem ajudar a eliminar os enigmas do tipo “funciona na minha máquina”. Eles também podem ajudar a garantir que ninguém fique sentado esperando que um teste seja executado localmente.

Um ambiente de CI hospedado, como GitHub Actions, também pode ajudar na execução de testes de integração que requerem o uso de recursos de serviços gerenciados.

Você pode usar segredos criptografados em um repositório para conceder ao executor do Actions acesso a recursos em um ambiente de teste, sem se preocupar em criar recursos de teste e chaves de acesso para cada um de seus desenvolvedores usar.

Já escrevi em muitas ocasiões sobre a configuração de fluxos de trabalho de ações, incluindo usando um para executar seu Makefile, e como integrar dados de evento GitHub. GitHub até me entrevistou sobre ações uma vez.

Para projetos Django, aqui está um fluxo de trabalho simples do GitHub Actions que executa testes com uma versão consistente do Python.

name: Run Django testson: pushjobs:  test:    runs-on: ubuntu-latest    steps:      - uses: actions/[email protected]      - name: Set up Python        uses: actions/[email protected]        with:          python-version: '3.8'      - name: Install dependencies        run: make install      - name: Run tests        run: make test

Para os comandos de instalação e teste, simplesmente usei o Makefile que foi verificado no repositório.

Um benefício de usar seus comandos Makefile em seus fluxos de trabalho de teste de CI é que você só precisa mantê-los atualizados em um lugar – seu Makefile! Não há mais “por que isso está funcionando localmente, mas não na CI ??!?” dores de cabeça.

Se você deseja intensificar seu jogo de segurança, pode adicionar Verificação de segurança do Django como uma ação também.

Configure seu projeto Django para o sucesso

Quer ajudar a manter sua equipe de desenvolvimento feliz? Configure-os para o sucesso com essas práticas recomendadas para o desenvolvimento do Django.

Lembre-se de que um grama de capacidade intelectual vale meio quilo de software.