Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Michal Šiman 06. 11. 2015, 08:18:30
-
Ahoj, prosim vas o vas nazor / zkusenost / radu. Programuji (resp. trosku skladam kod dohromady) intranetovou aplikaci, proste frontend nad zhruba 80ti tabulkami v MySQL. PHP jsem se zacal ucit sam od sebe pred hodne a hodne lety. Koduju zpusobem, ze jsem pripojeny primo na produkcni server pomoci SFTP a upravuju PHP soubory primo tam. Udelam zmenu a hned si ji vyzkousim. Ale uz me to moc nevyhovuje a hlavne vim ze to neni dobre. Predstavoval bych si neco jako subversion, ale nevim jak to potom davat na to SFTPko ... resp. jestli me popisete, nastinite, jak se to ma delat spravne profesionalne ... mit dva servery? Jeden vyvojovej, jeden produkcni? Jak to pak dostat z vyvojoveho na produkcni? Atd. diky.
-
Ahoj, prosim vas o vas nazor / zkusenost / radu. Programuji (resp. trosku skladam kod dohromady) intranetovou aplikaci, proste frontend nad zhruba 80ti tabulkami v MySQL. PHP jsem se zacal ucit sam od sebe pred hodne a hodne lety. Koduju zpusobem, ze jsem pripojeny primo na produkcni server pomoci SFTP a upravuju PHP soubory primo tam. Udelam zmenu a hned si ji vyzkousim. Ale uz me to moc nevyhovuje a hlavne vim ze to neni dobre. Predstavoval bych si neco jako subversion, ale nevim jak to potom davat na to SFTPko ... resp. jestli me popisete, nastinite, jak se to ma delat spravne profesionalne ... mit dva servery? Jeden vyvojovej, jeden produkcni? Jak to pak dostat z vyvojoveho na produkcni? Atd. diky.
Pořiďte si vývojové prostředí Phpstorm, to to udělá za vás. A máte po starosti. Potřebné příkazy se můžete doučit až podle potřeby, nebude-li něco fungovat jak má. Prakticky to může vypadat tak, že si založíte nový projekt ze souborů na serveru, upravujete ho na svém počítači, a jste-li s výsledkem spokojen, uploudujete změny na server. IDE umožňuje porovnávat soubory ze serveru s lokálními, zobrazovat soubory, které se změnily atp. A hlavní výhoda, kód můžete krokovat v debugeru.
Samozřejmě umí Vagrant, nebo SVN, Git a další vymoženosti.
Zajímavá je taky možnost používat remote compiler, který vám zajistí stejné lokální php prostředí (verze, nastavení php.ini) jako na serveru. Vyhnete se tak překvapení, že něco lokálně funguje a na serveru po překopírování ne.
-
Běžný (ale ne jediný možný) postup:
- vyvíjíte na svém pc, kde máte spuštěné potřebné služby (Apache, Mysql, ...)
- všechny změny průběžně zanášíte do repositáře zdrojových kódů (git, fossil, mercurial, ...)
- když máte hotovou sadu změn, označíte verzi v repositáři tagem dle smluvené konvence (1.0.0-rc1)
- na tuto verzi updatujete na testovacím serveru, kde se otestuje, že vše funguje správně
- teprve pokud je vše ok, aktualizujete tag (1.0.0) a na tuto verzi updatujete i na produkčním serveru
- pokud není vše ok, provedete opravu a znova testujete novou verzi (1.0.0-rc2)
- změny v databázi máte uloženy v repositáři jako sql soubory a v databázi máte tabulku, kam si ukládáte, které změnové soubory byly vykonány (aby nebyl sql soubor vykonán opakovaně)
Toto je asi nejjednodušší vývojové schéma, které drží učitou štábní kulturu. U složitějších projektů, kde spolupracuje řada systémů různých dodavatelů apod. je to složitější (integrační testy a další). Některé frameworky vývojová mohou některé kroky automatizovat (například provést migraci databáze na novou verzi schématu). Důležité je především chápat princip, konkrétní postup se dá vždycky doučit.
-
1) na svem PC mit linuxovy virtual ve kterem budes mit verze SW aspon zhruba stejne jako na produkcnim serveru. proc takhle? delat php na widli je nesmysl kvuli cp-1250. dale samozrejme si do dokazes prostym zkopirovani jednoho souboru kamkoliv prenest nebo zalohovat.
2) zcela jiste pouzivat git. je to jednoduche. jestli jsi sam tak ti staci commit, push, pull. casem pridas vetve.
3) nejak si vyresit fungovani updatu ve smysl nekde mit treba cislo nejake verze a system aby to umel detekovat a provest urcte kroky.
4) zkouset muzes jednoduse obnovenim puvodni DB a aplikaci update skriptu u sebe. rozhodne to nedelat na produkcnim serveru. na vetsi projekty kde je zivy vyvoj se pouziva jeste stage prostredi - tam aplikujes zmeny, das zazkaznikovi ke schvaleni a pak teprve je davas na ostry.
-
Jen dodám k již zde řečenému
* kvalitní vývojové prostředí (např. již zde zmíněný phpstorm).
* kvalitní vývojové prostředí
* kvalitní... :-)
* stejné/podobné verze SW - samozřejmě to vyvíjet v linuxu, nejlépe na podobné distribuci s koncovým serverem
* verzované klíčové konfigy (zrovna např. ten php.ini), v systémech (devel i production) mít symlinky na verzované soubory.
* pravidelně (např. každou noc) si stahovat DB/soubory na vývojářský stroj, abys vyvíjel rovnou na ostrých datech. DB může být vhodné/nutné při nalévání na devel z bezpečnostních i praktických důvodů "obfuskovat" (měnit emailové adresy uživatelů na tvoje, sjednocovat hashe hesel, atd.), to zajišťuje rovnou aktualizační skript
* Nejlépe mít ještě bokem ten staging, kdy se to prohlédne a schválí.
* Změny struktury DB samozřejmě řešit při nasazení automaticky (jak tu již bylo popsané), jinak budou vznikat chyby
-
... všechny změny průběžně zanášíte do repositáře zdrojových kódů (git, fossil, mercurial, ...)...
Ten fossil fakt používáš? Nebo znáš někoho, kdo ho používá?
-
Este doplnim, ze git ti vie urobit zip ktory bude obsahovat vsetky zmenene subory a to potom preplacnes pocas planovaneho releasu (mimo prac doby ..). Z toho vyplyva, ze aj na zmeny v db by si mal mat migracne skripty.. A hlavne si ved nejake tickety, aby si vedel aj o rok na co si robil danu zmenu v kode. (kukni si github, tam to uvidis)
-
... všechny změny průběžně zanášíte do repositáře zdrojových kódů (git, fossil, mercurial, ...)...
Ten fossil fakt používáš? Nebo znáš někoho, kdo ho používá?
Ano, fossil používám na vlastní menší projekty, kde dělám většinou sám. Výhodou je předevsím geniální jednoduchost - repositář je prostě sqlite soubor a server je jeden spustitelný binární soubor. Ten zajišťuje přístup k repositáři, obsluhuje web ui atd. Nic jednodužšího na správu a nasazení už asi nemůže být.
Ale myslím, že se fossilu dá věřit i pro větší nasazení. Není sice moc rozšířený, ale používá ho například SQLite, jeho mailing list je velmi živý, stále se vyvíjí a dost lidi ho používají dlouhodobě i na větší projekty. Já sám ho používám léta na linuxu a windows a zatím jsem neměl ani jeden problém. Akorát toho moc nečekejte od zabudovaného wiki+bugtracking systému, ten toho moc neumí.
Před nasazením si samosebou doporučuju zjistit podrobně vlastnosti, poptat se na mailing listu a podobně. Rychlé srovnání s gitem je třeba zde http://fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki
-
... všechny změny průběžně zanášíte do repositáře zdrojových kódů (git, fossil, mercurial, ...)...
Ten fossil fakt používáš? Nebo znáš někoho, kdo ho používá?
Ano, fossil používám na vlastní menší projekty, kde dělám většinou sám. Výhodou je předevsím geniální jednoduchost - repositář je prostě sqlite soubor a server je jeden spustitelný binární soubor. Ten zajišťuje přístup k repositáři, obsluhuje web ui atd. Nic jednodužšího na správu a nasazení už asi nemůže být.
Ale myslím, že se fossilu dá věřit i pro větší nasazení. Není sice moc rozšířený, ale používá ho například SQLite, jeho mailing list je velmi živý, stále se vyvíjí a dost lidi ho používají dlouhodobě i na větší projekty. Já sám ho používám léta na linuxu a windows a zatím jsem neměl ani jeden problém. Akorát toho moc nečekejte od zabudovaného wiki+bugtracking systému, ten toho moc neumí.
Před nasazením si samosebou doporučuju zjistit podrobně vlastnosti, poptat se na mailing listu a podobně. Rychlé srovnání s gitem je třeba zde http://fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki
PS: Jo a nevýhodou pro někoho může být, že se používá pouze přes příkazovou řádku. Pro prohlížení má docela dobré webové UI, ale to se pochopitelně nehodí pro samotnou práci s kódem. Nějaké pokusy o UI sice existují (https://fuel-scm.org/fossil/index), ale nevidím důvod pro jejich používání.
-
Ahoj, prosim vas o vas nazor / zkusenost / radu. Programuji (resp. trosku skladam kod dohromady) intranetovou aplikaci, proste frontend nad zhruba 80ti tabulkami v MySQL. PHP jsem se zacal ucit sam od sebe pred hodne a hodne lety. Koduju zpusobem, ze jsem pripojeny primo na produkcni server pomoci SFTP a upravuju PHP soubory primo tam. Udelam zmenu a hned si ji vyzkousim. Ale uz me to moc nevyhovuje a hlavne vim ze to neni dobre. Predstavoval bych si neco jako subversion, ale nevim jak to potom davat na to SFTPko ... resp. jestli me popisete, nastinite, jak se to ma delat spravne profesionalne ... mit dva servery? Jeden vyvojovej, jeden produkcni? Jak to pak dostat z vyvojoveho na produkcni? Atd. diky.
Skoro vsetko uz zaznelo.
Ked mas SFTP so shellom, tak tam lahko spravis git repozitar (git init --bare), do neho nahrajes subory a pomocou post-commit hooku zaistis, ze na serveri bude vzdy bezat napriklad vrchol nejakej branche. Ini robia to, ze si tam checkoutuju tag, co je mozno lepsie spravovatelne, ale zase nie je taka istota, co bezi na serveroch.
Subory sa tam dostanu tak, ze pri pushi sa tam prenesu diffy a post-commit hook zaisti deploy zmien.
Ako uz bolo pisane vyssie, hodi sa vyvijat lokalne a pripadne commitovat si do svojej branche. Ked sa rozhodnes, ze uz je to dobre, tak mergnes rozpracovanu branch do tej, ktora je vidiet na serveri. Vychadzaju z toho isteho, takze nejake konflikty nehrozia.
Pri uzivatelskom testovani sa hodi aj dalsi (testovaci) server, kde bude dalsia branch.
-
Ked mas SFTP so shellom, tak tam lahko spravis git repozitar (git init --bare) ...
Tohle přece vůbec nepotřebuje - ten vzdálený repozitář si může udělat třeba na Bitbucketu, ale určitě ne na produkčním serveru.
-
bitbucket ma privatne repository zadarmo
-
hlavne bitbucket pro vlastni server je do 10 useru v podstate zadaco. ja ho nasadil jeste v dobe kdy jsem delal jen sam a v kombinaci s jira agile (taktez skoro zadaco) je to nedocenitelne.
-
Dobry den,
dekuji vsem za navody/rady/napady a hlavne zkusenosti. Par veci jsem si z toho vybral. Pro me je trosku problem, ze produkcni ostra databaze ma 80 tabulek, celkem je v ni jiz nekolik milionu zaznamu a hlavne, pracuje se s ni nonstop, sbiraji se tabulky vyroby (kdo, kdy, kde a jak) a mame ve firme nonstop provoz, takze delat nejake upravy je celkem slozite, stejne tak jako kopirovat si celou databazi k sobe na vyvojovy server. Nejake zkusenosti/tipy s timto (myslim nonstop provoz)?
-
Delam s Drupalem, takze mnohe z toho vychazi...
1) je myslim obecne dost fajn mit v kodu nejak definovany popis struktury databaze
2) je myslim obecne dost fajn mit v kodu nejaky mechanismy pro updates
3) 80 tabulek je nic
4) velike urcite nejsou vsechny tabulky -> komplet export struktury, komplet export mensich tabulek, u tech nejvetsich tabulek delat export jen pro x zaznamu (jak jiz bylo zmineno, mame tam treba i nahrazani uzivatelskych mailu kdyz ma jit DB mimo tym)
5) testovat, testovat, testovat (mysleno ty updaty)
6) proces nasazovani updatu mam vyrazne urychleny tim, ze mame Drush = Drupal Shell. Proste nemusim pro vykonani update vubec na web, delam vse v terminalu coz ma vyrazne nizsi naroky, je to rychlejsi a vetsina limitu nastaveni PHP ma pro CLI hodnotu 0 (neomezene)
7) vetsina zajimavych veci ktere by bylo mozno poradit tak clovek vidi az s konkretnim projektem
-
Že je databáze obsáhlá a v nonostop provoz, to nic zásadního na již řečeném nemění. Možná jen připomenu, že je možno databázi replikovat a že to chce používat transakce všude, kde to je možné.
Jinak se mi nějak nezdá, že by taková obsáhlá aplikace neměla vývojový cyklus už nějak pořešený, zvlášť pokud na ní stojí nějaký nonstop provoz? To se při nonstop provozu opravdu vrtáte v běžící aplikaci?? To mi nějak nehraje.
-
Jinak se mi nějak nezdá, že by taková obsáhlá aplikace neměla vývojový cyklus už nějak pořešený, zvlášť pokud na ní stojí nějaký nonstop provoz? To se při nonstop provozu opravdu vrtáte v běžící aplikaci?? To mi nějak nehraje.
Už jsem na takové aplikaci také dělal a bylo to docela v pohodě. Bylo mi jen řečeno, do kterých tabulek nemám zasahovat a že z nich můžu jen číst. Přitom se do nich permanentně zapisovalo a všechno běželo normálně. Chce to jen "naučit se chodit v porcelánu".
-
Synchronizovat každou noc i 100GB DB na devel stroj není v dnešní době žádný problém. A to trochu pochybuji, že bude tak velká.
Samozřejmě to vyžaduje mít replikovanou kopii, ale u tak kritického nasazení mysql bych replikaci alespoň na dva stroje považoval za samozřejmost. Když se pak jeden shodí kvůli rsyncování datadiru na devel stroj, aspoň jeden slave musí zůstat v provozu, zasynchronizovaný. Máme DB 80GB, 900 tabulek a noční rsync změn v innodb souborech tabulek po gigabitové síti trvá i s následnou obfuskací dat na jednu vývojářskou stanici 20 minut.
Před pár dny jsme koupili repasy tiché pracovní stanice Dell T5500 2 x 4 jádra xeony s 24GB RAM (72GB max) za 11.500 Kc, doprava z Berlína 15 EUR. Plus dva SSD disky po pár tisících a výkon každé devel stanice se blíží produkčním serverům. HW pro vývoj je dnes skoro zadarmo.