Jak spustit a zorganizovat IT development nové aplikace? Které technologie a služby využít? Jak rozdělit role v týmu? Když jsme se před lety v Intelligent Studios pustili mimo jiné do vývoje aplikace Xeelo, která je nadstavbou ERP pro řízení firemních procesů, sami jsme na podobné otázky hledali odpovědi.
Ideální řešení jsme objevili často až praxí. Dnes víme, že vyhnout se některým slepým uličkám ušetří všem začínajícím vývojářům spoustu času i nákladů. Shrnuli jsme proto naše zkušenosti a postupy, které se osvědčily v tom, jak jednoduše začít s developmentem v MS Azure a připravit si aplikaci tak, aby ji bylo možné později doplnit o základní funkce jako security, jazykové mutace a další rozšíření.
1) Idea a řešení developmentu
Zásadní je idea, jak bude aplikace fungovat. Zde je důležité rozmyslet se, jaké technologie používat, zda je aplikace určená pro segment B2C, nebo B2B a kde plánujeme, aby běžela – v cloudu, nebo i on-premise (důležité u B2B řešení). V našem případě šlo o produkt určený primárně pro B2B použití, takže fungujeme na obou platformách.
Při výběru technologie a rozvržení aplikace je určitě vhodné separátně oddělit uživatelskou a administrátorskou část. V našem případě to přineslo výhodu různého release managamentu. Získáváme další plus v tom, že všeobecná chyba, která se může objevit v administrátorské části, neochromí část uživatelskou. Snadno také kontrolujeme zdrojový kód pro uživatelskou část, u admin části to není tak podstatné.
Už od začátku je důležité myslet na možné jazykové mutace (resources a překlady na úrovni databází).
2) Bezpečnost aplikace
Pozornost je nutné věnovat bezpečnosti – použití vlastního systému logování a ověřování, připojení na Active Directory, Google nebo Facebook login. V neposlední řadě je potřeba zabezpečit také web API v případě vícevrstvé infrastruktury za použití security tokenů pro každé připojení s ohledem na to, aby nebylo možné web API zneužít.
Rozhodně se vyplatí použít ověření přístupu uživatele na více úrovních – front-end/web API a v databázi. Může se to zdát pracné, ale úsilí se vrátí, protože eliminujete případné útoky na aplikaci, jako je zneužití aplikace uživatelem, který má do aplikace přístup.
3) Výběr technologie
V rámci cloud řešení MS Azure jsme se využili produkty, jako jsou SQL Database, App Service, Storage a Cloud Service. Rozdíl vůči standardní infrastruktuře je v tom, že nemusíme spravovat žádný server, kde by byly požadované služby instalované. Ušetříme množství času, protože neřešíme licencování, instalaci servisních ani bezpečnostních balíčků a nevěnujeme se samostatné správě serverů.
Pro development a správu zdrojového kódu jsme zvolili Visual Studio Online a projekt typu Git/Scrum. Každý modul aplikace má vlastní repo, protože na něm pracují různé týmy a používáme různé technologie. Programátoři používají Visual Studio, které má poměrně bohatou integraci s VSO Git repository, takže velmi rychle a pohodlně řídíme, co všechno chceme do kódu poslat, a také je možné použít Visual Studio pro správu release verzí dané aplikace (využití více větví a cherry-pick funkcionality).
Je žádoucí zamyslet se, jak aplikaci logicky dělit. My použili SQL server jako základnu, kde máme valnou část aplikační logiky, následuje web API vrstva a prezentační vrstva. Web API je realizované pomocí .NET Framework a prezentační vrstva je ASP.NET MVC pro uživatelskou část a Angular 2.0 pro administrátorskou část, pro mobilní zařízení je prezentační vrstvou Ionic Framework.
4) Azure Subscription
Velmi užitečné je zvolit správný typ plánu od společnosti Microsoft. Je dobré MS přímo kontaktovat, abyste se do budoucna vyhnuli případné migraci na jiný typ subskripce (pay as you go, prepaid nebo open). Hlavně začínající týmy mohou v rámci subskripce získat různé slevy a volný kredit, což následně sníží náklady spojené s vývojem aplikace.
5) Vývoj v cloudu
Vývoj v prostředí cloudu je v některých případech odlišný od standardního vývoje. Například databáze a webová aplikace jsou na oddělených serverech, a proto je nutné počítat s prodlevou připojení. Tyto problémy je ale možné řešit, a to tím, že dotazy mezi jednotlivými prvky řešení nejsou vytvářeny pro každé pole, ale v rámci „bulk“ přenosu, čili se snažíme vyměnit nebo dotazovat data ve větším objemu. Tyto transakce si ukládáme na web server a následně poskytujeme front-endu (caching).
Další funkcí, která dokáže vyřešit některé části developmentu, jsou App Service WebJobs. Toto řešení umožňuje asynchronní zpracování úloh webové aplikace. Deployment a naplánování je velmi jednoduché a je součástí aplikace, takže využíváte stejné zdroje/connection string a další nastavení, která chcete v rámci aplikace sdílet. Z důvodu lepšího performance managamentu můžete WebJobs přesunout na další App Service, nebude docházet k ovlivnění výkonu samotné aplikace.
6) Application lifecycle management
Řízení vývoje, jako je zadávání požadavků a plánovaní release, je možné v samotném VSO/VS. Jednotlivé commity mohou být linkované s požadavky, takže je následně poměrně jednoduché připravovat release notes a případně další dokumentaci potřebnou pro vývoj a zákazníka.
My jsme se rozhodli pro použití nástroje SPIRA, abychom měli všechny součásti vývoje aplikace v rámci jednoho ALM a zároveň, abychom měli rozdělené repo. Navíc je potřebné vývoje v rámci jednotlivých modulů koordinovat, a to je v jednom prostředí jednodušší.
7) Release management
V našem projektu máme měsíční release, kdy pro každý vytváříme další větev v rámci repository. Tento release následně testujeme a případný bug je řešený skrze funkci cherry-pick z hlavní vývojářské vrstvy. Toto řešení používáme především z důvodu, že produkt nabízíme i ve verzi on-premise. Výhodou je, že máme přesnou verzi kódu, kterou má u sebe zákazník, takže není problém danou verzi rozbalit v interním testovacím prostředí a odstranit reportovaný bug.
Číslování release může být rozmanité, ale každopádně je dobré zahrnout do něho srozumitelný časový údaj, jako je rok/měsíc a také číslo úpravy v případě bug-fixingu.
U každého release vidíme detailní log změn a nových funkcí. Přehled je důležitý, jak pro nás, tak pro zákazníka, který může koncové uživatele informovat o změnách.
8) Deployment
Pro deployment jsme použili Azure Virtual Machine, kde běží automaticky pomocí MSBuild, SQLPackage a Node.js. Tento deployment využívá scheduled jobs na Windows serveru a deployment profilů pro jednotlivá prostředí. V testovacích prostředích běží nasazování kódu na denní bázi. U produkčního prostředí jde deployment „on-demand“ po dohodě s klientem. Stačí jednou měsíčně přehodit název Git branch, kterou chceme nasadit na test, a o ostatní se postarají připravené deploy skripty.
9) Rozdělení týmu
Každý modul nebo část řešení by měly mít jednoho zodpovědného developera. To neznamená, že pracuje na vývoji sám, ale zabezpečíte tak, že daný modul bude konzistentní a stejný problém nebude řešen různými způsoby.
Nad aplikací je dobré mít důsledný dohled. To zabezpečí role architekta, který zadává práci developerům s výjimkou bug-fixingu, protože zde mohou podněty přicházet od testerů či konzultantů. Pokud jde o větší změny, musí se ale zapojit i architekt.
Přínosný je tým zkušených testerů, což se často podhodnocuje. Kvalitní tým ale dokáže vyřešit problémy přímo s developery, a na beta testování tak mnohdy ladíme jen logické nedostatky řešení.
Autor: Tomáš Belák, Chief Design Architect, Intelligent Studios
O Inteligent Studios a Xeelo:
Intelligent Studios od roku 2007 navrhuje inteligentní softwarová řešení pro firemní byznys. Hlavním smyslem navrhovaného software, respektive IT řešení je, aby se efektivně podílela na růstu firmy a dávala vyniknout jejímu potenciálu. Jedním z klíčových produktů Intelligent Studios je Xeelo, nadstavba ERP systémů pro řízení firemních procesů.
Články ze série Microsoft TechNet nevytváří redakce Živě.cz, ale partneři programu Microsoft TechNet. Jsou publikovány v rámci mediálního partnerství Živě.cz a společnosti Microsoft.
