6.1. Přehled vývoje QWAT

6.1.1. Předpoklady

Za účelem rozvoje pro QWAT mohou být požadovány následující dovednosti:

Dobré obecné znalosti o GIS
Dobré obecné znalosti o QGIS
Znalosti v relačních databázích a konkrétně PostgreSQL / PostGIS
Dovednosti v Pythonu

6.1.2. Prostředí

Budete muset nainstalovat a nakonfigurovat Git a GitHub <https://help.github.com/articles/set-up-git/> _
Nainstalujte si python 3 jako výchozí python. Pokud tomu tak není, použijte virtuální prostředí <https://docs.python.org/3/library/venv.html> _
má bash shell
mít práva administrátora pro vytváření a odstranění databází PostgreSQL

6.1.3. Architektura QWAT

Popište zde různé části QWAT
Popište vztah k jiným projektům (pluginy, qgis core)

6.1.4. Role

Commiters mají přístup k úložištím kódů QWAT a mohou tam odesílat push požadavky. To znamená, že mají pod kontrolou vývoj softwaru
přispěvatelé mohou poskytnout informace, kód, dokumentaci k projektu. Nemají přímý přístup k úpravám a musí projít komitery, aby získali své úpravy. Další informace a procesy naleznete v části [[Contributors_guide]].
Správce verzí má na starosti rozhodování o vydání nové verze softwaru a vydání tohoto vydání. Aktuální správce vydání je Régis Haubourg (OSLANDIA) <https://github.com/haubourg> _ jménem skupiny QWAT.

6.1.5. Cykly a verze vydání

Nové verze pro QWAT jsou vydávány pravidelně, ale v nepravidelné frekvenci Správce vydání rozhodne, kdy bude zveřejněna nová verze.

Číslo nainstalované verze najdete v datovém modelu v tabulce qwat_sys.info.

6.1.5.1. Pravidla správy a vydávání verzí

Čísla verzí se řídí přístupem `sémantického verzování <http://semver.org> `_.
Plán verzí pro nové funkce musí být sdílen na trackeru a s generálním výborem. Problémy musí být otevřeny a označeny štítky (1.4, 1.5).
Nevytvářejte verzi pro každou změnu kódu.
Verze budou shromažďovat různé změny kódu a musí být projednány se správcem vydání.
Je možné mít více rozdílových souborů Delta pro jednu verzi-vydání Příklad: delta_1.3.2_0001_one_change, delta_1.3.2_0002_another_change
Každá nová verze bude systematicky vydána. Vydání se projeví pomocí značky git
travis-CI automaticky uvolní vydání když přijde čas a testy jsou úspěšné
Správci dat nesmí NIKDY pracovat na hlavní větvi, ale používat vydání. Důvodem je to, že nejnovější verze hlavní větve se až do vydání mění, takže nejde o spolehlivou značku verze. To pro uživatele git znamená, že mají načíst vzdálené značky a provést kontrolu do požadovaného vydání pomocí git checkout tag_number

6.1.6. Proces vydání

Proces vydávání pro QWAT je následující:

Problémy jsou tříděny s milníky do dalších verzí
Správce vydání rozhodne, kdy bude uvolněno další vydání, v souladu s potřebami komunity
Oznámí předpokládané datum vydání v předstihu (nejméně 1 týden)
Problémy jsou přezkoumány a datum může být přesunuto podle toho, jak probíhá práce
CHANGES.md je zaškrtnuto, zda obsahuje popis změn pro tuto verzi
Když je připraveno (všechny plánované tikety jsou uzavřeny), správce vydání přidá verzi projektu metadata a označí projekty (verze), které budou uvolněny (datový model, projekt QWAT) s novou verzí,
Správce vydání oznamuje novou verzi (seznamy adres, IRC, twitter…)

6.1.7. Další závislost

Projekt QWAT má několik závislostí na různých submodulech

Načítání jejich obsahu je dosaženo pomocí konkrétního příkazu git

6.1.8. Verzování rozšíření

Před datovým modelem QWAT 1.3.0 byla verze sledována v qwat_sys.versions, které museli přispěvatelé udržovat ručně. Poté se modul PUM postará o automatické zvyšování a sledování verzí pomocí konvencí pojmenování souborů jádra delta. Doporučujeme však použít pouze jeden skript SQL pro přizpůsobení, bez verze v názvu. Můžete jej verzovat v samostatném úložišti git nebo SVN, ale smíchání lokální a základní verze může vést k velmi složitému systému.

6.1.9. Vypracování základního datového modelu

Abychom udrželi řízený proces nad verzí, máme následující systém:

Soubory SQL, které odpovídají vytvoření základního datového modelu
Soubory SQL odpovídající změnám od verze X do verze X+1 („diff SQL“)

Rozdílové soubory jsou umístěny v úložišti v adresáři „delta“. Jejich název má tuto konvenci, kterou používá modul PUM:

delta_1.3.2_0001_one_change.sql

Nasazení modelu pro konkrétní verzi a postupné použití souborů diff k dosažení jiné verze by mělo vést k přesně stejnému modelu jako nasazení této poslední verze. Projekt QWAT bude mít nástroje pro testování této shody.

Doporučuje se psát diff soubory současně s modifikací modelu, ale to není povinné. Diff soubory musí být kompletní a aktuální při vydání nové verze modelu. Před uvolněním nové modelové verze by měly být diff soubory analyzovány a dokončeny. Některý kód může být také refaktorován na zjednodušené diff soubory (např. Více úprav do stejného pole mezi dvěma verzemi)

Některé soubory delta jsou jednoduché, jako nové tabulky a pohledy. Některé jsou složitější, protože jsou vystaveny prostřednictvím pohledů. Většina pohledů v QWAT je automaticky generována modulem metaprojektu. To znamená, že přidání uživatelských polí (například do elementů nebo trubek), bude vyžadovat další instrukce pro zrušení a opětovné vytvoření pohledů před / po použití souboru delta. PUM umožňuje přidat pre a post soubory, buď v pythonu nebo sql pro každou aktualizaci, příklady viz delta.1.2.8.

V důsledku toho při vývoji základního datového modelu byste měli:

Vložte modifikace do základních modelů souborů SQL
Přidejte své úpravy do správného diff souboru.

Požadavek pull by měl být doplněn těmito prvky, nebo musíte být před samotným vydáním připraveni přezkoušet diff SQL soubory, abyste se ujistili, že diff je aktuální.

6.1.10. Rozvíjení projektu QGIS

Jak upravit výchozí projekt nebo vytvořit nový
Jak tyto změny sdílet

6.1.11. Přidání nových funkcí do QWAT

viz doprovodná příručka pro diskusní proces a správu problémů
vytvoření konkrétního pluginu
přispívat do QGIS core