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 17:00 | Nová verze

Simon Long představil na blogu Raspberry Pi novou verzi 2018-11-13 linuxové distribuce Raspbian určené především pro jednodeskové miniaturní počítače Raspberry Pi. Přehled novinek v poznámkách k vydání. Společně s Raspbianem byl aktualizován také instalační nástroj NOOBS (New Out Of the Box Software). Simon Long z novinek zdůrazňuje multimediální přehrávač VLC s hardwarovou akcelerací nebo vývojové prostředí pro Python Thonny ve verzi 3. Ke stažení jsou nově také lite a full obrazy Raspbianu. Raspbian Full opět obsahuje software Mathematica.

Ladislav Hagara | Komentářů: 0
dnes 02:00 | Nová verze

Krátce po vydání Debianu 9.6 oznámil Tomáš Matějíček vydání verze 9.6 dnes již na Debianu založené živé linuxové distribuce Slax. Vedle vylepšení z Debianu je opraveno několik malých chyb. Opraveno bylo bootování pomocí PXE. Novinkou je skript s názvem pxe pro spuštění vlastního PXE serveru.

Ladislav Hagara | Komentářů: 0
dnes 01:00 | Nová verze

Byla vydána beta verze Red Hat Enterprise Linuxu 8. Přehled novinek v příspěvku na blogu a v poznámkách k vydání.

Ladislav Hagara | Komentářů: 2
včera 13:44 | IT novinky

Nadace Raspberry Pi na svém blogu představila (YouTube) jednodeskový počítač Raspberry Pi 3 Model A+. Toto menší Raspberry Pi 3 lze koupit za 25 dolarů.

Ladislav Hagara | Komentářů: 0
včera 06:00 | Pozvánky

Dnes a zítra probíhá v Praze konference Internet a Technologie 18 pořádaná sdružením CZ.NIC. Sledovat ji lze online.

Ladislav Hagara | Komentářů: 0
včera 01:11 | Komunita

V září proběhl v Madridu Open Source CubeSat Workshop 2018. Videozáznamy přednášek byly zveřejněny na YouTube.

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

Společnost Amazon představila Amazon Corretto. Jedná se o fork a distribuci OpenJDK (Open Java Development Kit) s dlouhodobou podporou od Amazonu. Ke stažení je preview verze 8. V plánu je také verze 11. Zdrojové kódy jsou k dispozici na GitHubu. Jedná se o reakci na oznámení společnosti Oracle, že bezplatné aktualizace její Javy nebude možné po lednu 2019 používat komerčně. Název Coretto vychází z Caffè corretto, tj. espressa s alkoholem.

Ladislav Hagara | Komentářů: 5
14.11. 12:44 | Nová verze

Po roce vývoje od vydání verze 5.2.0 byla vydána verze 5.3.0 svobodného integrovaného vývojového prostředí KDevelop (Wikipedie). Novinkou je analyzátor Clazy. Vylepšena byla podpora programovacích jazyků C++, PHP a Python. Ke stažení a k vyzkoušení je i binární balíček s KDevelopem 5.3.0 ve formátu AppImage.

Ladislav Hagara | Komentářů: 0
14.11. 05:55 | Komunita

Ubuntu 19.04 bude mít kódové jméno Disco Dingo. Dle oznámení v diskusním listu ubuntu-devel-announce je ve vývojové verzi Disco Dinga výchozím Pythonem 3 verze 3.7. Perl byl aktualizován na verzi 5.28. OpenSSL 1.0 bude nahrazeno OpenSSL 1.1.1 LTS. Nové instalace Dinga budou mít sloučený /usr. Stane se tak 7 let po sloučení /usr ve Fedoře nebo Arch Linuxu.

Ladislav Hagara | Komentářů: 9
14.11. 02:22 | IT novinky

V pondělí a úterý proběhl v San Franciscu Chrome Dev Summit 2018. Přehled dění v příspěvcích na Chromium Blogu. Videozáznamy přednášek na YouTube. Představen byl například web pro webové vývojáře web.dev nebo rozšíření webového prohlížeče Chrome s názvem VisBug (YouTube) určené pro webdesignery. Slíbená je podpora Firefoxu.

Ladislav Hagara | Komentářů: 0
Jak nejčastěji otevíráte dokumenty na počítači?
 (90%)
 (4%)
 (6%)
Celkem 96 hlasů
 Komentářů: 9, poslední včera 22:46
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: 1108×
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.