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%-20s 33[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.