ASL Best Practice ASL Proces Configuratiebeheer ASL Versie
ASL Best Practice ASL Proces Configuratiebeheer ASL Versie ASL 2 Soort document Voorbeeld Naam best practice Configuratie Management QRC Omschrijving van de inhoud Betreft een Quick Reference Card ten aanzien van configuration management. Hierin zijn ondermeer opgenomen: visie, doel, rollen, belangrijke begrippen, best practices, templates etc. Identificatie 231 Datum vrijgave voor publicatie 20 -06 -2013 Rubricering (indicatief) Teamgrootte applicatiebeheer: Klein (aantal fte < 10), Middel (aantal fte 10 – 20) , en/of Groot (aantal fte > 20). Vul hier de schaalgrootte in van het applicatiebeheer team: □ √ Klein □ √ Middel □ √ Groot Voorbehoud Deze best practice is oorspronkelijk opgesteld vanuit de eerste versie van het ASL Framework en naderhand overgezet naar ASL 2. Het kan dus zijn dat soms nog termen uit de eerste versie van het Framework terug te vinden zijn. Deze best practice is nog steeds geschikt voor toepassing in de praktijk. Opmerkingen Dit voorblad dient verwijderd te worden voor eigen gebruik. 1 12 -1 -2022
Versiebeheer Versie Datum Auteur Distributielijst Versie 0. 1 2 12 -1 -2022 Datum Aan Omschrijving
< Inhoud document> 3 12 -1 -2022
BEST PRACTICES ROLLEN Ontwikkelomgeving, waar ontwikkelaars bouwen, testen en debuggen: • deel geen ontwikkelomgevingen; • werk niet buiten de gemanagede omgevingen; • blijf synchroon met de baselines; • doe vaak check in’s. Configuration Manager Biedt een CM infrastructuur voor de afdeling en het projectteam. Verzorgt de inrichting van verschillende ontwikkel- en test- en deployment omgevingen. Is verantwoordelijk voor het opstellen van het CM plan. Baselines, een bij elkaar behorende set van source files en bijbehorende documentatie: • voer over elke baseline een beleid; • geef elke baseline een eigenaar; • zorg dat er een mainline is. Integrator Integreren/deployen software componenten tot een build. Is ook verantwoordelijk voor de planning hiervan. Branches, baseline varianten: • maak alleen branche wanneer dit noodzakelijk is; • maak geen kopie wanneer je een branche wil; • branch bij niet overeenkomend beleid; • branch zo laat mogelijk; • maak een brache in plaats van een freeze. Change Propagation, wijzigingen van de ene baseline naar de andere brengen: • maak de originele wijziging in die branche die het minst gewijzigd is sinds die is afgesplitst; • propageer snel en vaak; • zorg dat de juiste persoon de merge uitvoert. Builds, source files omzetten in een product: • source + tools = product; • check alle originele source files in; • scheid gecompileerde objecten van de source; • gebruik algemeen gebruikte tools om builds te maken; • maak vaak builds; • bewaar de build logs en de build output. Proces, regels voor al het bovenstaande: • volg change packages (files die betrokken zijn bij een wijziging); • volg gepropageerde change packages; • maak een onderscheid tussen een wijzigingen en een change package; • geef alles een eigenaar; • gebruik levende documenten. 4 12 -1 -2022 Ontwikkelaar Is verantwoordelijk voor het ontwikkelen en ontwikkeltesten van software componenten volgens de richtlijnen. ARTIFACTS Vastgestelde Programmatuur Bibliotheek Database waarin alle fysieke versies van alle product files en directories staan. Eigen werkruimte (ontwikkelomgeving) De persoonlijke werkruimte van een projectlid waarin die artifacts staan die nodig zijn om huidige taak te volbrengen (tools behoren tot de infrastructuur). Configuration Audit (CF-AUD) Controle van een baseline op ontbrekende artifacts, incomplete of afgeteste requirements. Opleverdocument (OLDOC) Beschrijft de inhoud van een baseline die gebruikt wordt voor de overdracht tussen OTAP omgevingen. Software Configuration Management Plan (SCMP) Beschrijft de uitvoering van configuratie management binnen een afdeling/project. Software Control & Distribution Management (SC&D) Het Software Control & Distribution proces. Configuration Management VISIE Een Configuration Management Systeem is van groot belang om de verschillende artifacts te beheren die door alle projectleden worden gemaakt. Het helpt problemen te voorkomen zoals gelijktijdige wijzigingen op hetzelfde artifact, informeren van alle belanghebbenden en het beheren van verschillende versies. DOEL • Beheer van alle artifacts (niet alleen code) • Eenduidige versienummering • Richtlijnen voor baselines (beleid) • Ondersteunen release-matig werken • Mogelijk maken om terug te springen naar vorige (stabiele) versies • Inzicht in de wijzigingshistorie (audittrail) BELANGRIJKE BEGRIPPEN Baseline beleid Afspraken voor het gebruik van de betreffende baseline. Denk hierbij aan: • Compilatie richtlijnen • Frequentie builds (óp afroep, dagelijks, wekelijks) • Voorwaarden (alleen geteste software in baseline) • etc. Dit beleid wordt vastgelegd in het Configuration Management Plan AANSPREEKPUNTEN TEMPLATES Template titel Locatie Rol xxxx. doc xxxxxxx Config. Manager xxxx. dot xxxxxxxxxxxxxx Integrator Naam Toestel
BRANCHING EIGEN WERKRUIMTE Werk in een eigen werkruimte, waar je zelf de versies van de code en componenten beheert. Je hebt dan totale controle over hoe en wanneer de omgeving wijzigt. Figuur 1 Mainline Development. In Figuur 1 wordt een simpel branching model getoond. Alle ontwikkeling wordt gedaan op de mainline (ook wel “home codeline” genoemd). Alleen in speciale omstandigheden wordt er een branch gemaakt. Maak een goed beleid over een branche, kies bij twijfel altijd voor het simpelste model. Mainline ontwikkeling betekent niet dat er geen branches worden gemaakt, het betekent dat de ontwikkelactiviteiten op een bepaald moment altijd terug komen bij één branch. Een eigen werkruimte bevat de volgende zaken: • source code die je wijzigt; • alle lokaal ‘gebuilde’ componenten; • verkregen ‘third-party’ objecten die je niet kunt of wilt ‘builden’; • ‘build objecten’ voor alle code in het systeem (kan ook een referentie zijn); • configuratie en data die nodig zijn om testen te draaien; • build scripts om binnen de werkruimte builds te kunnen maken; • Identificatie van de versies van alle componenten in het systeem. Een eigen werkruimte bevat niet: • privé versies van scripts die een beleid opleggen; • componenten die onder versiebeheer staan, maar van een andere bron zijn gekopieerd; • tools, deze moeten hetzelfde zijn over alle versies van het product. Niet elk project is geschikt voor deze aanpak. Complexe projecten met veel releases en implementaties hebben een complexere strategie nodig met betrekking tot branching. Een eigen werkruimte kan tools bevatten die het werk ondersteunen, zolang deze privé tools maar niet in tegenspraak zijn met de werkafspraken binnen de afdeling/het projectteam. MAINLINE DEVELOPMENT PROCEDURE Let op: dit is vooral op de implementatie discipline gericht, maar het geld voor alle rollen, disciplines en artifacts van het project. 1. Uitchecken: Haal de laatste versie op van de code en 2. 3. 4. 5. 6. 7. 5 build. Als je op een nieuwe brache gaat werken maak dan een nieuwe werkruimte aan. Breng de benodigde wijzigingen aan. Maak een build van het systeem in de eigen werkruimte. Test de gemaakte wijzigingen met een ontwikkeltest. Vernieuw de werkruimte door de laatste versie op te halen van alle niet aangepaste componenten. Maak een rebuild. Voer een test uit om te kijken of er geen showstoppers zijn. Check de wijzigingen in. 12 -1 -2022 STATUSSEN Er zijn vijf baseline niveaus met de volgende statussen: Nr. Status Req. Status Overige Status 1 Initieel Concept 2 Build Goedgekeurd Voorgesteld 3 Getest Geïmplementeerd Goedgekeurd 4 Released Gecontroleerd Vervallen 5 Geweigerd Vervallen Er wordt lineair door de statussen heengelopen. Statussen kunnen naar boven en beneden worden bijgesteld afhankelijk van de kwaliteit van het artifact / baseline. NUMMERING Nummering Versienummers worden als volgt opgebouwd: [R|A|B]<X>[. <Y>. <Z>][. BL<#>] R|A|B Release, Alpha of Bèta <X> <Y> <Z> Integer, staat voor een major release Integer, staat voor een kleine release Integer, staat voor een alternatieve release (patches, etc. ) Base Level (interne release) Integer voor interne release Tussen vierkante haken is optioneel BL # [] Voorbeelden R 1. 0 Release 1 R 2. 0. BL 5 Interne release bedoeld om tot Release 2 te komen B 1. 1 Bèta Release 1. 1 R 1. 0. 5 Onderhoudsrelease TOEPASSING NUMMERING Afstemming nummering Nummeringen wordt tussen de verschillende zaken niet afgestemd. Ieder artifact, groepering, product line hebben eigen onafhankelijk versienummer. Baseline samenstelling Een baseline volgt de eigen nummering. Er wordt bijgehouden uit welke versie van welke artifacts de baseline is opgebouwd. Koopcomponenten Onderdelen die gekocht worden hebben over het algemeen eigen nummering. Deze componenten worden wel onder versiebeheer geplaatst, maar de eigen nummering blijft behouden en zitten in een aparte branch. Tools (optioneel) Alle gebruikte tools binnen het project worden ook onder versiebeheer gebracht. Deze worden hetzelfde behandeld als koop componenten.
- Slides: 5