Hemit.Common

Samle gjenbrukbar/gjentakende kode på tvers av applikasjoner i fellespakker 

Innhold​

Hvorfor?​

• Kvalitet
  • Mindre kode å vedlikeholde / sentralisert vedlikehold
  • Krav om testdekning
    
  • Flere interessenter/øyne
    
• Standardisering
• Samarbeid
  • På tvers av teams og seksjoner (dugnad) => samhold
  • Lære av hverandre
  • Diskusjon
• Gjenbrukbarhet
• Raskere utvikling (etterhvert mer og mer kode/byggeklosser klare til bruk)

Hvordan?

Ulemper

• Tyngre utviklingsprosess å måtte lage kode i Hemit.Common og vente på ny versjon
  • Løsninger
    • Hyppige versjoner (nattlig etter godkjent PR, evt. manuelt trigget)
    • Lag koden i Hemit.Common med tester. Kopier inn koden til prosjektet sitt merket med TODO om å slette koden når ny versjon av Hemit.Common er klar
    • Lag koden i prosjektet, og flytt til Hemit.Common senere (mindre sjanse for at det blir gjort, anbefaler forrige punkt)

Ulemper

• Arbeidssomt å få ut ny versjon av Hemit.Common
  • Løsninger
    • Automatisk nattlige versjoner, evt. manuelt trigget
    • Enkelt format på versjonsnummer, må kun manuelt følges opp ved knekkende endringer

Ulemper

• Noen må holde liv i Hemit.Common for at det ikke skal dø ut, bestemme hvordan det skal struktureres og vedlikeholdes
  • Løsninger
    • Noen har det overordne ansvaret

Ulemper

• Endringer i eksisterende kode i Hemit.Common kan knekke et prosjekts bruk av koden
  • Løsninger
    • Endringer i eksisterende kode må kvalitetssikres grundig, viktig med god testdekning
    • Hvis bruken ikke er dekket av eksisterende tester i Hemit.Common - bør testene utvides
    • PRs med minimum to reviewers - se gjerne på historikken til endret kode og bruk utviklerne som har bidratt rundt koden tidligere

Ulemper

• Utviklere vet ikke hva som ligger i Hemit.Common og lager egne løsninger
  • Løsninger
    • Alle følger slack kanalen hvor det informeres om nye versjoner
    • Alle har tilgang til kodebasen
    • Jevnlig status/oppfordringer på kollokvium?
    • Løsningsarkitekt sørger for aktiv bruk av Hemit.Common til nye prosjekter og vedlikehold av eksisterende

Utvikling

Prosjekter lages i utgangspunktet i .NET standard slik at det kan brukes i både .NET Framework og Core prosjekter.

Trengs .NET Framework eller Core spesifikk kode så lages spesifikke Hemit.Common prosjekter for dette.

Basepakken Hemit.Common skal ha et minimum av avhengigheter. Er man avhengig av andre biblioteker skal man i utgangspunkt lage egne prosjekter, som vil føre til egne pakker (automatisk).

Eksempelvis brukes EPPlus for lesing fra og skriving til excel dokumenter. Vi har mye hjelpemetoder rundt dette, og det er da plassert i Hemit.Common.EPPlus prosjektet - og kun de applikasjonene som trenger dette drar inn den pakken og EPPlus avhengigheten.

Versjoner

For å hyppig kunne levere nye versjoner vil det automatisk releases nye versjon nattlig hvis det er endringer i master. 

Versjonsnummer på pakkene vil være av det enkle format [Major].[buildnummer] for å slippe måtte følge opp versjonsnummer andre ganger enn når det er knekkende endringer.

Bidra!

Alle oppfordres til å bidra, kontakt gjerne den ansvarlige først for å avklare om noe er uklart.

Man bidrar via pull request mot master. Legg til en kollega som reviewer, i tillegg vil den ansvarlige blir lagt til som reviewer automatisk.

Løsningsarkitekt sørger for fremme aktiv bruk av Hemit.Common i nye prosjekter og vedlikehold av eksisterende

Innholdet i presentasjonen finnes på Hemit.Common prosjektets wiki i devops

Slack: #hemit-common