Hvordan etablerer du kildekontroll og releaseprosess?
Utarbeidet med KI.
Kildekontroll gir historikk og mulighet til å rulle tilbake. Denne veiledningen beskriver et oppsett som er realistisk for et lite team.
- 7 steg
- Total tid: 4 t
- Forberedelse: 2 t
- Resultat: Konfigurasjon under versjonskontroll med en avtalt releaserutine
Nødvendige verktøy
- Et Git-repositorium — Azure DevOps eller GitHub.
- Verktøy for å pakke ut solutions — Power Platform CLI eller tilsvarende.
Kom i gang
1.Pakk ut solutionen til filstruktur
En eksportert solution er én stor fil. Pakket ut blir den mange små filer, én per komponent. Det er den utpakkede formen som gir mening i Git — den store filen viser ingen forskjeller.
2.Legg inn en første versjon som utgangspunkt
Sjekk inn dagens tilstand før dere endrer noe. Da har dere et sammenligningsgrunnlag fra dag én.
3.Avtal hvem som sjekker inn når
Etter hver meningsfull endring, ikke én gang i måneden. Historikk med store hopp er nesten like lite nyttig som ingen historikk.
Etabler releaserutinen
4.Skill mellom utviklingsgren og releasegren
Det som er i produksjon skal kunne identifiseres presist. En egen gren eller et versjonsmerke per release gjør at dere kan gjenskape nøyaktig den tilstanden.
5.Automatiser bygg og distribusjon når rutinen sitter
Begynn manuelt til dere vet hvordan løpet ser ut. Automatiser deretter det som gjentar seg. Å automatisere en rutine ingen har prøvd, gir bare raskere feil.
6.Merk hver produksjonsrelease
Versjonsnummer knyttet til det som faktisk står i produksjon. Dette er det som gjør en tilbakerulling mulig framfor teoretisk.
7.Skriv en kort releaselogg
Hva ble endret, av hvem, og hvorfor. Tre linjer per release er nok, og det er dette som besvarer spørsmålet om hva som endret seg da problemet oppsto.
Diskusjon
Still et spørsmål eller del hva som hjalp deg.
