Programvareutvikling hos Sun Microsystems Jørgen Austvik Sun Microsystems Database Technology Group
Innhold Sun i Trondheim Hva vi lager Utviklingsprosesser Kvalitetsarbeid > Mål > Hva vi gjør Verktøy > Infrastruktur > Rapporter
Sun Microsystems
Sun i Trondheim Database Technology Group Tidligere Clustra, som har historie tilbake til Telenor og SINTEF Databasearbeid i Trondheim fra 1970 Ca 50 personer i Trondheim, jobber tett med USA og India, ca 10 personer hver plass Trondheim er det største miljøet for database systemutvikling innen Sun
Innhold Sun i Trondheim Hva vi lager Utviklingsprosesser Kvalitetsarbeid > Mål > Hva vi gjør Verktøy > Infrastruktur > Rapporter
JavaDB Apache Derby (tidligere Bundles med Cloudscape) > J2EE Referanse Implementasjon IBM, Sun og > Applikasjonsserveren privatpersoner > Portal Server Følger standarder > Java Studio Creator > JDBC 4.0 > Java Studio > SQL Enterprise Embedded eller > NetBeans 5 Standalone > Java 6 SDK
TPC/B-like load, Disk-bound DB DB 10GB, buffer 64MB, 400 branches 70 Derby embedded Derby client/server MySQL (InnoDB) PostgreSQL 60 50 TPS 40 30 20 10 0 0 20 40 Number of clients 60 80 100
High Availability Database (HADB) Distribuert databasesystem Høytilgjengelig (99,999%) Benyttes i: > Applikasjonsserveren, Enterprise Edition > Sun Message Queue > HoneyComb
HADB Arkitektur
Distribusjon av data
Innhold Sun i Trondheim Hva vi lager Utviklingsprosesser Kvalitetsarbeid > Mål > Hva vi gjør Verktøy > Infrastruktur > Rapporter
Prosesser? Dere vet hva vi lager hvilke prosesser ville dere ha satt igang for å sikre god nok kvalitet?
Prosess: Roller Program Management > Forvalter kundenes interesser ARC > Godkjenningsorgan > Utvikling, kunder, marked/salg, support/sustaining Prosjekt > Driver prosessen etter et mandat QA/QE > Lånes ut til prosjekter
Prosess: Forenklet skisse PM Prosjekt QA Marked Services Konsept Plan Utvikling Systemtest Sustaining Retirement t Krav Plan Utv Rette feil Kjøre tester Markedsføring og Salg Support EOL Benchmark med andre sammenlignbare firma: 39% raskere til markedet enn 20% top av andre firma, ca 3X mer fortjeneste.
Produkt og Prosjekt HADB 4.5 4.6 5.0
Prosjekter og Vedlikehold HADB Kern HADB 4.6 Ytelse SQL JDBC Vedlikehold SQL I IQ Q Mgt QA QE
Innhold Sun i Trondheim Hva vi lager Utviklingsprosesser Kvalitetsarbeid > Mål > Hva vi gjør Verktøy > Infrastruktur > Rapporter
Kvalitet: Mål med testing Kvalitet på produkt Enkelt Effektivt
Mål for Kvalitetsarbeidet? Dere vet hva vi lager og hva vi ønsker hvordan ville dere ha gjennomført kvalitetsarbeidet?
Kvalitet: Produkt oppfyller krav Mapping mellom krav og tester/testcaser Teste noe som ikke er krav: tung bevisbyrde Testbare krav er med fra starten
Kvalitet: Finne feil tidlig og før kunder Er med fra starten Release testing MATS Nattlig og ukentlig testing Statisk kodeanalyse
Kvalitet: Finne regresjoner Nattlig og ukentlig testing Ytelsestester Skalerbarhetstester Langtidstester
Kvalitet: Skape trygghet Testkjøring og analyse
Kvalitet: Automatisert testing Nattlig og Ukentlig regresjonstesting Med og uten debug
Kvalitet: Effektiv bruke av ressurser Mennesker > Automatisering Maskiner > Hjørneplattformer > Parallell kjøring i testinfrastruktur
Innhold Sun i Trondheim Hva vi lager Utviklingsprosesser Kvalitetsarbeid > Mål > Hva vi gjør Verktøy > Infrastruktur > Rapporter
Kategorier av tester Sorterer testene inn i kategorier for å få oversikten Bygger opp testsuiter for forskjellige releaser og produkter basert på disse Release kriterier på hvor mange tester som må kjøre igjennom for hver kategori
Testinfrastruktur Java Engine for Testing (JET) > Kjører XML filer for å sette sammen Java kode til tester JET Agent (JAG) > Kommunikasjons punktet på maskinene vi styrer JETBatch > Kjører flere tester distribuert Servere JETBatch JAG HADB Klient JAG JET JAG HADB
Rapporter: Ytelse Se at produktet ikke degraderer Se at fikser som legges inn har en virkning Basert på Baseline > Forrige versjon av produktet > På en gitt rigg > På en gitt plattform
Rapporter: Skalerbarhet Endre antall noder og klienter Se at vi klarer å ta unna mer last når vi legger til flere noder Se at vi ikke plutselig legger inn en algoritme som ikke skalerer
Rapporter: Langtidstest Ser at produktet ikke degraderer over tid > Eksempel: Minnelekasjer
Rapporter: Åpne feil Danner grunnlag for å bestemme om et release kan gå gjennom forskjellige faser > Beta > Alpha > Release Candidate > FCS
Programvareutvikling hos Sun Microsystems Jørgen Austvik jorgen.austvik@sun.com