Jakou náhradu za PSpad? Potřebuji k práci FTP

PeterPP:
Skúšal si hľadať?

Ty edituješ kód přímo na FTP? Odnauč se tenhle zlozvyk.

PetraPP:
Asi bych zkusil Visual Studio Code, což je dobrý kompromis na půli cesty mezi textovým editorem a profesionálním IDE. Především je pro něj spousta pluginů, jako třeba ftp-sync, který by mohl řešit tvoje potřeby FTP deploymentu.

Kcko:
„Ty edituješ kód přímo na FTP? Odnauč se tenhle zlozvyk.“

Viem, že je to trochu od veci, ale zvedavosť mi nedovolí nespýtať sa: Aký postup možno pri úpravách považovať za najlepší?

Vždy som bol totiž zvyknutý robiť všetky zmeny najprv na localhoste a až potom ich (po skúške) preniesť do produkcie. Keď som však pred časom začal pôsobiť v brandži na plný úväzok a nastúpil do firmy, kolega mi hneď prvý deň povedal: „Otvor si FTP klienta, na súbor na FTP klikni pravým tlačidlom, daj editovať…“

Prekvapilo ma to a doteraz sa s týmto postupom celkom nestotožňujem. Napadá mi niekoľko nevýhod. Dve najväčšie:

• Ak mám plnohodnotný projekt na locali, môžem si ladiť v zásade čo chcem a ako chcem. V ostrej verzii musím buď kopírovať súbor, alebo patlať ladenie s parametrom v URL (čosi ako if (isset($_GET["atest"])) {echo "test";}).

• Vyhľadávanie. Pri takom množstve súborov a tak robustnom CMS, aké používame, potrebujem občas vedieť, odkiaľ sa berie daná funkcia, a potrebujem to vedieť čo najrýchlejšie. IDE mi ponúka možnosť Search in project, nepoužiteľnú kvôli editácii výlučne na FTP.

lionel messi:
„Aký postup možno pri úpravách považovať za najlepší?“
Mít kopii na localhostu považuji za minimum. Tedy pokud se bavíme o něčem profesionálním. Mám kamaráda, který má web s návštěvností tak jeden dva uživatelé za měsíc. Když tam chce něco dvakrát do roka upravit tak tam kvůli tomu taky nenasazuji CI. Stáhnu z ftp, upravím, nahraju. Ale to jen proto, že i kdybych to nějak moc podělal (jako že to moc ani nejde) a jeho web třeba den nejel, tak by mu to bylo jedno. Něco podobného bych si ale u klienta nedovolil.
Co se firem týče, tak tam by v procesu měl určitě být git. U jednotlivce to nehrozí ale ve firmě, pokud by dva upravovali na ftp stejný soubor, jeden by z toho nakonec moc šťastný nebyl, jelikož by o veškeré úpravy přišel. Udělat pak git pull na master větev na serveru je celkem jednoduché a je celkem malá šance, že se něco rozbije (zapomene se nakopírovat). Dalším krokem v procesu bych viděl Continuous Delivery. Tedy že to na server nenasazují lidé, ale nasazuje se to automaticky. V takovém případě, když se v master větvi objeví nová verze kódu, rozjede se automatizovaný proces, který vezme novou verzi kódu, může s ní něco udělat (třeba stáhnout veškeré potřebné závislosti atp.) a když je vše připraveno, nahraje nový kód na server. Dá se s tím vyhrát a udělat třeba zero downtime deployment, kde se změna z jedné verze na druhou provede atomicky. Tedy se nestane, že by uživatel dostal třeba novou verzi souboru index.php, ale soubor foo.php, který se do něj includuje je ještě ve staré verzi jelikož se stále nahrává a proto to způsobí nějaký error. Nedůležité stránky s malou návštěvností to trápit nemusí, ale weby, které obsluhují traffic v řádu několika requestů za vteřinu to už řešit musí. Mimochodem, tohle je úroveň kterou používám já. Vývoj na localhostu, kód v gitu s využitím feature větví. Má činnost končí mergnutím pull requestu do master větve. Pak už to jede automaticky až do nasazení nové verze. Včetně zero downtime i když mé projekty nejsou zas až tak důležité, aby to byla nutnost. Nastavení to systému mi zabralo asi týden práce, protože jsem většinu těch služeb nastavoval poprvé, ale teď už se o to vůbec nemusím starat. Kdybych to měl dělat znovu, zabere mi to tak odhadem den.
Nicméně dá se jít ještě dále. Spousta firem nemá jen jedno prostředí (produkční server) ale má jich více. V minulé práci jsme měli docela dost verzí. Měli jsme server, kam se nahrával kód z feature větví. Každý commit. To bylo jen pro vývojáře a nevadilo, pokud se ta nějaká určitá verze rozbila, že vůbec nefungovala. Bylo to hlavně na to, že i když jsme se snažili mít localhost co nejpodobnější serveru, odlišnosti tam byly a tohle bylo takové pískoviště pro vývojáře kde si mohli otestovat, že to co funguje u nich funguje taky na serveru. Pak jsme měli prostředí, kam šly už hotové vyvinuté a funkční celky. Tam už by mělo téměř vždy vše fungovat. Kdyby se to nepovedlo a něco se předtím přehlédlo, tak to závažný problém nebyl ale snažili jsme se to držet vždy ve funkčním stavu. Tohle sloužilo hlavně pro projekt managera aby věděl, jak to vypadá a mohl si to osahat. Když jsme měli s vývojem hotovo, tak to šlo na server ke kterému mu měl přístup klient. Mohl si tam novou verzi vyzkoušet, připravoval na ní nová data do databáze atp. No a po odsouhlasení klientem šla ta verze teprve do produkce. Tohle jinak než automatizovaně už dělat nejde. Navíc třeba produkční prostředí nebyl jen jeden server. Bylo to spousta serverů. Na začátku byly 2 loadbalancer servery. Ani ne tak kvůli rozdělování zátěže jako spíš kvůli redundanci, kdyby jeden z nich vypadl. Pak následovaly dva servery, které terminovaly https. Pak tam byly servery které se staraly jen o servírování statických souborů no a nakonec pool serverů, na kterých běžely scripty. Pak mimo byly servery, které se staraly o asynchronní operace (časově náročné operace jako třeba rozesílání emailů, resize obrázků, generování pdf, předpočítávání cen do keše, atp.) no a samozřejmě pool serverů s databázemi. Největší sranda na tom je, že některá část kódu byla na nějakém serveru, jiná část kódu zase na jiném. Taky stejná část kódu byla na rozkopírovaná na více fyzických serverů.
K tomuto jsem se nikdy nedostal ale je to další level, co některé firmy používají - testy. Druhů testů je spousta a v celém tom procesu se vyskytují různě. Mají společné to, že většinou se pouštějí a vyhodnocují automaticky a pokud se objeví nějaký problém, nemůže se kód posunout v procesu dále dokud se ten problém neopraví a testy nezačnou procházet. Ty testy nemusí být jen na samotnou funkčnost kódu, některé mohou kontrolovat i třeba jen to, jak je ten kód zapsaný. Jsou firmy které mají definovaný code style a automatické nástroje, které nedovolí vývojářům commitnout nebo mergnout kód, který tyto standardy nesplňuje. Do procesu taky může být zařazen code review, takže kód před mergnutím kromě automaticých testů musí projít a schválit jeden další nebo i více dalších vývojářů.

Co je nejlepší se říct nedá. Záleží co je to za projekt, jak je velká firma, kolik na tom dělá lidí atp. Čím větší, tím větší nároky. Pokud bych byl nezávislý vývojář a dělal projekty ve stylu one man show, určitě bych za minimum považoval localhost a git.

Já používám Notepad++, spousta pluginů. Využívám hlavně XML, Json, ale je tam i spusta dalšího. A práce s ftp je tam samozřejmostí (taky plugin).
Plus obarvování syntaxe dle zvoleného jazyka (xml, java…)

lionel messi:
Způsob, kterým jsi byl zvyklý pracovat, je v dnešní době minimální možný, pokud na projektu děláš sám (a jedná se tedy o klientský projekt, nikoliv projekt se 2 návštěvami týdně).

Naopak způsob, který razí tvůj zaměstnavatel, je hodně divný a nevím, jak může fungovat na projektu více lidí. Jak nasazujete větší balíky změn bez jakékoliv automatizace? Co když se změna na serveru nepovede? Těch otazníků tam je mnoho. Vzal bych nohy na ramena, dokud je po vývojářích na trhu hlad...

PetraPP:
Jak by sis podobný nástroj představoval? Ne, tak, jak si to představujes, to nefunguje.

Na tvé úrovni bastleni stylem FTP klienta v editoru nic nevymyslis. Musel by ses přepnout o několik levnou dal, pak by byla relevantni odpověď [#7]. Jen podotknu, ze to ani tak nebude “z webu na localhost”, ten směr je vždy opačný.

Tomášeek:
„ten směr je vždy opačný“

Pro uživatelská data (plněný obsah databáze, uploadované soubory) se občas používá i směr
ostrý server -> záložní či testovací server

PetraPP:
Pro zautomatizování záloh souborů a databází se většinou používají dávky psané na míru. V nich můžete použít např. nástroje mysqldump nebo rsync, pokud to hosting umožňuje zapnout.

Kajman:
> občas používá i směrostrý server -> záložní či testovací server
Tady potom akorát pozor s jakými (a komu patřícími) daty pracujete. Dneska je velmi běžným standardem pro firmy co chtějí být konkurenceschopné mít ISO27001 a tam se tenhle směr buď "zakazuje", nebo podléhá nutně vydefinovaným retention politikám. Domnívám se, že proto je lepší už od začátku ten směr "testovacího serveru s produkčními daty" neuvažovat.

Keeehi, Tomášeek:

Ďakujem veľmi pekne za odpovede.

PetraPP:
Lehce jsem se na to teď díval a to, že to neumí vytvořit složky mě celkem překvapuje (jinak to vypadalo jako dobrý plugin). Obdobou je ftp-simple, které funguje tak, že si před začátkem práce je potřeba vytvořit pracovní kopii FTP a pak po úpravách je zase třeba vybrat, co a jak kam uložit. Dost krkolomné.

Možná běžte do toho WinSCP - nastavíte si v něm někde defaultní editor (např. ten VS Code) a ono by to mělo fungovat. Dle Vašich požadavků to asi bude nejlepší volba.

PetraPP:

Tým FTP klientom, ktorého spomínam v [#5] je práve WinSCP.

„co je nutné nastavit?“

Na nič ďalšie si momentálne nespomínam. Len pozor na to, že niektoré editory, resp. IDE sa správajú tak, že zmeny v súbore uložia aj bez toho, aby užívateľ fyzicky zadal pokyn na uloženie - deje sa to napríklad vtedy, keď edituješ súbor a prepneš sa do okna iného programu (správa sa tak napr. PHP Storm, zrejme sa to dá ovplyvniť nastavením IDE).

PetraPP:
„přidala externí editor visual studio code. Jak to funguje dál, co je nutné nastavit“
Pravděpodobně nic, WinSCP by měl uploadovat soubor po každém uložení.

PetraPP:
„Myslela jsem si, WinSCP“
Myslel, myslel... myslet znamená houby vědět.

WinSCP je FTP jen klient, žádnou magickou složku vytvořit neumí. Sakra, chlape, zkus u toho trochu přemýšlet - jak by to asi dle tebe fungovalo, jak by „danou složku propojil s FTP“?

PetraPP:
Nepoužívám, tak je tipuju. Ve WinSCP si najdeš na FTP soubor, který chceš editovat, otevřeš ho. Díky nastavení externího editoru se otevře ve Visual Studio Code. Po úpravě ho uložíš a on se automaticky nahraje. Procházet další soubory ve VS code spíš nepůjde.

Tomášeek:
„jak by to asi dle tebe fungovalo, jak by ‚danou složku propojil s FTP‘?“
Operace čtení / zápis by se nezapisovaly na disk, ale volaly se při nich pod pokličkou FTP příkazy. Na linuxu to dělá curlftpfs, na windows o něčem podobném nevím.

Mám pocit že tvým základním problém je to, že máš dva protichůdné požadavky na jednu stranu chceš používat IDE které prostě potřebuje mít lokální kopii souborů aby mohlo efektivně fungovat, na druhou stranu nechceš mít lokální kopii souborů. Tak až se rozhodneš co z toho je pro tebe důležitější, tak ti budeme schopni poradit.

PetraPP:
Toto se běžně řeší např. přes git, který ví, jaké změny a ve kterých souborech byly provedeny. Vyžaduje ale to něco málo nastavení i na serveru. Případně se to dá řešit např. přes grunt ftp deploy, ale není to ideální řešení.

PetraPP:
Git je běžně používaný nástroj. Bohužel nevím, jak by se dal použít automatizovaně i pro upload na FTP. Možná někdo zná nějaký nástroj co v kombinaci s gitem to zvládne, já ho bohužel neznám.

Další možností je github.com/dg/ftp-deployment
To si taky udržuje seznam souborů, které byly nahrány a uploaduje jen změny (nové soubory, upravené soubory, smazané soubory)

PetraPP:
„Není nějaký nástroj, program, který dokáže rozeznat změnu v souboru a třeba po týdnu nahrát na FTP jenom soubory, které jsem opravdu změnila?“

WinSCP umí synchronizaci souborů (aktualizaci), tzn porovnat datumy a časy poslední změny a nahrát na server jen ty novější.
Už si moc nepamatuju jak se to nastavuje. Je potřeba se dostat k tomuto dialogu:


A pak dole kliknout na transfer settings a vytvořit nový profil

A tam zaškrtnout možnost New and updated files only.

No a pak se vrátit k původnímu dialogu "Synchronize" a tam vybrat ten nový profil a dát "Ok". (nebo případně upravit výchozí profil, tak nebude potřeba pokaždý vybírat profil, ale zase se tím příjde o možnost nastavit pro každé webovky jiný exclude files atd., kdyby to k něčemu bylo, třeba aby to zbytečně neporovnávalo složku se staženými knihovnami, které se stejně nebudou nikdy upavovat atd.)

Nejdřív to porovná všechny soubory v nastavených adresářích (lokálním a vzdáleném) a pak zobrazí seznam změněných / nových souborů, a po potvrzení je nahraje.
Takový nástroj mi teď na Xubuntu celkem chybí.

Ano, mohou být i na síťovém disku. Můžete pak pozorovat delší prodlevy při některých operacích.

Ale pokud prostě toužíte ladit na jiném serveru a nemít lokálně spuštěný webserver, tak winiscp umí i po té zmíněné synchronizaci souborů spustit hlídání změn v souborech na disku a nahrávat hned na server změny (Příkazy - Udržovat vzdálený adresář aktuální).