abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 02:22 | Nová verze

Byla vydána verze 11.8 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností i s náhledy v příspěvku na blogu. Zdůraznit lze například SAST (Static Application Security Testing) testování JavaScriptu.

Ladislav Hagara | Komentářů: 2
dnes 02:00 | Zajímavý projekt

Neziskové technologické konsorcium Linux Foundation oznámilo, že nejnovějším oficiálním projektem konsorcia se stává ELISA (Enabling Linux In Safety Applications). Clem projektu je usnadnit společnostem vývoj a certifikaci kritických aplikací a systémů postavených na Linuxu, tj. aplikací a systémů, jejichž selhání může vést ke ztrátě lidských životů, k významným škodám na majetku nebo škodám na životním prostředí.

Ladislav Hagara | Komentářů: 1
včera 14:55 | Zajímavý projekt

Vyšlo piate číslo Magazínu KPI — webového časopisu Katedry počítačov a informatiky Technickej univerzity v Košiciach. V čísle sú články o vizualizácii dát v jazyku Python, nástroji Docker, a použití protokolu MQTT.

sergejx | Komentářů: 3
včera 10:44 | Nová verze

Po dvou a půl měsících vývoje od vydání verze 5.0 byla vydána nová verze 5.1 svobodného open source redakčního systému WordPress. Kódové označením Betty bylo vybráno na počest americké jazzové zpěvačky Betty Carter.

Ladislav Hagara | Komentářů: 0
21.2. 16:11 | Bezpečnostní upozornění

V Linuxu byla nalezena bezpečnostní chyba CVE-2019-8912. Jedná se o vážnou (CVSS v3.0: 9.8) bezpečnostní chybu typu CWE-416: Use After Free v crypto/af_alg.c. Chyba byla nalezena pomocí detektoru chyb při práci s pamětí KASAN (Kernel Address Sanitizer).

Ladislav Hagara | Komentářů: 5
21.2. 11:11 | Komunita

Mozilla.cz informuje, že další vydání SeaMonkey se zdrží. Infrastruktura projektu SeaMonkey prochází mnoha změnami. Důvodem je požadavek na nezávislost na infrastruktuře Firefoxu do konce roku, protože jeho vývoj nebude SeaMonkey následovat ve stejném tempu a rozdíly jsou moc veliké. Bohužel se při těchto přesunech nepodařilo udržet vše ve funkčním stavu a tak není možné sestavovat a vydávat nové verze SeaMonkey.

Ladislav Hagara | Komentářů: 0
20.2. 16:55 | Bezpečnostní upozornění

V Drupalu byla nalezena vysoce kritická zranitelnost PSA-2019-02-19. Podrobnosti a opravy 8.5.x a 8.6.x budou zveřejněny dnes mezi 19:00 a 23:00.

Ladislav Hagara | Komentářů: 1
20.2. 16:33 | Zajímavý projekt

Mozilla.cz informuje o stavu češtiny v projektu Common Voice. Projekt Common Voice sbírá hlasová data, na základě kterých bude možné trénovat modely a software pro rozpoznávání řeči. Aktuálně je nutné rozšířit počet vět v datové sadě a alespoň 5 tisíc vět musí být ručně ověřených několika lidmi.

Ladislav Hagara | Komentářů: 0
20.2. 16:22 | Nová verze

Byla vydána nová vývojová verze datového formátu a souvisejících nástrojů Relational pipes. Hlavní novinkou verze v0.10 je nástroj relpipe-tr-guile, který díky GNU Guile umožňuje filtrovat a transformovat relační data pomocí výrazů jazyka Scheme.

xkucf03 | Komentářů: 0
20.2. 00:33 | Bezpečnostní upozornění

CSIRT.CZ upozorňuje na kritickou zranitelnost ve WordPressu umožňující vzdálené spuštění libovolného kódu. Prakticky se jedná o kombinací dvou různých zranitelností (Directory Traversal a Local File Inclusion), pro jejichž úspěšné zneužití musí útočník získat v rámci instance WordPressu alespoň oprávnění autora.

Ladislav Hagara | Komentářů: 2
Máte v desktopovém prostředí zapnutou zvukovou znělku po přihlášení se do systému?
 (8%)
 (1%)
 (90%)
 (2%)
Celkem 398 hlasů
 Komentářů: 13, poslední dnes 18:27
Rozcestník

Dotaz: Nasazení GITu v rámci vývoje webové aplikace

25.4.2018 09:27 famke
Nasazení GITu v rámci vývoje webové aplikace
Přečteno: 1125×
Ahoj všem,

náš tým cca 10 vývojářů vyvíjí webovou aplikaci s databázovým backendem. Snažíme se pro účely vydávání verzí a nějaké rozumné správy vývoje nasadit git. V současné době se pracuje stylem kdy všichni přímo upravují kódy vývojové webové aplikace a provádí změny databáze. Vydání funkcionalit v dané verzi se řeší ručním přenášením změn z vývojové aplikace na release aplikaci ze které je vytvořena aktuálně vydávaná verze , databázové změny se zapisují do sql skriptu který s vydáním dané verze jde do světa. Že tento model není ideální je asi stejné jako říct, že Hitler trochu zlobil. Aplikace je psaná většinou v Classic ASP, takže nějaké continuous integration se jeví jako poměrně obtížně řešitelné.

V současné době je na stole tato varianta:

Uživatelé pracují na lokální kopii, která se synchronizuje s vývojovou verzí (nemají vlastní instanci web aplikace) a změny testují na vývojové verzi. Pokud jsou OK, provedou commit do centrálního repozitáře, ze které by byla vydána verze. Změny databáze by byly součástí tohoto commitu.

V plánu je držet spíše více větví pro nově přidávané/měněné funkcionality a po akceptaci je začleňovat do release větve. V současné době není na pořadu, že každý vývojář by měl vlastní instanci aplikace, kterou by si synchronizoval, s vlastní databází, takže byl navržen tento postup.

Napadá někoho jak to udělat, lépe, správněji?

Za každý postřeh, nebo nakopnutí děkuji.


Řešení dotazu:


Odpovědi

25.4.2018 10:06 cronin | skóre: 49
Rozbalit Rozbalit vše Re: Nasazení GITu v rámci vývoje webové aplikace
Už použitie akéhokoľvek VCS bude pre vás obrovským krokom vpred, urobte tak už DNES. Použitie rôznych workflows môžte zvážiť kedykoľvek neskôr.
Řešení 1× (OldFrog {Ondra Nemecek})
25.4.2018 22:29 Kit | skóre: 43 | Brno
Rozbalit Rozbalit vše Re: Nasazení GITu v rámci vývoje webové aplikace
Každé použití VCS je lepší než žádné. Git je skvělá volba, kterou používám i pro své privátní projekty, které s nikým nesdílím. V podstatě jen kvůli průběžnému zálohování. Také se nemusím bát si v něm cokoli natrénovat, i když si třeba nejsem jist správným výsledkem. Odnaučilo mě to dříve oblíbené zakomentovávání kusů kódu.

Zatím jsem se všude setkal s tím, že vývojář si kompletní aplikaci rozchodí na svém lokálním počítači, s lokální databází. Když vývojář řeší nějakou feature či bug, založí si nový branch, ve kterém to napíše a odladí. Průběžně vše verzuje do doby, než je s prací hotov. Pak nechá udělat code review tím, že zažádá o merge do hlavní větve. Druhý vývojář to zkontroluje a po dohodě to jeden z nich merguje do větve master. Větev s feature či bugem se následně zruší. V určitém okamžiku se z větve master udělá další větev deploy, udělají se na ní poslední hotfixy a otaguje číslem verze. Může se nasadit.

S tímto primitivním schématem se dá fungovat až do docela vysoké složitosti projektu. Pro 10 lidí to může v pohodě stačit.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
26.4.2018 16:17 MP
Rozbalit Rozbalit vše Re: Nasazení GITu v rámci vývoje webové aplikace
Nejslozitejsi na nasazeni lokalniho vyvoje (krome nauceni se jineho workflow) je vyreseni situace kolem databaze. Pokud se databazove zmeny prenasi sql skriptem, tak je napul vyhrano, ale je nutne to vyresit i u tech dev, jak se jim to syncne. Sami to ted resime...
Řešení 1× (OldFrog {Ondra Nemecek})
26.4.2018 20:04 .
Rozbalit Rozbalit vše Re: Nasazení GITu v rámci vývoje webové aplikace
spíše více větví pro nově přidávané/měněné funkcionality
Primárně se projekt pořád posunuje dopředu, takže pořád makáš na devu a něco přidáváš a měníš. Jednou za čas oddělíš release candidate, který chvíli stabilizuješ, pak vydáš release a případně z něj ještě děláš menší updaty. Prostě stálý vývoj se stabilními body. Jestli bokem s něčím experimentujete a až později to promergujete, tak se tím nic nemění.

Každý musí mít možnost kód hned testovat a commitne až splněný úkol (třeba i ve více krocích) a samozřejmě před tím zmerguje případné kolize s commity ostatních. Nechápu jak to chcete dělat na nějakém společném testovacím serveru, kde si všichni navzájem rozbíjí kód a commitují opravu každého překlepu.

To řeší i problém s databází. Buď se vytváří nová, nebo převádí stará a pak se samozřejmě verzuje a autor změny v DB doplní i převodní kód. Všichni vždy mají funkční verzi i když třeba každý jinou.
3.5.2018 13:59 kapo | skóre: 15 | blog: runtime
Rozbalit Rozbalit vše Re: Nasazení GITu v rámci vývoje webové aplikace
Why make things difficult, when it is possible to make them cryptic... - Aksel Peter Jorgensen
10.5.2018 19:07 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: Nasazení GITu v rámci vývoje webové aplikace
Jo, tohle jsem taky prosadil (s drobnyma zmenama) a dobre to bylo

plus samozrejme v gitu byl congif.example, zatimco config (se skutecnym jmenem databaza, IP, porty a tak) byl v .gitignore, takze kazdy vyvojar si ho nastavil podle sebe a mel svou databazi, ale komitoval zmeny od config.example (pokud neco pridal/zmenil/....)

samozrejmosti bylo, ze zmeny do databaze se delaly skripty (DJANGO je generuje automaticky - migrations), takze kdyz jsem si stahnul verzi od kolegy, tak jsem jen spustil migrace a mel to co on.

databazi si kazdy verzoval u sebe lokalne, takze nebyl problem kdyz zmeny neco rozbily to vratit zpet.

do develop se poustly az kompletni "squash" commity, ktere byly odladene a prosly testy.

(samozrejme cely kod byl pokryt testy - povinne - a pred commitem z vetve do develu musely projit vsechny.)

Jo, byl to opruz zavest a kolegy k tomu dokopat (i kdyz podpora vedeni byla na ideove urovni, ale hlavni bylo moje ultimatum (jako hlavniho vyvojare a otce systemu) - bud to bude verzovane a delane ciste, nebo proste odchazim) se zpetnym ohlednutim po pul roce si uz nedokazali predstavit, jak bez toho mohli neco rozumne delat. Vsechny ty rozbite releasy se staly v podstate prehistorii a hlavni vetev byla cista radka komitu, kde kazdy "zazrakem" resil jednu vec uplne a spravne. Feture vetve se zahazovaly prakticky jakmile se pridal ten squash merge do develu, protoze pak se z nej odstiply dalsi vetve a vychazelo se z toho stavu. (teda, nechaly se tak tyden, dva zahnivat kvuli moznym dohledavanim regresi, ale jejich aktivni zivot v podstate zaclenenim skoncil)

Rutinne (i kdyz rucne, protoze ne vzdy se to hodilo zrovna v tu chvili, kdy nekdo mel u sebe rozdelany komplexnejsi problem a nechodily mu na to testy) se mergoval novy stav develu do vsech otevrenych feature vetvi, rozhodne vzdy povinne pred sqash mergem zpet, takze merge z feature do develu byly vzdy bezproblemove (prakticky fast-forward, jen jinak zabaleny)

devel se pak obdobnym zpusobem choval jako "fetature vetev" releasu, takze kazdy release byl kompletni a funkcni a overeny - k nezaplaceni :)

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.