Get Started with DDEV - DDEV Docs

@Work Tools of Trade
, ,
1

Am mai scris acum câteva săptămâni într-un thread despre asta, dar cred că ar trebui să fie subiect nou, să știe mai mulți :slight_smile: (inspirat și de problema lui @Ekors)

Am descoperit DDEV, care este un fel de XAMPP pe steroizi:

  • rulează în docker
  • are un set-up util în majoritatea cazurilor [1]
  • suportă mai multe versiuni de PHP
  • etc

Dezvolt folosind DDEV de… o lună, dacă nu mai bine și sunt cât se poate de mulțumit de… orice:

  • xdebug funcționează fără probleme (trebuie să avem o discuție adiacentă este despre debuggers în curând :sweat_smile:)
  • performanța este semnificativ mai bună decât ce aveam în xampp. Pentru același cod am - în unele cazuri - timpi de execuție cu >10x mai mici.
  • funcționează mai multe site-uri simultan

Ce nu am reușit (până acum):

  • să configurez editorul să folosească PHP din DDEV (dar nici nu este o problemă prea mare, am încercat o dată, câteva minute, n-am reușit, aia a fost)
  • să rulez phpunit
  • să rulez/debug un script node - asta m-a durut, că a trebuit să fac debug cu console.log, ca barbarii…

Toate astea în ciuda faptului că în shell merg ok, dar nu în editor (dar pentru că merge în shell, nici aici nu mi-am bătut capul prea tare momentan)

Alternative:

  • devkinsta - recomandat de @dinu . L-am încercat sumar, este un blackbox, motiv pentru care nu mi-a plăcut. Pe de altă parte, a mers din prima, fără probleme.
  • wp-env - nu am reușit să-l adaptez nevoilor mele, dar știu oameni care-l folosesc cu succes
  • Lando - cred că l-am încercat la un moment dat; am un partener care-l folosește și e foarte mulțmit.

Performanța în Docker pe Windows

Am mai scris pe forum treaba asta: dacă ești pe Windows și vrei să rulezi ceva în Docker, rulează în Docker în WSL. Și dacă rulezi în WSL, asigură-te că fișierele sunt în filesystem-ul WSL (i.e. nu în /mnt/*). Da, acum are sens treaba asta, dar este o informație pe care am găsit-o menționată atât de rar încât consider că este un soi de open secret pe care se presupune că trebuie să-l știi…

  1. până la un anumit nivel, desigur. ↩︎

5 Likes
2

Ce sa-ti zic, ultima oara cand am incercat dezvoltare in php sub windows a fost acum 10 ani si mi s-a urat de ce smecherii trebuia sa fac pentru a-l face sa mearga. Nu zic, si pe Linux e intortocheata calea, dar nu am avut probleme sa nu mearga phpunit sau intl , pana la urma, pentru ca orice problema aveai mai erau X care au rezolvat-o. In special in ultimii 5 ani sa zicem, cand s-au mai asezat lucrurile. Acu am probleme cu nodejs pe mac, rezolvate, dar care-si arata coltii la cateva luni odata.

3

Câteva chestii, că au trecut vreo două luni de când folosesc DDEV:

Alias-uri și scurtături

Tot ce este executabil: php, composer, mysql, node, npm etc sunt rulate la modul ddev php sau ddev composer etc. Treaba asta devine enervantă, prin urmare am făcut câteva alias-uri în .bashrc:

alias reddev="ddev restart"

ssd(){
    currentRoot=$(ddev describe -j | jq -r '.raw.approot')
    currentDir=$(pwd)
    rel=$(echo $currentDir | sed -r "s|^($currentRoot)|/var/www/html|g" )
    ddev ssh -d "$rel"
}

xdebug(){
    xdebugStatus=$(ddev xdebug status)
    if [[ $xdebugStatus =~ 'disabled' ]];
    then
        ddev xdebug on
    else
        ddev xdebug off
    fi
}

npm(){ ddev npm "$@"; }
wp(){ ddev wp "$@"; }   

composer(){ ddev context-composer "$@"; }

Composer

Pentru că ddev composer rulează doar în root-ul proiectului, trebuie ori să mă conectez prin SSH ori să specific calea spre composer.json. Prin urmare, am făcut o comandă nouă, care ține cont de path-ul curent:

~/.ddev/commands/web/context-composer:

#!/bin/bash

## Description: Run context-composer inside the web container in the root of the project (Use --working-dir= for another directory)
## Usage: context-composer [flags] [args]
## Example: "ddev context-composer install" or "ddev context-composer require foo/bar" or "ddev context-composer --working-dir=my/custom/path require foo/bar"
## ExecRaw: true
## HostWorkingDir: true

composer "$@"

În mod normal se rulează cu ddev context-composer dar am pus alias-ul în .bashrc și îl rulez ca și cum l-aș rula nativ, cu composer ...

Versiuni PHP

Ca să schimb versiunea de PHP: ~/.ddev/commands/host/php-version:

#!/bin/bash

## Description: Display or set the PHP version
## Usage: php-version [version]
## Example: "ddev php-version"

currentVersion=$(ddev describe -j | jq -r '.raw.php_version')

if [ -z "$1" ]; then
  echo "Current PHP version is $currentVersion"
else
  if [ "$currentVersion" = "$1" ]; then
    echo "PHP version is already set to $1"
  else
    ddev config --php-version "$1"
    ddev restart
    echo "PHP version set to $1"
  fi
fi

Bonus, git hook care schimbă versiunea de PHP pe anumite branch-uri:

#!/bin/bash

php81_branches=("qa", "feat/GWD-586", "feat/GWD-589")
currentBranchName=$(git rev-parse --abbrev-ref HEAD)

if [[ ${php81_branches[*]} =~ (^"$currentBranchName") ]]; then
  echo "Setting PHP version to 8.1"
  ddev php-version 8.1
else
  echo "Setting PHP version to 8.0"
  ddev php-version 8.0
fi
1 Like
4

Integrarea cu PHP Storm

Am observat că PHP Storm face fițe când vine vorba de remote PHP interpreter. După ce am căutat de mi-a ieșit pe nas, am ajuns la două concluzii:

  • [1]: Numele proiectul NU trebuie să aibă puncte. Exensia DDEV pentru phpstorm pune punctul, dar nu ar trebui. i.e. în loc de ddev-foo.bar vei avea ddev-foobar
  • [2] → [3]: Din varii motive, PHP Storm nu găsește executabilul docker și este nevoie ori să bifezi include system env ori să setezi o variabilă PATH cu calea spre docker
  • [4]: extensia DDEV pentru PHP Storm nu setează numele executabilului corect, și de fiecare dată adaugă și versiunea (e.g. php8.0)

image
image1131×779 83.6 KB

2 Likes
5

nu vreau sa fiu rau, DAR.
xamp, lamp, fank, ddev, bdev, etc nu exista. n-au ce cauta. sunt mizerii care nu merg. dupa cum te plangi si tu. este extrem de usor sa-ti setezi mediul astfel incat sa mearga cu ce versiune de php vrei, am proiecte de la 5.4 pana la 8.x si ruleaza toate in paralel fara nici o problema. e extrem de usor sa-ti setezi debugerul si testele. nu-i nevoie 12343 scripturi care nu fac nimic, nu-i nevoie sa te mulezi dupa experienta unora care nu cred ca au vazut un proiect mai mare de hello world. hai sa zicem un todo copiat de la un video indian.

repet, nu vreau sa fiu rau. doar ca am avut destule probleme din cauza unora care au preferat sa folosesasca mizerii de genul asta in loc sa invete sa-si faca un mediu decent.

//end rant

2 Likes
6

Asta e asemănătoare cu „nu sunt rasist/antisemit/homofob DARRRR”. :sweat_smile:

Dar sunt de acord cu tine. 100%.

Până nu demult, tot set-up-ul meu era făcut de mine (chiar dacă am menționat xampp inițial, setup-ul era de fapt: nginx + 5 versiuni de PHP[1] + mariadb; cu ocazia asta am aflat că xampp nu este un termen generic, gen LAMP :sweat_smile:)

Problema a apărut când a fost nevoie să avem mai mulți devi un set-up cât mai asemănător, iar DDEV a fost cea mai la îndemână soluție. Niciunul dintre cei din echipă nu avut câteva ore de investit în a face toată jucăria să funcționeze corect pe toate mașinile.

Nu stăpânesc suficient de bine terminologia docker; de fiecare dată când am încercat să setez un proiect mă loveam de o problemă sau alta. Și faptul că am nevoie atât de rar de a seta singur chestii nu reprezintă o motivație foarte puternică pentru a aprofunda.

  1. de la 7.2, că aveam un legacy, la 8.1, că încercam chestii noi. ↩︎

1 Like