verzovat composer.lock nebo ne

kleinpetr
Člen | 480
+
0
-

Ahoj,

chtel bych se zeptat jak idealne resit git s composerem.

defaultne verzuju composer.json i composer.lock

kdyz si projekt pullnu v produkci, tak spustim composer install aby si dotahnul vendors, to je ok.

Ale ted prijde situace kdy budu chtit composer update. Jak spravne to resit, co jsem pochopil, tak prepisuje composer.lock a je nesmysl updatnout na localu → pushnout composer.json i lock, pak pullnout na serveru lock, ktery preci nepatri k moemtalni situaci na serveru. Nebo se pletu ?

Diky

Ondřej Kubíček
Člen | 494
+
+2
-

no v podstatě jak pišeš
composer install ti nainstaluje závislosti podle composer.lock

pak jednou za čas budeš chtít udělat update, updatuješ tedy závislosti, vyzkoušíš aplikaci, že s updatovanými balíčky appka funguje a pak můžeš nový composer.lock pushnout, server si teda updatuješ až potom co si otestuješ že to běží bezchybně

Felix
Nette Core | 1183
+
+1
-

U aplikaci by jsi urcite mel verzovat composer.lock, jinak nelze zarucit, ze aplikace funguje tobe i po nainstalovani na serveru.

Jak pise @OndřejKubíček, az budes chtit upgradovat zavislosti, u sebe provedes aktualizaci, vyzkousis a pak commitnes.

Šaman
Člen | 2632
+
+2
-

Zajistit composer install, tedy aby se ti nerozcházel composer.lock s reálně nainstalovanými knihovnami je úkol toho, kdo provádí deploy. Ideálně nástroje, který to zautomatizuje, stejně jako spustí třeba databázové migrace.

Příkaz composer update by se na produkci vůbec neměl zadávat – protože pak se ti mohou stáhnout novější verze, než se kterými pracovali vývojáři. A tyhle verze mohou obsahovat nové chyby, mohou porušovat zpětnou kompatibilitu apod. (Neměly by. Ale mohou.)

Editoval Šaman (30. 12. 2017 3:02)

kleinpetr
Člen | 480
+
0
-

Mockrat diky za vysvetleni, dava to smysl :)

David Matějka
Moderator | 6445
+
+6
-

nejlepsi je verzovat cely vendor ;) #protip