Komponentní vývoj aneb příběh firmy, co příliš rychle narostla

Slides:



Advertisements
Podobné prezentace
Web Michal Žůrek Jak se na něj dívám já..
Advertisements

Něco málo o ICNET s.r.o. Správa kódu v historii – přechod na TFS (TF Server) Nové platformy – přechod na TFS (TF Service) Integrace TFS s nástroji třetích.
Stránka 1, © Vema, a. s.. Stránka 2, © Vema, a. s. Podnikové aplikace  Integrovaný podnikový systém (Integrated Business System):  komplex aplikací.
ŘEŠENÍ PRO TÝMOVOU INFRASTRUKTURU
AJAX fenomén současného internetu Dalibor Kačmář Academic Developer Evangelist Microsoft ČR host Vítek Karas Senior Software Development Engineer Microsoft.
Scia - Nemetschek Postavení SCIA v holdingu Nemetschek
 Informací se data a vztahy mezi nimi stávají vhodnou interpretací pro uživatele, která odhaluje uspořádání, vztahy, tendence a trendy  Existuje celá.
SOFTWARE operační systémy
Workflow Foundation Základy a architektura
Webová aplikace.  Úvod  Možnosti vývoje (komponenty, které dokážeme nabídnout) + ukázka  Možnosti využití Frameworku pro těžkého klienta  Výrobní.
Tvorba webů pomocí Web CMS Michal Neuwirth Product Manager Kentico Software s.r.o. Ondřej Výšek Samostatný konzultant Optimalizovane-it.
Tvorba webových aplikací
1 Audit software Petr SLOUP Cíl Cílem auditu je sestavit přehled a základní popis používaného software (aplikací)
„Firemní řešení avast! - rychle, efektivně, jinak“
LCS International, a.s..
11. Trendy ve vývoji aplikací, podporujících podnikové procesy
Informační strategie. řešíte otázku kde získat konkurenční výhodu hledáte jistotu při realizaci projektů ICT Nejste si jisti ekonomickou efektivností.
Michael Juřek Software Architect Microsoft s.r.o.
PHP – Základy programování
Rozšíření jednouživatelské verze IS na víceuživatelskou Prezentace Diplomové práce Autor : Libor Tomášek Spoluautoři : Pobucký M., Drábek L. Vedoucí :
Technologická středa Continuous Integration with Maven and Hudson Vlastimil Menčík
Tomáš Urych, ESO9 Intranet a.s.
4IT445 – Testování a ladění v PHP Ing. Jan Mittner
Debian Unixová distribuce. Historie První zmínka pochází z 16. srpna Zakladatelem je Ian Murdock, který v té době studoval na univerzitě. Je vytvářen.
4. Lekce Dílčí procesy funkčního testování
Tvo ř te historii. CAD a Data Management VIII. ročník konference Autodesk Academia FÓRUM listopad 2008 Ing.Radomír Žvak DAGIS a.s.
Představení nové verze OPSI Kamil Malinka Martin Lebeda PROJEKT financovaný z Operačního programu Vzdělávání pro konkurenceschopnost ZVYŠOVÁNÍ IT GRAMOTNOSTI.
Aleš Chudý IW BG Lead Microsoft Corporation. Lidé jsou klíčové aktivum firem Nové trendy práce Software jako platforma Strategická iniciativa (horizont.
Dokumentace informačního systému
MODERNÍ ZPRACOVÁNÍ PROJEKTOVÉ DOKUMENTACE. Obsah Vývoj reprografických služeb Co by dnes měli projekční, developerské a stavební firmy požadovat od svého.
Copyright (C) 1999 VEMA počítače a projektování, spol. s r.o.
Aneb proč to dělat složitě, když to jde jednoduše S Datronem proti proudu.
Novinky pro webovou platformu Jiří Burian, Tomáš Kutěj,
Nebezpečí webových aplikací Tomáš Strýček Invex Forum Brno
Základní rozdělení činností v podnikové informatice
SERVICESSERVER CLIENT Operating System Relational Database Application ServicesSystems Management Developer Tools Programming Model Applications.
Robert Hernady Regional Solution Architect Microsoft.
INTERNET VE STÁTNÍ SPRÁVĚ A SAMOSPRÁVĚ 2008 © Copyright IBM Corporation 2008 Správa obsahu v podání IBM 7. – 8. dubna 2008 ibm.com/cz/public Daniel Beneš.
Trustworthy Computing Michael Juřek Software Architect Microsoft ČR.
Windows XP a live distribuce Knoppix, Danix apod
Srovnání systémů řízení projektů Vypracovala: Jitka Procházková.
Nokia Czech Republic, s.r.o. Igor Šmerda, program manager.
Protálová řešení Příklady reálných nasazení Tomáš Kutěj System Engineer Microsoft.
Webový knihovní systém
Google Apps Martin Kotlík Brno, 12. květen 2015 Cloudová řešení 1.Cloudové řešení Apple 2.Cloudové řešení Microsoft 3.Cloudové řešení Google.
Počítačové hry a animace
Portál jako Dynamic WorkPlace.  Cleverbee s.r.o.  společnost založena 2000  15 let zkušeností (prodej a vývoj ERP řešení)  švýcarská společnost se.
ICT – TEORIE A PRAXE – ŠKOLY A FIRMY Miloš Maryška, Katedra informačních technologií, VŠE Praha
Vývoj software pro Linuxové distribuce Installfest Praha,
Miroslav Hübner listopad 2014 Jak sehnat peníze na IT ANEB zamyšlení jak si koupit, co potřebuji.
Randstad Java Academy vše o kurzu Gabriela Hrbáčková Director Randstad Professionals.
TEAM FOUNDATION SERVER 2015 BUILDS POKORNÝ JIŘÍ
Internetový prohlížeč
SOFTWARE Operační systémy.
INISOFT s.r.o. softwarová společnost v Liberci
TDD - Test Driven Development
Team Foundation Server 2015
„Firemní řešení avast! - rychle, efektivně, jinak“
Operační Systém Operační systém je v informatice základní programové vybavení počítače (tj. software), které je zavedeno do paměti počítače při jeho.
Vysoká škola technická a ekonomická
Tradiční metodiky vývoje softwaru
Git Git je v informatice distribuovaný systém správy verzí vytvořený Linusem Torvaldsem pro vývoj jádra Linuxu.
Vývoj aplikací v ASP.NET Core a Angular2
Web Application Scanning
ABRA FlexiBee Developers Day 2015
DevOps (nejen) pro mobilní aplikace
Trendy v unit testování a mockování
Praktická cvičení Úvodní hodina David Malý kabinet 205.
Azure DevOps Terraform QA FTW
Desktopové aplikace na .NET Core
Transkript prezentace:

Komponentní vývoj aneb příběh firmy, co příliš rychle narostla Jiří Pokorný Jiri.Pokorny@solarwinds.com

Solarwinds 30+ produktů pro IT Management Microsoft stack: C#, MS SQL, AngularJS Non MS: Python, Java, Linux Brno office – Solarwinds R&D center https://www.solarwindsmeetup.com/ Pozice http://solarwinds.jobs/ Navštivte náš stánek

Historie firmy Hračičky s.r.o. 10 let úspěšně na trhu 20+ projektů Neustálý růst a nábor nových vývojářů (100+) Většina produktů Asp .Net web forms Source control - TFS Mladý tým Nastaveny kontroly kvality formou automatizovaných testů a continuous integration

Problémy firmy (viditelné) Hromadící se technologický dluh zastarávajících technologií (např. webforms) Nikdo nemá know how o celých produktech (pouze o částech) Již detekována opakovaná implementace tohotéž (kopírování celých částí kódu mezi produkty) Neustále se prodlužující se doba mezi vydáním následující verze Většina vývojářů pracuje ve firmě od školy, přichází ze škol nebo ze startupů – chybějící zkušenosti Vývojáři hlásí hodně hodin strávených opravou vývojového prostředí Zmínit, jak nahradit zastaralou technologii za novou, pokud není izolovaná Uvést příklad přepisování WebForms do nového Asp .net Uvést příklad build skriptu kopírovaného do každého projektu

Ignorované problémy (neviditelné nesledované) Aneb na co by se manager měl ptát? Narůstající množství integračních a regressních buggů: 50% všech bugů jsou chyby vzniklé změnou v nové verzi Narůstající doba testování: měsíc regresních tetů před releasem, tisíc manuálních testů Narůstající doba continuous integration: build 2hodiny, testy 26 hodin Klesající success rate u buildů: pouze 50% buildů je úspěšných Neuvádím Statickou analýzu, např. pomocí SonarQube, která taky pomůže odhalit stav projektu Zmínit, že google testuje více než 75 mil. Testů denně a release každé 3 sekundy https://www.youtube.com/watch?v=W71BTkUbdqE https://www.youtube.com/watch?v=KH2_sB1A6lA

Zlepšovák 1. – Přejít na GIT Problém: Velké množství padajících buildů Přínos není GIT, ale branchovací strategie => žádné dlouho žijící branche Hodně malých repozitářů nebo jeden velký (google)? U hodně malých nejde udělat změna najednou pro všechny produkty Převzato: https://paulhammant.com/2014/01/08/googles-vs-facebooks-trunk-based-development/ https://datasift.github.io/gitflow/IntroducingGitFlow.html https://trunkbaseddevelopment.com/ Zmínit, že každá knížka o continuous integration doporučuje minimalizovat počet aktivních branchí Připomenout feature toggles Zmínit Google s jeho jediným repozitářem na všechno a optimalizací vlastní implementace Zmínit, že Microsoft má projekt souborového systému pro podporu velkých repozitářů v Gitu

Zlepšovák 2. – Velký refaktoring B G H D J L M Aktuální architektura E A B F C G H D J K L M Neúspěšný refaktoring Problém: Dlouho trvající build Neúspěšný pokus: Velký refaktoring - rozbít solution na menší části Držet jeden velký solution soubor (rules them all) Integrační testy pouštět pouze jednou denně Po půl roce refaktoring stále není hotový Veký refaktoring a „from scratch“ obvykle selže Stabilita integračních testů se zhoršila Řešení: Používat feature toggles Vyříznout jeden logický celek do nové komponety Otočit závislost a definovat samostatný release cyklus E A B G H D J L M Úspěšná architektura Tisk Komp. E A B G H D J L M Úspěšná architektura Tisk Komp. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://martinfowler.com/articles/feature-toggles.html Zmínit příklad Netscape a jejich failu, když se pokusili přepsat jádro prohlížeče „from scratch“ Připomenout, že feature toggles pomáhají při velkém refaktoringu, kde hrozí, že projekt nebude nějakou dobu kompilovatelný Modré boxy jsou jeden repozitář s jedním solution souborem, zelená je jiný repozitář s jiným solution souborem

Zlepšovák 3. - Semantic versioning Problém – Velké množství itegračních bugů a testů, protože konzumujeme nejnovější („bleeding edge“) verze všech závislostí Řešení: Vyextrahovat sdílený kód do samostatných komponent Zavést samostatné verzování každé komponenty Použít semantic versioning pro detekci „breaking change“ (2.0 je kompatibilní s 2.0.3 nebo 2.0.3-beta1, ale ne s 2.1.0) Referencovat „kompatibilní“ stabilní verze – nikoliv latest Aktualizovat závislosti často, samostatným krokem v CI, ověřované automatizovanými integračními testy https://semver.org/ Zmínit artifactory jako doporučený tool pro package server Zmínit, co je to prerelease verze a tu konzumovat pro interní komponenty Problém aktualizace komponent a tranzitivních závislosti, kde A -> B -> C a současně A -> C. Doporučit paket namísto nugetu, protože je flexibilnější v resolvování závislostí source https://www.nuget.org/api/v2 nuget unit nuget log4net Paket.dependencies: source https://www.nuget.org/api/v2 nuget unit ~> 2.6.4 nuget log4net ~> 2.0.3 Paket.dependencies:

Zlepšovák 4. - Infrastructure as a code Problém: Vývojáři hlásí velké množství hodin strávené opravou vývojového prostředí Dokument obsahující návod co všechno nastavit a nainstalovat Řešení: I build script je sdílená verzovaná komponenta I skript je testovaný (Powershell => Pester) Instalace prostředí je automatizovaná skriptem Utilizujeme šablony pro virtualizaci (Hyper-V templates, docker images) Nastavení pomocí environment variables Vývojář musí být schopen pustit jakýkoliv skript lokálně Minimalizovat rozdíl mezi build agentem, vývojářským PC a produkčním serverem Komponenta si nese svou vlastní dokumentaci Viz. Také 12factor.net https://12factor.net/ https://github.com/pester/Pester Představit problém connection stringu v souboru Ukázat jak se dozvím, co dělat, když naklonuju repozitář Zmínit příklad různých verzí SQL serveru na vývojářských mašinách Zmínit, jak zrychlením SQL serveru v dockeru pro DB integrační testy zrychlilo nastavení vývojového prostředí a spouštění a stabilitu testů

Zlepšovák 5. – Contribution model Problém: Musím počkat než tým tiskové komponenty implementuje změnu Code review – není dostupný nikdo kdo by rozuměl měněné části aplikace Řešení: Kdokoliv může vytvořit pull request do libovolného kódu Zavést roli „component owner“ a „maintainer“: dohlíží (nemusí schvalovat) na všechna review Má právo zamítnout pull request! Zodpovídá za kvalitu a technical debt komponenty Zmínit, že Open source uvnitř firem je moderní trend, viz. Např. Microsoft Říct příklad hry zakomponované v účetním software Příklad malé změny, která stála spoustu peněz, přestože architekt varoval product ownera. Component owner nemusí schvalovat všechno, může delegovat na maintanery. Dá se snadno ověřit, kolik máme odborníků na danou problematiku. To, že se komponenta příliš nevyvíjí neznamená, že její vlastník ji např. nebude kompilovat pro novější verzi .netu nebo aktualizovat externí závislosti.

Zlepšovák 6. – Automatizované integrační testy Problém: Velké množství regresních a integračních testů Dlouhá doba testování (regrese) před releasem Řešení: Každá komponenta má své testy definující její API Pouštět integrační testy s každým buildem Release produktu obsahuje automatizované integrační testy Build Component A Build Component B Integration tests for A and B Mark A and B as Stable Pokud jsou si komponenty rovnocené a není mezi nimi závislost, pak je spojuje produkt a pak se jedná o end to end testy produktu nikoliv integrační testy komponent. Integrační testy produktů je potřeba dělat pouze pokud podporujeme současnou instalaci různých verzí produktů, které vzájemně spolupracují. Zmínit, že itegrační a E2E testy trvají dlouho a proto je nutné je paralelizovat Google to řeší tím, že dělá pouze incrementální build, nikdy clean na build agentovi Build Component A Build Component B Test Component B Mark B as Stable Test Component A Mark A as Stable Řešení:

Souhrn Pomocí: Docílíme: Branching strategie Feature toggles Semantic versioning Infrastracture as a code Automatizace všeho Continuous integration Contribution modelu Docílíme: Vyšší stability buildů Rychlejších release cyklů –prakticky kdykoliv Možnosti rychle vyměnit libovolnou externí komponentu Minimalizace regresních bugů

Závěr – Firma je úspěšná i nadále Veškerá podobnost s existující firmou je čistě náhodná! Firma je fiktivní a ukazuje souhrn zkušeností několika firem .Net vývojáři, učte se od Linuxového světa => Neobjevujme již objevené Rozbíjejte a refaktorujte monolitická řešení raději dříve než později (velký problém jde vždy rozbít na spoustu menších) Automatizujte všechno (instalaci, testy, upgrade komponent, integrace, kontroly kvality)