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

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: 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

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 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

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: 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: 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 do que, 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 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 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.