Deploy

[nilsgs]

Hvllke komponenter trenger vi å deploye, og hva mangler før vi kan få noe fungerende ut i skyen?

[havremunken]

Det ser vel omtrent slik ut:

• Vemundo sitt java-prosjekt er det som samler inn data. Kan vi kjøre java-baserte prosjekter som en webjob er vel det greit? Alternativet er kanskje å ha en egen VM gående?
• Jeg jobber på en konsoll-app som leser xml-filer, tolker de, legger data inn i SQL-basen, og genererer statiske kamptråd-bilder (la ut et eksempel på et eksperiment i tråden på RBKweb i går, dette var generert manuelt på "gamlemåten" med gdi++. Bruker WPF usercontrols + OxyPlot for rendering av ting nå, tror det gir oss mye mer fleksibilitet mtp. layout o.l.). Denne er tenkt å gå som en webjob.
• Det må vel også settes opp en webtjeneste som kan serve
  • de statiske bildene for kamptråder
  • web api
  • frontend på litt sikt (hvis jeg fortsetter med ember blir dette bare en html-fil pluss en haug js og css)

Jeg vet jo at et webprosjekt kan auto-deployes til Azure ved git-oppdatering, men gjelder det samme webjobs (eller hva de faktisk heter)? Eller bør vi sette opp noe på en gratis CI-tjeneste som vi så kan få til å deploye når vi pusher oppdateringer?

[nilsgs]

Såvidt jeg kan se så går det fint å kjøre Java på Azure: http://blogs.msdn.com/b/azureossds/archive/2015/04/28/executing-java-web-jobs-on-azure.aspx

CI fra GitHub skal heller ikke være noe problem. Jeg skal ha noe tid neste uke, før jeg drar på ferie, der jeg kan begynne å se på hvordan vi skal orge deploy.

[havremunken]

Høres veldig bra ut! Jeg har også startet ferie nå, og vil ha litt variabel tilgang til nett, men skal se om jeg får rigget til en automatisk statisk-bilde-i-dropbox-greie som kan funke for kamptråder frem til vi har en fungerende Azure-sak.

[havremunken]

For de som har sett kamptråden mot vif så er statisk-bilde-i-dropbox-greia på plass. Ingest-programmet (må få sjekket inn et mareritt av en update snart) er ganske primitivt nå - ikke noe logg, ikke noe output på hva den driver med, og den genererer statiske bilder for alle kamper den vet om, uavhengig av om de har fått nye data eller ikke. Dette er heldigvis lett å fikse, og tror ikke dette trenger å være så fryktelig langt unna det vi slenger inn i Azure - selv om det gjerne skal være litt mer robust enn Rambo-koden min.

[nilsgs]

Jeg har satt opp det meste av det vi trenger i Azure (web site og database), men jeg får ikke til å koble det mot GitHub. Det virker som om jeg ikke har de tilgangene som kreves. Tror jeg må stå som owner, noen som kan fikse dette?

[havremunken]

Jeg TROR jeg har fått gjort deg til owner nå - hvis det ikke går, si ifra, så skal jeg se litt nøyere på det!

[nilsgs]

Takker. Da skal det automatisk blir kjørt en deploy av WebAPI ved push til master.

Check it out: http://staut.azurewebsites.net/api/event

Foreløpig har jeg bare en dummy implementasjon av repositoriene, så neste steg blir å koble opp databasen.Er det mye kode som ikke er sjekket inn forresten?

[nilsgs]

Har også lagt til Swashbuckle (Swagger) for autogenerering av API dokumentasjon: http://staut.azurewebsites.net/swagger/ui/index

[havremunken]

Veldig kult!

Jeg har et digert lass med kode som ikke er sjekket inn, det meste av det går på tegning av graf. Skal forsøke å få røven i gir og få inn dette ASAP, så vi kan begynne å tukle igjen. Ikke meningen å opptre som en "kork" i denne sammenhengen!

Må bare få unna litt podcast-redigering, så skal jeg sette meg ned og ni-committe!

[leloberg]

Tøft! Begynner så smått å se på hvordan jeg kan lese dette i android.

[havremunken]

Vær obs på at web api default gir deg xml om du ikke ber om noe annet. Jeg antar at i en Android-app vil det være enklere å forholde seg til JSON? Man kan vel be om det via en content-type header eller noe sånt, om jeg ikke husker helt feil.

[havremunken]

@nilsgs : Har du noen formening om hva som er rett sted å legge de genererte statiske bildene som brukes i kamptrådene når vi flytter til Azure?

Pr. nå går det på kottserveren min, og når Ingest-programmet (som leser inn data og lager png'er) har gjort sitt, lagres filene bare i dropbox'en min. Primitivt men en relativt enkel måte å gjøre det tilgjengelig for mange kjapt.

Er rette fremgangsmåte å lagre disse på samme webserver som APIet går? Eller noe smartere?

Disse filene er relativt billige å generere på nytt, så tror ikke vi trenger å vurdere å lagre dem på en mer permanent blob eller noe sånt.

Hvor filene blir generert (og litt andre ting) er forøvrig konfigurerbart gjennom app.config'en.

[nilsgs]

Jeg er ikke helt sikker på hva som er den beste måten å gjøre dette på. Jeg har undersøk litt, men ikke funnet noe godt svar enda.

[havremunken]

Den er god. Jeg tenker egentlig at vi vel kanskje ikke gjør noen utilgivelig feil hvis vi lager en "grafer"-mappe i webroot og legger dem der? Så kan vi jo alltids forandre på det om vi ser at det er mer hensiktsmessig.

Og hvis du skulle komme over noe som er mye bedre så skal jeg holde kjeft og gå og skamme meg i hjørnet jeg. :)

[nilsgs]

Jeg har begynt å se litt på deploy igjen, Og slik jeg tenker det foreløpig, så tror jeg det mest hensiktsmessige vil være å sette opp et API for lagring og uthenting av data. Så kan vi flytte selve datainnsamlingen ut i skyen etterhvert.

Men før jeg begynner å rote rundt vil jeg vite om det er noe utestående kode som ikke er sjekket inn?

[havremunken]

Masse! Jeg har dårlig samvittighet så det holder for dette, har brukt altfor mye tid på andre ting de siste par ukene.

I dag sitter jeg grundig fyllesyk på jobben og forsøker å holde gråten tilbake, hvis jeg får være i fred skal jeg se om jeg får sjekke inn det jeg har gjort. Hvis dere har sett grafene på rbkweb har dere sikkert sett at verden langt fra er perfekt enda, men litt fokus (da først og fremst fra meg) kan få dette brukbart relativt kjapt.

[havremunken]

Da har jeg endelig fått sjekket inn up-to-date kode som genererer de grafene som brukes på RBKweb i dag. Her er det MYE bugly kode, utviklet etter ADHD-metoden, bare hoppet fra det ene til det andre for å klare å spytte ut en graf på et vis.

Legg merke til at denne pr. nå genererer grafer for ALLE events den finner i databasen - noget unødvendig. Tenkte å legge til en greie som gjør at den kun kjører rendering på filer som har fått nye data siden sist. Kan selvfølgelig også legge til en sjekk så den genererer ev. som måtte mangle siden sist - grei måte å sørge for at den "henter seg inn" når vi har gjort noen ev. drastiske ting.

[nilsgs]

Da har jeg også klart å få den hånden som var trygt plassert der solen aldri skinner ut. v1.0 av Staut API ligger nå ute med databasestøtte. Sjekk ut http://staut.azurewebsites.net/swagger/ui/index for dokumentasjon.

Det er verdt å merke seg at alt ligger helt åpent foreløpig.

[havremunken]

Veldig kult! Er midt oppi en ganske forvirrende prosess med å bytte jobb o.l., så det har blitt lite STAuting på meg i det siste, men i løpet av en måned bør alt være på plass, da tenkte jeg å se litt mer på dette igjen. Hadde vært stilig å ha mer på plass når neste sesong nærmer seg. Måling av sesongkortsalget f.eks. Har også fått forespørsel om å lage en slags "widget" til Kjernen-hjemmesiden, det bør være trivielt i forhold til alt vi allerede har på plass. Og så må jeg vel snart tenke ferdig tanken om en ordentlig STAut-frontend hvor folk kan få utløp for statistikk-fantasiene sine... :)