search

Altinn / altinn-studio

Next generation open source Altinn platform and applications.
https://docs.altinn.studio
BSD 3-Clause "New" or "Revised" License
110 stars 72 forks source link

'Ny utgave' i repository ikke synlig i altinn.studio #45

Closed xmrsa closed 5 years ago

xmrsa commented 5 years ago

Man må vite nøyaktig hva utgaven heter for å kunne finne den igjen etter at den er opprettet. Min utgave heter "1994" men er bare synlig dersom jeg limer inn hele strengen i nettleseren https://altinn.studio/designer/SSB/Test/1994

På siden SSB/Test finnes det ingen liste over hvilke utgaver som er laget: image

altinnadmin commented 5 years ago

@xmrsa Det virker ikke som du har opprettet noen utgave? Kan du forsøke å trykke "Clone service" og så trykke "Ny utgave"?

Tanken er at det skal kunne se ut som noe ala dette: image (jeg la til en ny utgave, men får naturlig nok ikke sjekket det inn da jeg mangler skrivetilgang til din tjeneste)

Igjen, beklager manglende navigasjon og at funksjonaliteten per nå er tungvint og lite intuitiv. Dette er absolutt et "Minimum Testbart Produkt"... 😄

xmrsa commented 5 years ago

Jeg trykket på Clone service og fikk da beskjed om at jeg trengte Personal Access Token, så jeg opprettet det og kopierte den inn da jeg ble spurt om det. Det er vel kanskje det med "innsjekkingen" som er problemet for meg også. Jeg kan gå rundt omkring, opprette UI og sette sikkerhetssnivå og laste opp XSD og sånt. Jeg har trykket på den grønne Lagre-knappen på selve skjemasiden, men jeg har ikke sett noe som har tydet på at ting er "committet". Det ser bare ut som om jeg får lov til å "Slette utgave".

image

Nå forsøkte jeg til og med å trykke på Deploy-lynet, men det virket veldig dødt. Jeg gikk så tilbake til Test-siden, og da ser det fortsatt like tomt ut:

image

Må jeg kontakte ham som opprettet repositoryet for at den hemmelige nøkkelen min skal være godkjent? Jeg kan se at jeg har skriverettighet til repositoryet på forsiden: image

xmrsa commented 5 years ago

Jeg får forresten null reference, unhandled exception når jeg forsøker å klikke på teksten "Last opp" her. Det er vel kanskje en liten bug. image

altinnadmin commented 5 years ago

Tror du må trykke "Clone service" en gang til etter at du har lagt inn token (disse manuelle stegene vil forsvinne i endelig løsning).

Pt. så må du tilbake til tjenste-nivå (altså SSB / Test) for å kunne sjekke inn ev. endringer som er gjort på tjenesten. Et mye bedre (og mer tilgjengelig) brukergrensesnitt for dette vil naturlig nok komme på plass etter hvert.

Info om at noe er endret, med lenke til innsjekking:

image

Innsjekking med liste over endrede filer, husk å legge inn en beskrivelse:

image

Hannott commented 5 years ago

Jeg kan heller ikke se noen utgaver jeg selv har opprettet. De eksisterer, men jeg må skrive inn navnet på utgaven i URL for å komme meg dit. Har ikke lastet opp noe kode, kun jobbet i designeren.

TheTechArch commented 5 years ago

Lukker denne da vi har fjernet konseptet med utgaver. En tjeneste har kun en utgave.

Hannott commented 5 years ago

@TheTechArch Hvordan vil oversikten se ut når vi har over 60 tjenester som endres hvert år, og skal leve videre i produksjon i 10 år frem i tid? Skatteetaten har mange hundretalls utgaver i TUL nå, kan jo prøve å telle.

TheTechArch commented 5 years ago

@hannekot det er viktig at vi kommer opp med en god løsning på dette. Skissene er ikke klare for dette. En av hovedriverne for å endre dette er at man lettere kan sammenligne to versjoner da det vil være sitt eget repository i GIT isteden for undermapper i samme delte repository.

Hannott commented 5 years ago

@TheTechArch Virker som det blir tatt utgangspunkt i tjenesteeiere som har særdeles få tjenester?

Jeg er ikke enig i det med GIT. Det er mye bedre å ha et repository med flere brancher, enn helt separate repositories. Hvis vi tar utgangspunkt i at alle våre skjema som nå ligger i TUL var utviklet i 3.0, måtte jeg lastet ned rundt 5-600 separate repositories.

Google-søk på GIT compare repositories gir meg svaret "ta repo 1, og kopier det inn i repo 2 som en branch, så compare"

TheTechArch commented 5 years ago

@Hannott det er mulig vi snakker rundt hverandre her, men det er supert om vi går litt i dybden.

Slik det var frem til forrige uke så var det slik at når man opprettet en tjeneste så fikk man et tomt repository.

Så kunne man lage en utgave. Da ble det en folderstruktur under det repository. MVA/2012 f.eks

I det øyeblikket man trengte en ny utgave fikk man folderen MVA/2013.

For å sammenligne hva som er forskjellen mellom to utgaver ville ikke GIT kunne forstå dette da det vil oppfattes som helt forskjellige sett med filer.

Men som du påpeker så er det ingen rett frem måte å sammenligne to repositories direkte. (som ikke er en fork av det andre) (og forking innad i en org virker ikke som en konsept som er vanlig)

Det er riktig at skatt har mange utgaver totalt sett. 326 siden 2010 i produksjon.

  1. Er det noen spesiell grunn til at du tenker du må laste disse ned? Er det ikke nok å laste ned de du skal jobbe med?
  2. Er det slik at du foretrekker at vi løser utgaver som brancher på en tjeneste? Foreløpig har vi sagt at branching skal vi prøve å holde vekk fra GUI i designer

Takk for at du tar deg tid. Det er nå det er lettest å påvirke hva vi lager.

altinnadmin commented 5 years ago

Se også #109 for noen flere argumenter.

Hannott commented 5 years ago

@TheTechArch Det er ikke uvanlig å gjøre sammenlikninger med tidligere utgaver. Eksempelvis er det funksjonalitet som fjernes ett år og skal tilbake det neste. Men neida, jeg må strengt tatt ikke laste ned absolutt alle, men det virker unødvendig tungvint å laste ned et helt repo og gjøre all den jobben for å hente opp en commit.

Jeg forstår tydeligvis ikke problematikken du beskriver med git. Hvordan blir det umulig for git å gjøre compare mellom to brancher i samme repo?

Ang punktene fra #109

Der er vi vel bare uenig. En hovedmappe med "Skattemelding" med undermapper for årstall høres helt oversiktlig ut for meg

Å gjøre en git branch fra 2017 til en 2018 branch beholder historikk og commits som er veldig relevant å beholde. Automatisk testing burde også være lettere ved å kjøre feks Skattemelding.All().RunTest()

Diff mellom Head og prev commit er mye enklere enn repo diff.

I hvilke tilfeller er det naturlig å ikke få tilgang til en eller flere spesifikke utgaver?

Vet ikke

Personlig synes jeg det er veldig praktisk med to identifikatorer. Da kan jeg si "gi meg alle skattemedinger", i stedet for "gi meg skattemlding 2012, gi meg skattemelding 2013, osv".

Hannott commented 5 years ago

@TheTechArch Bare av interesse, hvor gikk du for å lete etter antall utgaver? Vi begynte med 50 tjenester i 2012, og har en til mange utgaver av hver av de hvert år siden den gang, så et absolutt minimum av utgaver hadde vært 350, men faktisk antall er antatt over 600. Hadde vært interessant å finne et faktisk tall

TheTechArch commented 5 years ago

@Hannott grunnen til at det er umulig å sammenligne mellom to utgaver slik det var er at utgavene lå i forskjellige foldere i samme branch. (Master)

Som nevnt har man i utgangspunktet tenkt at brancher skal skjules fordi ikke-tekniske utviklere vil kunne ha problemer med å skjønne konseptet branch. Men dette er ikke skrevet i stein. Blir et spørsmål hvor lett det blir i Altinn Studio å skjønne hvilken branch man faktisk jobber med og hvordan man mapper branchen til en gitt container.

Jeg har tatt antall fra produksjonsdatabasen til Altinn.no. Dette er altså antallet unike tjenester/utgaver som er migrert fra TUL til SBL siden 2010. I TUL har dere sikkert noen testtjenester som dere kanskje aldri har migrert?

Hannott commented 5 years ago

@TheTechArch Nå forsøkte jeg å lage en branch i SourceTree og pushe den til mitt repo: image

Får da frem to brancher i mitt repo: image

Forventet funksjonalitet blir da å se to valg av utgaver som vist i screenshot i starten av denne tråden.

TheTechArch commented 5 years ago

@Hannott takk for innspill. Vi skal ta en runde på dette i prosjektet. Du har gode argumenter for å løse versjoner slik.

Vi må se på hvordan vi kan løse det i Designer (den webbaserte kode editoren) .

@AnneThorseng @IneF @eimik @nkylstad

TheTechArch commented 5 years ago

@Hannott vi har nå tatt en diskusjon rundt problemstillingen. Det vi har landet på er følgende.

  1. Vi vil legge inn støtte for branching i Altinn Studio. Men dette er IKKE for å håndtere versjoner, men for å understøtte utvikling med f.eks ekstern kodeeditor hvor man ønsker å sjekke noe inn å gjøre det tilgjengelig i Altinn Studio for testing uten at man nå sjekke det inn i Master. For tjenester med flere brancher vil man da få et valg i Altinn Studio. Man kan da som utvikler gjøre pull request for en branch inn i Master. Tjenester bygges i utgangspunktet fra Master. Vi oppfatter å beholde brancher i evigheter for å holde track på tidligere versjoner er ugunstig.

  2. Versjoner av tjenester beholdes som forskjellige repositories. Dette vil muliggjøre forskjellig tilgangstyring. Sammenligning mellom to versjoner vil på kort sikt måtte skje i utviklers eget lokale repo. (f.eks Win merge eller lignende).

  3. Vi vil jobbe med design for å en god opplevelse for de som har mange tjenester.

Vi har opprettet følgende issues

427

426