16 patterns til konfigurationsstyring

•  Central kodebase
• Værktøjsunderstøttelse
• Byggeproces
• Løbende test af produkt
• Tredjepartselementer
• Særlige opgaver
• Release
• Regler og forventninger.

Central kodebase
Patterns 1. Mainline og 2. Active Development Line

Disse patterns handler om at etablere en central opbevaring af den primære kode og relateret (eks. test, data og dokumentation).

Pattern 1. Mainline (også kaldet Trunk) handler om at skabe én centraliseret kodebase, som er udgangspunktet for udviklingen, dvs. det er her man, brancher fra [branching handler at skabe forgreninger ved at duplikere kode under konfigurationskontrol, så modifikationer kan ske parallelt i flere uafhængige grene]. Formålet med dette er give plads til parallel udvikling, så udviklingsaktiviteterne ikke skal holdes fuldt synkrone hele tiden, da dette vil være en alvorlig reduktion af teamets produktivitet.

Pattern 2. Active Development Line er tæt relateret med forrige pattern, da den etablerer princippet om, at den udvikling, der sker i teams og hos individer løbende skal synkroniseres tilbage i Mainline. Det sikrer, at mainline fortsat indeholder det primære indhold. At synkroniseringen skal ske løbende, er baseret på triste erfaringer fra udviklingsforløb, hvor måneders og års arbejde skal integreres i en stor samlet aktivitet.

Værktøjsunderstøttelse
Patterns 3. Private Workspace og 4. Repository

Disse patterns er koblede og værktøjsnære, da de handler informationsteknologiske løsninger.

Pattern 4. Repository beskriver behovet for et centralt lager, hvilket i praksis bliver til en server for konfigurationsstyring (eks. Azure DevOps, Subversion, CVS, Ansible og Rational ClearCase) eller netværksbaserede systemer (eks. Git og Bitbucket).

Pattern 3. Private Workspace giver udviklerne deres eget område, hvor de kan arbejde uden at påvirke andre. I praksis kan det også være sådan, at hvert team har et workspace eller at hver task har sit workspace (se mere i Pattern 16). Det afgørende er muligheden for afkobling, så den samlede stabilitet ikke forringes, og der samtidigt gives plads til at bidrage og ændre.

Lokal byg og løbende test af product
Patterns 5. Private System Build, 10. Smoke Test og 11. Unit Test

Disse tre patterns understøtter et samlet workflow for at udviklerne kan afprøve deres ændringer uden at forstyrre andre.

Pattern 5. Private System Build handler om at kunne bygge en eksekverbar (eng.  build) til afprøvning ud fra egen kodebase, dvs. med egne ændringer. Formålet er at kunne afprøve det stade den lokale udvikling er på, inden den eventuelt integreres tilbage i Mainline.

Pattern 10. Smoke Test handler om at etablere hurtig og automatiseret test med det primære formål at sikre Mainline mod opdateringer, der skaber problemer. Forventningerne er ikke en komplet sikring af korrektheden af funktionalitet (også kaldet verifikation og validering), men at gennemføre en hurtig sikring mod kendte problemer.

Pattern 11. Unit Test fortsætter, hvor forrige pattern slap. Formålet med unit testing er at eftervise, at kontrakten for den givne unit er overholdt. Unit tests bør være simple at eksekvere, evalueres automatisk og tilstrækkeligt detaljerede.

Særlige opgaver
Patterns 8. Task Level Commit, 13. Private Versions og 16. Task Branch

Disse tre patterns er relativt uafhængige af hinanden, men handler alle om at håndtere undersøgelser og større opgaver, samt at give plads til kreativitet og eksperimenter.

Pattern 8. Task Level Commit har fokus på en samlet opgave (task), hvilket kunne være en ny feature, en løst opgave/fejl eller en refaktorering [refaktorering er en omskrivning af en eksisterende programkode, så den bliver enklere og derved lettere at læse og vedligeholde, mens dens funktionalitet bevares]. Dette pattern tager udgangspunkt i, at sådanne opgaver ofte består af flere koblede og afhængige ændringer, dvs. ikke kan begrænses til en enkelt stykke kode.  Behovet er derfor, at disse kan integreres i Mainline som en helhed (et samlet commit).

Pattern 13. Private Versions handler om at understøtte hurtige eksperimenter ved at skabe en isoleret såkaldt sandkasse hertil. Hvis eksperimentet har succes, så er der brug for mekanismer, hvor indholdet af sandkassen kan flyttes tilbage til et udviklingsspor.

Pattern 16. Task Branch favner opgaver, som er længerevarende og måske ikke er rettet mod næste release, men måske skal springe en eller flere udgivelser over. Formålet kan være at udvikle til en version, senere end den, der skal frigives næste gang, arbejde med større arkitektoniske ændringer eller at integrere flere produktlinjer. Implementeringen af dette pattern handler om at give plads til sådanne ændringer, som lever lidt ”udenfor normalen”, men samtidigt skal være under kontrol.

Regler og forventninger
Pattern 9. Codeline Policy

Dette pattern gælder for både det centrale og det lokale område, og er derfor et passende emne, inden vi går over til de sidste patterns, som hører hjemme i det centrale felt.

Når mange udvikler sammen, er der brug for at blive enige om regler og forventninger omkring arbejdet. Formålet med denne policy er at definere disse, hvilket eks. kan handle om:

• Hvad er under konfigurationskontrol, eks. udvikling, vedligehold, tredjepartskode eller releases?
• Hvornår og hvordan udføres check in og check ud?
• Hvornår og hvordan udføres branch og merge [merge er en handling, hvor branches nedlægges ved at integrere indholdet af flere forgreninger]?
• Hvem har adgangs til koden?
• Hvordan deles og forfremmes ændringer mellem branches og udviklingsniveauer?

Tredjepartselementer
Pattern 7. Third Party Codeline

Tredjepartskode skal håndteres anderledes og kræver derfor sit eget pattern. Eksempler er kode, som udvikles af eksterne, komponenter (eks. java beans), biblioteker (eks. Python pakker) og frameworks (eks. .NET).

Dette pattern behandler, hvordan samtidig (og måske endda også synkroniseret) udvikling af tredjepart kan integreres i den samlede kodebase, og hvordan ændringer kan håndteres.

Central byg og løbende test af produkt
Patterns 6. Integration Build og 12. Regression Test

Disse to patterns handler om at sikre integritet af indholdet i Mainline. De kan opfattes som centrale versioner af Pattern 5 henholdsvis 11.

Pattern 6. Integration Build sikrer at Mainline kan bygges, hvilket også er fokus for disciplinen Kontinuert integration. At kunne bygge Mainline viser ikke i sig selv så meget, men når den ikke kan bygges, så viser det, at der er problemer, som skal løses snart. Anbefalingerne til byggeprocessen er:

• Automatiser processen
• Byg det samlede system, ikke en delmængde
• Byg alt fra grunden (såkaldt ren maskine)
• Byg centralt og jævnlig (eks. om natten).

Pattern 12. Regression Test er automatisk test, der udføres på den netop byggede Mainline. Som navnet antyder, er formålet at sikre, at ændringer, der tilføres et system, ikke introducerer nye fejl. Herved fastholdes den værdi i Mainline, som er opnået.

Typiske tilgangsvinkler til regressionstest omfatter:

• Definer tests ud fra kendte og betydningsfulde risici
• Inkluder tests ud fra situationer, som tidligere har fejlet
• Verificer de krav, som kan verificeres automatisk.

Release
Patterns 14. Release Codeline og 15. Release Prep Codeline

Formålet med disse patterns er at udvælge og stabilisere indhold fra Mainline så der kan skabes en ny release af produktet. Dette sker samtidigt med, at udviklingen fortsætter og erfaringer fra releases (eks. rettede fejl eller mindre features) tilbageføres til Mainline.

Pattern 15. Release Prep Codeline beskriver en praksis, hvor indholdet fra Mainline udvælges, gøres komplet, stabiliseres og kvalitetssikres. Som sædvanligt er det et kompromis mellem dynamik og produktivitet; det ville være nemmere at skabe en release, hvis udviklingen blev stoppet, men det ville koste produktivitet. En release håndteres derfor ved at skabe en branch med dette specielle formål.

Pattern 14. Release Codeline handler om at kunne vedligeholde en release mens udvikling fortsætter. En release vil ofte kræve efterfølgende patches til fejlretning etc., og disse udføres i den branch, der er oprettet til den givne release. Der er derfor også en opgave med at tilbageføre disse fejlretninger til Mainline.

Opsummering

Formålet med denne beskrivelse er at give inspiration til et relativt komplekst emne. Følgende er en oversigt over patterns.