FTP není cesta
Když chce náš zadavatel vidět ukázku hotové práce, či tester brečí, že nemá co testovat, není nic jednoduššího než prostě otevřít to FTP, překopírovat data na webhosting a hotovo. Tester nám to otestuje, zjistí, že jsou tam chyby (ještě aby nebyly), my je opravíme a znovu vypublikujeme.
Vše super až do okamžiku, než tam pošleme tak rozbitou aplikaci, že prostě neběží vůbec a my okamžitě musíme vrátit tu minulou verzi. No jo, ale na jaké verzi to minule běželo? Pamatuje si to někdo z vás? Copak z FTP zjistím, jaká tam byla verze? Ooops.
Git na server nepatří
Ok, tak FTP cestou jsme se ještě zatím nevydali, rovnou jsme šli na “level 2”. Na server vlezu přes SSH, projekt nainicializuji pomocí git clone a všechny updaty projektu jsou pak jen “git pull”. Když je třeba něco víc, tak to zaobalím shell scriptem, který to “všechno udělá”. Stáhne novou verzi z gitu, aktualizuje composer, promaže cache a jede se.
Celý deploy je pak jen SSH na server a spustit /projekt/deploy.sh. Prostě úžasně jednoduché a snadné. Ale má to tři zásadní nevýhody. Jednak pokud každá aplikace běží na jiném serveru, pořád jen lovíte to správné SSH a vzpomínáte, kam máte vlastně jít a co dělat. Tak ty data zapíšeme do wiki a problém solved ?
…až do doby, co ten jediný v týmu, který doteď měl odvahu na to, aby na serveru na ostré pouštěl ty scripty, o kterých nikdo neví, co udělají, a modlil se u toho, že to dopadne a aplikace pak ještě poběží, třeba onemocní a není nikdo jiný, kdo by to uměl udělal. No a tester stojí a kouká do stropu, protože nemá co dělat. Ale tak jo, zaškolíme dalšího. Přemluvíme toho windowsáka, co si myslí o linuxu, že je to nadávka, vše mu pečlivě vysvětlíme a naučíme, aby, až zase dostaneme rýmičku, byly projekty jako v bavlnce.
Takhle to docela funguje, až na to, že ty deploye jsou otravná věc a zdržuje to. Několikrát denně na server, aktualizovat projekt, vrátit se k práci, aby za hodinu zase…? Prostě jak “u blbečků na dvorečku”. Nešlo by to, aby se to na ty servery dostalo nějak samo? Proč by programátor, měl aplikaci deployovat? To přeci není naše práce, nás to zdržuje a otravuje. Ale zase ono to přece funguje, tak to tak necháme.
Společná řeč s adminem
Takhle se vesele jede do doby, než přijde rána z čistého nebe. Přijdou za vámi admini a oznámí, že SSH na produkční server na projekt XYZ dát nemohou z bezpečnostních důvodů. Proč by taky měl mít programátor přistup k produkci. Jednak se potom neustále dohadujete, kdo aplikaci rozbil, zda špatný deploy, nebo admini jejich aktualizacemi. Kromě toho taky nechceme, aby programátoři měli přístup k ostré databázi a jiným službám.
Po několika týdnech dohadů ty přístupy stejně nedostanete a všechna jistota je pryč. Prý jim máme dávat aplikace v podobě deb balíčku a oni si to nainstalují sami. PHP jako deb balíček? To myslí vážně? Oni ti admini asi v životě neviděli webovou aplikaci. Kdo to kdy slyšel, aby se webové aplikace publikovaly jako deb? A jak asi udělám nějaký balíček? …..
Po vystřízlivění a zjištění, že fakt není jiná možnost, nakonec zjistíme, že vytvořit deb balíček jde plně automatizovaně. Takét to má tu výhodu, že vím přesně, na jaké verzi aplikace jedu a pokud potřebuji “rollback”, jen udělám downgrade balíčku.
Plná automatizace je správná cesta
Přešli jsme tedy na “level 3”. Po push do repozitáře se spustí v GitLab-CI, které stáhne závislosti z composeru, spustí testy, sestaví deb balíček a pošle ho do apt-repository a dle git-branch rovnou ten balíček ihned na serveru nasadí (pokud má SSH [test či devel]).
Deploy u nás tedy probíhá tak, že prostě pošleme svůj kód do gitu, provedeme code-review a následně si mergneme větev do testu (develu dle libosti). V ten okamžik má test/devel verze ihned novou verzi a “křeček tester zase může testovat jak divej” a nás to nezdržuje v práci. No a až je aplikace hotová a je třeba ji nasadit na produkci, jen napíšeme, ať admini nainstalují verzi balíčku x.y.z a dál se o to nestaráme.
Jak jsme mohli žít bez automatického deploye pomocí deb balíčků?
Vývojový tým vshosting~