Stručně
Základní pravidla a best practices pro práci s Flyspray-em. Vždy platí priority tasků dle RFC 2119 takto:
milník | Flash |
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ů:
Bug | jakákoli chyba, ať od uživatele nebo z interních testů |
Feature | uživatelská funkčnost či vlastnost, nově chtěná |
Task | interní vylepšení, reorganizace kódu, technické úpravy |
Test | testovací scénář pro ověření funkčnosti -- JakPsatTestovaciTasky |
Leader
- používá plánovací tasky takto:
Type | Komentář |
** 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:Critical | Funkč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