Diskuze: UPDATE webovej aplikácie na strane klienta
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
TomasGlawaty:6.7.2017 14:37
Ahoj,
Prvně bych chtěl podotknout, že je toto vcelku zajímavý dotaz 
Problém lze řešit mnoha
způsoby, tak zkusím popsat, jak bych to řešil já.
Předpokládám tedy, že máš:
- Několik klientů, každý má svůj web a každý z nich je samostatná instance (nebeží fyzických X webů na jedné [společné] fyzické administraci)
- Jeden typ CMS, který mají všichni tví klienti (připadně je to rozmodulované, každý z klientů ma jiné moduly)
- Píšeš, že to je v Laraveli, takže používáš Composer
Cílem je:
Upozornit klienta, že existuje nová verze tvého CMS, respektive některého
jeho modulu a chceš jeho souhlas s aktualizací.
Jestli má každý zákazník specifický web (frontend) delaný "na míru" (ačkoliv je administrace stejná), tak jako největší problém mě napadají BC breaks, kdy ty upravíš nějakou funkcionalitu, která může rozbít třeba jen některé z front aplikací tvých klientů.
Z CMS bych udělal samostatný balíček, instalovatelný Composerem - pokud tak již nemáš. Takže samostatný repozitář, případně jestli se jedná o modulární CMS (což hádám, že ano), tak aby každý z těchto modulů byl samostatným repozitářem. Aby bylo možné repozitář stahovat Composerem, tak musí být k nalezení na https://packagist.org/ (repozitáře by musely být volně dostupné, například na GitHubu). Ovšem, pokud by jsi chtěl využívat privátní repozitáře (např. na Bitbucketu, Gitlabu ad.), tak si potřebuješ na nějaké doméně rozchodit Satis a říct Composeru, že ma hledat také tam. Více o Satisu ZDE , měl jsem i nějaký CZ članek od Filipa Procházky myslím, ale nemohu ho již dohlledat.
Takže ve výsledku máš aplikaci klienta a tvoje adminsitrace je
dotahována composerem do vendoru. Dále se nabízí používat
třeba Databázové Migrace, kdy při stažení nějakého tvého modulu se
spustí migrace a vytvoří tabulky, případně číselníky, automaticky do
dané DB.
Jak bych aktualizace ideálně řešil?
Uživatelský souhlas bych neřešil. Pro všechny projekty bych využíval CI
(třeba Travis), kdy bych si nastavil, že po push do repozitáře se zavolá
build aplikace, spustí se testy (ano ty jsou potřeba, aby odhalily případně
chyby) a jakmile vše projde, tak se zaktualizuje ostrá, pustí se composer,
migrace atd.
Takže situace by vypadala nějak takto:
- Pošlu úpravy do repozitáře daného modulu z CMS
- Spustí se mi testy, připadně code-checking ad. - musí vše projít
- Klientských aplikacím, kde chci modul aktualizovat, upravím
composer.jsons danou verzi balíčku a pushnu změny - Spustí se mi build aplikace, testy. Jakmile vše projde, tak se
zaktualizuje repozitář na ostré (daná aplikace), spustí se
composer installa migrace.
Samozřejmě, že tohle je docela složitý proces vývoje a musíš
zvážít, jestli se ti to oplatí jak z časového hlediska, tak finančního
(Společnosti, které ti poskytují CI rozhraní si za to samozřejmě
nechávají platit ).
A také se o aktualizace prakticky staráš ty.
Dovedu si představit, že by se to dalo řešit i bez continuous delivery.
Například si na nějaké URL vystavovat aktuální verzi a pravidlně se z
aplikací doptávat - následně si tuto informaci uložit a zobrazovat
uživateli - po souhlasu si naplánovat cronjob, který spustí
composer update daného balíku. Může se pak ale stát, že
nějaká úprava něco specifického v klienské aplikaci rozbije a web pak
nepojede
+20 Zkušeností
Zobrazeno 4 zpráv z 4.