Uppdrag: Öka tryggheten, minska brottsligheten 1 myndighet sedan 1/1 2015 Ca 30.000 anställda, 20.000 poliser, 10.000 civilanställda. Ca 800 + konsulter på it-avdelningen Budget ca 1.7 miljarder Mobilt stöd till polisen, utrullning av 10.000 mobiler med kontinuerliga förändringar Polisens it-verksamhet en integrerad del av den polisiära verksamheten (Medborgare, Internationellt, Forensik, Polisen)
Avsaknad av moderna e-tjänster (Försäkringskassan, Skatteverket) Time to market och förväntningar från medborgare väger högt Handläggningstider behöver minskas (Vapenlicens, handläggningstid) Nästa generation medborgare Närmare medborgare
I början av 2015 så kom beslutet från Rikspolischef Dan Eliasson att leverera e-tjänster med legitimering och betalning. Under 2015 genomfördes en Proof of Concept Polisen har traditionellt varit dåliga på att använda och adaptera till den senaste tekniken PoC:en innebar en chans att ta in etablera ny tekniken för framtida lösningar
PoC:en innebar att vi fick ett helt vitt papper Så vi satte oss ner och började brainstorma kring vilken teknik vi ville använda Buzzwords Java 8 Groovy SpringBoot TDD/BDD/Testbarhet Cucumber Microservices/Microtjänster Docker Gradle, Git, CI/CD, Jenkins REST Swagger Netflix Zuul Boostrap Med mera
Proof of concept:en byggdes med bl.a. följande - Microtjänstarkitektur (många tjänster/system) - REST-api mellan tjänsterna - Netflix Zuul (reverse proxy) agerar Grindvakt sköter legitimeringen (SAML) + Lägger på JWT (json web token) - Standalone Tomcat pga NoOps
Gradle -> Koncept från Ant och Maven -> Groovy DSL Gradle -> Möjlighet att ha script i byggkonfigurationen Gradle -> Inte lika verbose/pratig konfiguration som XML (Maven) Gradle -> Kompatibel med Maven Central/Repo Spring Framework gör vardagen enklare SpringBoot gör vardagen ännu enklare, det tar hand/bort om mycket konfiguration enligt principen convention over configuration SpringBoot har förkonfigurerat allting med bra standardvärden, men allt går att ändra på (t.ex. den inbyggda Tomcat:en kör som standard på port 8080, men det går att byta) Springboot-starter-* för att komma igång websocket - acctuator, web, logging, jdbc/data-jpa, aop, MongoDB,
Cucumber är ett verktyg för att kommunicera kring krav. Cucumber är INTE ett testverktyg, som många tror. Dock! Så går det att koppla ihop Cucumber mest automatiserade tester, vilket är rätt lätt Kraven skrivs i talspråk (Gherkin), lätta att förstå för alla - Utvecklare - Produkägare - Kravanalytiker - Testar Språkstöd för flera språk - Engelska, Svenska, Tyska, Spanska, Esperanto, - Emoji, Lolcat, Pirate, Klingon
Även om Cucumber inte är ett testverktyg så kan man koppla ihop det med automatiserade tester. Vi har valt att koppla ihop egenskaperna med acceptanstesterna mot domänlagret. I testkoden så har vi abstrakthetrat bort implementationen, det blir enklare att läsa testerna
Det går att koppla ihop Cucumber-scenariona med flera testnivåer Geb är ett testramverk för GUI-tester som bygger på Selenium Samma egenskaps-filer som för acceptanstesterna Snurrar igång hela applikationen i bakgrunden med hjälp av @SpringBootTest
En översikt över arkitekturen Det är många integrationspunkter, vilket gör att testningen blir komplicerad
PoC:en fick ett bra utslag och det bestäms att vi köra på. Under 2016 så ska vi lansera e-tjänst(er) till allmänheten Dock så finns det ingen (modern) driftplattform Utvecklarna har tittat på Kubernetes, som bygger på Googles Borg-plattform För snabb utväxling så samarbetar Polisen med Red hat för att leverera en ny plattform baserad på Openshift (som bygger på Kubernetes) I samband med detta så skapas ett team med folk från driften, med teknisk stöttning från Red hat Planen är att vidarutveckla PoC:en
MÅL Modernisering av arbetssätt och teknologi Leder till ökad kompetens kring moderna teknik och automation. Skapa förutsättningar för att attrahera kompetent personal Möjliggör snabbare leveranser av applikationer Tätare mellan produktionssättningar Närmare samarbete mellan utveckling och Produktion Bättre verktyg för produktägare METOD Samarbetsteam från utveckling och drift Ny plattform baserad på modern teknologi Färdigpaketerad lösning från Red Hat, byta komponenter över tid om så behövs Introducera komplexitet stegvis Minimera beroende till befintliga system Använda nya applikationer (MERIT)
Arbeta agilt - Mode 2 Pipeline-koncept för applikationer INKL UTMANINGAR Säkerhet, integration Utveckling i Norrköping Framtida ansvar you build it you run it
DevOps Driftteam bildas, hur samarbetar vi över olika orter? Driften har sina utmaningar (serverinstallation, brandväggar, certifikat, etc) Utvecklarna har sina utmaningar (systemdesign, användbarhet, testautomation, buggar, etc) Den andra grupperingen är ett svart hål pga avståndet. Lösning: Gemensamma standup via video.
Tappat arbetssätt (scrum) Tappat kravhanteringen Arkitekturen håller inte Teknisk skuld från PoC:en En månads diskussion Nystart utveckling Ta lärdom av PoC:en Gör om, gör rätt En tjänst, inte flera Skapa microtjänster när behov finns Scrumprinciper Leverans varje sprint Leverera verksamhetsnytta Ny kodbas
Tätt samarbete mellan driften och utveckling Så gott som driftklar e-tjänst (behövs lite puts på färg och form) för ansöka om tillstånd att ställa upp container, byggsäck, byggnadsställning på offentlig plats Grunden för driftmiljön är snart klar, en hel del infrastrukturbitar är kvar (övervakning, loggning, cert (-revokering)) Planerad pilot i slutet av oktober Kommande e-tjänster i pipe:en: - Ansökan av tillstånd för uteservering - Lyfta internetanmälan till nya plattformen (IMSE) Möjlighet att betala sin ansökan online/i samband med skickar in ansökan Legitimering kommer Fler e-tjänster som kommer: - Fler tillståndsansökningar - IMSE (Anmäl stöld, förlust, inbrott och inbrottsförsök, Anmäl kontokortsbedrägeri) - Vapenlicensansökning - Verifiera pass - Tipstjänsten
Vad har vi lärt oss av detta? - DevOps över olika orter fungerar - Ha med driften och utvecklarna från dag 1, låt driften vara med i PoC:en - Det är ett lyft (kunskapsmässigt) för personalen att jobba DevOps - Individer lyfter under rätt förutsättningar - Var försiktig med microtjänster. Skapa bara när det verkligen behövs. Se över nyttan de tillför? SOA done right (Martin Fowler) - Testning kräver mycket arbete, svårt få till bra Cucumber-scenarion. Det är komplicerat att testa microtjänster - Frihet att testa ny teknik under en PoC. Vi fick, tyvärr, mycket leveransfokus och krav på krav. - Lär av era misstag, Vi har ökat vår kunskap, tack vare misstag