Hlavní menu

Nástroje

WebKiv / PravidlaProVyvojare

View (print) - Edit page | Recent changes - Page history

Updated 10 September 2010, 11:05 by PremekBrada

Stručně

1. Bug tracker = Flyspray na forge.kiv

Základní pravidla a best practices pro práci s Flyspray-em. Vždy platí priority tasků dle RFC 2119 takto:

milníkFlash
MUST čili release blocker (prioritu má task)High
SHOULD čili pokud není impl v release je třeba zdůvodnit (prioritu může mít release)Normal
MAY čili když se nestihne, nic moc se neděje (prioritu má release)Low

Aktuální práce jsou identifikovány ohvězdičkovanými verzemi, tj. např. "Due in version = *Common 2.0" .

Vývojáři

  • dělají jen tasky, které mají přiřazené,
  • když začnou na nějakém dělat, změní stav na "In development" a případně upraví hodnotu odhadu pracnosti,
  • si budou aktualizovat "teploměr" u svých tasků,
  • po úpravách ověří, zda něco jinde nerozbili, projitím testovacích scénářů (viz Flyspray typ tasku "Test")
  • když mají hotovo, změní stav na "Requires testing", nastaví odhad pracnosti na skutečně strávený čas a teploměr na 90%, a dají "Request closure"

Vývojářské typy tasků:

Bugjakákoli chyba, ať od uživatele nebo z interních testů
Featureuživatelská funkčnost či vlastnost, nově chtěná
Taskinterní vylepšení, reorganizace kódu, technické úpravy
Testtestovací scénář pro ověření funkčnosti -- JakPsatTestovaciTasky

Leader

  • používá plánovací tasky takto:
TypeKomentář
** MILNÍK **Cíl etapy-iterace; má mít nastaven Due in datum i Due in version; ideálně přiřazeny dependent tasks
Feature se Severity:CriticalFunkční modul; má mít přiřazeny dependent tasks; typicky se jejich část řeší v nějaké iteraci

Pro moduly: Milník se statusem "In development" je aktuálně ve vývoji, status "Assigned" je možné použít jako "jo tohle budeme chtít a plánujeme to jako další verzi"; status "New" je potenciální budoucí milník.

Detaily viz IteracniPlanovaniVeFlysprayi.

2. Úložiště v Subversion

Úložiště přístupné pres Orion login+heslo na URL https://forge.kiv.zcu.cz/svn-www-kiv/.

Verzují se, resp. v Subversion repo mají separátní top-level adresáře (v nich pak je std subversion struktura)

  • jednotlivé moduly
  • globální dokumentace
  • grafické návrhy a šablony
  • datový model a SQL DDL skripty

Co se neverzuje:

  • projektové apod soubory pro IDE (např .project pro Eclipse), které má každý vývojář jiné

Konfigurace OpenCms je v top-level adresáři opencms-libs spolu s potřebnými .jar soubory knihoven. TODO: Nekde by mela v top-level strukture modulu byt sdilena konfigurace pro pripojeni do db.

Práce s úložištěm při vývoji

Vývojáři:

  • Při prvním přístupu do svn přes Eclipse a plugin SVNKit? budete dotázáni na zadání jména autora. Povinně zadejte svůj orion login, nesmí se zde zadat jméno(login) s diakritikou. Pokud jste náhodou již toto provedli, smažte v adresáři "Eclipse Home"/configuration/org.eclipse.core.runtime soubor .keyring a znovu spusťte Eclipse. Při přístupu do SVN budete opět dotázáni na jméno autora.
    • Důvod: případné "uživatelské" jméno s diakritikou boří některé Subversion klienty, zejména cmdline a Tortoise, ve kterých pak nejde udělat checkout/update.
  • Při commitu povinně psát komentáře !!! (pokud možno s referencí na Flyspray task ve formátu FS#123)
  • Před commitem změn src/.java modulu: zbuildovat .jar tříd pro modul, uložit ho do lib/ adresáře -- pak teprve commit
    • výsledek: v svn jsou vždy v souladu zdrojáky a přeložené třídy k nasazení do OpenCms
    • POZN: možná opustíme, viz návrh nové struktury

3. Struktura a build modulu

Struktura modulu

Struktura KIV modulů je založena na std OpenCms struktuře a z pohledu Subversion struktury vymyšlena taková, aby na ní šel dělat vývoj (viz také OpenCMS.VyvojModuluPodEclipse) a zároveň v ní byly dostupné hotové buildy nasazených modulů.

Pár pravidel:

  • nevytvářet zbytečné adresáře -- např. templates/ pokud modul neobsahuje šablonové JSP
  • pod pages/ rovnou JSPčka (ne tedy např. pages/osoby/neco.jsp) pro modul Osoby

Pojmenování a verzování modulů a jejich .zip souborů

Moduly pro web KIV mají čísla verzí ve formátu M.m.p.e kde první dvě pozice (Major a Minor) určují verzi funkčnosti (dle dohody vývojářů, prj managera, a pokud možno dle souladu s cílovou verzí v milníku ve Flyspray), třetí pozice (Patch) indikuje opravy chyb bez přidání fčnosti, a čtvrtá pozice (Export) je ponechána k nastavování OpenCms při exportu modulu.

  • před exportem modulu pro uložení jeho buildu vývojář v OpenCms nastaví v datech modulu (Administration > Module management > Edit module) verzi na M.m.p.0 tj. nastaví major a minor dle dohody a číslo exportu na nula, a do Description napíše aktuální datum a čas vydání
  • výsledný .zip uložený v Subversion bude mít tedy název cz.zcu.kiv.modul_M.m.p.X.zip a po importu do OpenCms bude mít verzi M.m.p.X kde "X" je nezajímavé číslo vzniklé při exportu (nejčastěji z lokálního OpenCms) vývojářem.

Build a release

Základní pravidla:

  • v Subversion musí být uložen každý "zbuildovaný" .zip modulu -- repository je referenční místo, odkud se moduly berou pro instalaci na ostrý web;
  • každá verze modulu, která je určena pro nasazení (byť i jen v testovacím režimu např. na beta.kiv) musí mít tag v Subversion a tento tag v sobě musí obsahovat příslušné číslo verze modulu -- např. /temata/tags/temata_1.2.0/;
  • .zip soubor modulu pro uložení v Subversion vzniká pouze a jedině exportem otestovaného a fungujícího modulu z (lokálního) OpenCms, nikoli ručním "zazipováním" nebo třeba ant scriptem (a je základní slušností ho před commitem zkusit naimportovat do čistého OpenCms, aby vývojář věděl, že mu to funguje).

Zpět na RedSys