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í
×
včera 13:00 | Komunita

Do 30. října se lze přihlásit do dalšího kola programu Outreachy (Wikipedie), jehož cílem je přitáhnout do světa svobodného a otevřeného softwaru lidi ze skupin, jež jsou ve světě svobodného a otevřeného softwaru málo zastoupeny. Za 3 měsíce práce, od 4. prosince 2018 do 4. března 2019, v participujících organizacích lze vydělat 5 500 USD.

Ladislav Hagara | Komentářů: 39
21.9. 22:22 | Komunita

Společnost Purism představila kryptografický token Librem Key. Koupit jej lze za 59 dolarů. Token byl vyvinut ve spolupráci se společností Nitrokey a poskytuje jak OpenPGP čipovou kartu, tak zabezpečení bootování notebooků Librem a také dalších notebooků s open source firmwarem Heads.

Ladislav Hagara | Komentářů: 8
21.9. 20:33 | Nová verze

Společnost NVIDIA oficiálně vydala verzi 10.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
21.9. 20:00 | Upozornění

Příspěvek Jak přežít plánovanou údržbu DNS na blogu zaměstnanců CZ.NIC upozorňuje na historicky poprvé podepsání DNS root zóny novým klíčem dne 11. října 2018 v 18:00. Software, který nebude po tomto okamžiku obsahovat nový DNSSEC root klíč, nebude schopen resolvovat žádná data. Druhým důležitým datem je 1. února 2019, kdy významní výrobci DNS softwaru, také historicky poprvé, přestanou podporovat servery, které porušují DNS standard

… více »
Ladislav Hagara | Komentářů: 7
21.9. 15:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 156. brněnský sraz, který proběhne v pátek 21. září od 18:00 v restauraci Na Purkyňce na adrese Purkyňova 80.

Ladislav Hagara | Komentářů: 0
21.9. 13:22 | Nová verze

Alan Griffiths z Canonicalu oznámil vydání verze 1.0.0 display serveru Mir (GitHub, Wikipedie). Mir byl představen v březnu 2013 jako náhrada X serveru a alternativa k Waylandu. Dnes Mir běží nad Waylandem a cílen je na internet věcí (IoT).

Ladislav Hagara | Komentářů: 0
20.9. 22:00 | Nasazení Linuxu
Stabilní aktualizace Chrome OS 69 (resp. Chromium OS), konkrétně 69.0.3497.95, přináší mj. podporu linuxových aplikací. Implementována je pomocí virtualizace, a proto je tato funkce také omezena na zařízení s dostatkem paměti a podporou hardwarové akcelerace, tudíž nejsou podporovány chromebooky s 32bitovými architekturami ARM, či Intel Bay Trail (tzn. bez Intel VT-x).
Fluttershy, yay! | Komentářů: 5
20.9. 21:32 | Zajímavý projekt

Došlo k uvolnění linuxové distribuce CLIP OS, vyvíjené francouzským úřadem pro kybernetickou bezpečnost ANSSI, jako open source. Vznikla za účelem nasazení v úřadech, kde je potřeba omezit přístup k důvěrným datům. Je založená na Gentoo.

Fluttershy, yay! | Komentářů: 1
20.9. 16:00 | Komerce

Zjistěte více o bezpečné a flexibilní architektuře v cloudu! IBM Cloud poskytuje bezpečné úložiště pro Vaše obchodní data s možností škálovatelnosti a flexibilitou ukládání dat. Zároveň nabízí prostředky pro jejich analýzu, vizualizaci, reporting a podporu rozhodování.

… více »
Fluttershy, yay! | Komentářů: 12
20.9. 12:22 | Nová verze

V dubnu letošního roku Mozilla představila webový prohlížeč pro rozšířenou a virtuální realitu Firefox Reality (GitHub). V úterý oznámila vydání verze 1.0. Ukázka na YouTube. Firefox Reality je k dispozici pro Viveport, Oculus a Daydream.

Ladislav Hagara | Komentářů: 2
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (13%)
 (15%)
 (21%)
 (23%)
 (25%)
 (4%)
 (1%)
Celkem 393 hlasů
 Komentářů: 33, poslední 16.9. 11:55
Rozcestník

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

25.4. 09:27 famke
Nasazení GITu v rámci vývoje webové aplikace
Přečteno: 1105×
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. 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. 22:29 Kit | skóre: 42 | 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. 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. 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. 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. 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.