Vrei ca echipa ta să facă asta bucură-te fluxul de lucru de dezvoltare? Credeți că ar trebui să fie software de construcție distractiv și împlinitor existențial? Dacă da, aceasta este postarea pentru dvs.

Mă dezvolt cu Django de ani de zile și nu am fost niciodată mai fericit cu proiectul meu Django înființat decât sunt acum.

În acest articol, voi explica cum îmi fac o zi de dezvoltare cu Django cea mai relaxantă și mai plăcută experiență de dezvoltare posibilă pentru mine și echipa mea de ingineri.

Un instrument CLI personalizat pentru proiectul dvs. Django

În loc să tastați:

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

Nu ar fi mult mai frumos să tastați:

make start

… și toate acestea s-au întâmplat pentru tine? Așa cred!

Putem face asta cu un Makefile care se autodocumentează. Iată una pe care o folosesc frecvent când îmi dezvolt aplicațiile Django, cum ar fi ApplyByAPI.com:

SHELL: = / bin / bash include .env .PHONY: help help: ## Arată acest ajutor @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: local hooks: - id: markdownlint name: markdownlint description: "Lint Markdown files" entry: markdownlint '** / *. md' --fix --ignore node_modules --config "./.markdownlint.json" language : tipuri de noduri: [markdown]

Aceste cârlige verifică dacă există comiteri secrete accidentale, formatează fișierele Python folosind Negru, formatați fragmente Python în fișiere Markdown folosind blacken-docs, și lint Markdown files de asemenea.

Probabil că sunt disponibile și mai multe cârlige utile pentru cazul dvs. de utilizare: a se vedea cârlige susținute a explora.

Gitignore utile

O modalitate subapreciată de a îmbunătăți experiența zilnică de dezvoltare a echipei dvs. este să vă asigurați că proiectul dvs. folosește un sistem complet .gitignore fişier.

Acest lucru vă poate ajuta să preveniți comiterea fișierelor care conțin secrete și, în plus, poate economisi dezvoltatorilor ore de plictiseală, asigurându-vă că nu treceți niciodată printr-o git diff de fișiere generate.

Pentru a crea în mod eficient un gitignore pentru proiectele Python și Django, A lui Toptal gitignore.io poate fi o resursă plăcută pentru generarea unui sistem robust .gitignore fişier.

Încă vă recomand să examinați singur rezultatele generate pentru a vă asigura că fișierele ignorate se potrivesc cazului dvs. de utilizare și că nimic din ceea ce doriți să fie ignorat nu este comentat.

Testare continuă cu GitHub Actions

Dacă echipa dvs. lucrează la GitHub, configurarea unui proces de testare cu Actions este un fruct slab.

Testele care se desfășoară într-un mediu consecvent la fiecare solicitare de extragere pot ajuta la eliminarea problemelor „funcționează pe mașina mea”. De asemenea, pot contribui la asigurarea faptului că nimeni nu stă în așteptarea unui test pentru a rula local.

Un mediu CI găzduit, cum ar fi GitHub Actions, poate ajuta, de asemenea, atunci când rulați teste de integrare care necesită utilizarea resurselor de servicii gestionate.

Poți să folosești secrete criptate într-un depozit pentru a acorda alergătorului de acțiuni acces la resurse într-un mediu de testare, fără a vă face griji cu privire la crearea resurselor de testare și a cheilor de acces pe care fiecare dintre dezvoltatorii dvs. le poate folosi.

Am scris de mai multe ori despre configurarea fluxurilor de lucru Actions, inclusiv folosind unul pentru a rula Makefile, și cum se integrează datele evenimentului GitHub. GitHub chiar m-a intervievat despre Acțiuni o singura data.

Pentru proiectele Django, iată un flux de lucru simplu GitHub Actions care rulează teste cu o versiune Python consistentă.

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

Pentru instalarea și testarea comenzilor, am folosit pur și simplu Makefile care a fost verificat în depozit.

Un avantaj al utilizării comenzilor Makefile în fluxurile de lucru ale testului CI este că trebuie doar să le mențineți actualizate într-un singur loc – Makefile! Gata cu „de ce funcționează local, dar nu în CI ??!?” dureri de cap.

Dacă doriți să vă intensificați jocul de securitate, puteți adăuga Verificare de securitate Django ca și acțiune.

Configurați-vă proiectul Django pentru succes

Doriți să vă ajutați să vă mențineți echipa de dezvoltare fericită? Configurați-le pentru succes cu aceste cele mai bune practici pentru dezvoltarea Django.

Amintiți-vă, o uncie de putere cerebrală merită o kilogramă de software.