| 9 | | * De releasedatum is de datum dat de acceptatieversie wordt aangemaakt door de development-branch te kopiëren naar een release-branch. De releasedata vallen in principe op 31-3, 30-6, 25-9 en 15-12 (4x per jaar). |
| 10 | | * 5e week voor releasedatum: scope bepalen, ontwerpjes maken |
| 11 | | * 4e en 3e week voor releasedatum: bespreken ontwerpjes voor de grotere tickets, tickets afwerken |
| 12 | | * 2e week voor releasedatum: testen (en soms nog wat losse eindjes ontwikkelwerk), 2 pilot-AC's zoeken |
| 13 | | * week voor releasedatum: documenteren, changes overnemen en live (zie hieronder) |
| 14 | | * week na releasedatum: test bij 2 pilot-AC's, changes overnemen, bericht productieversie live |
| | 15 | FENAC ICT stuurt er op aan dat er ongeveer om de drie maanden een release |
| | 16 | (van een nieuwe versie) is; |
| | 17 | dat betekent dat de omvang van elke versie (gemeten in aantal tickets) |
| | 18 | beperkt is, en dat soms tickets gepland worden die pas over een paar |
| | 19 | versies gerealiseerd zullen worden. Dit wordt zo gedaan zodat we wel |
| | 20 | tijdig nieuwe versies uit kunnen brengen en geen onrust veroorzaken door |
| | 21 | sluipende veranderingen in de lopende versie. |
| 20 | | - '''Splash''' - de splash-screen controleren en bijwerken. Uit ticket #2454: |
| 21 | | - Open `images/splash.xcf` met GIMP, |
| 22 | | - Werk copyrightboodschap bij, dus ''(C) 2004 - 2010''. Klik op de layer ''achtergrond'' om die onzichtbaar te maken. Klik dan op het tekst-tool icoon (vette '''A''' in de toolbox). Dubbel-klik op het tekstveld dat nog een beetje zichtbaar is, dialoog verschijnt. Pas de tekst aan. |
| 23 | | - Sla op, |
| 24 | | - Sla op als `splash.png`, File -> Save As -> Vul filenaam in. Je moet nog kiezen om de PNG plat te slaan (''merge visible layers''). |
| 25 | | - Controleer met een andere plaatjes-viewer dat de splash nu klopt. |
| 26 | | - Commit de gewijzigde twee bestanden. |
| 27 | | - '''Merge''' - wijzigingen coordineren zodat development acht de laatste wijzigingen bevat. |
| 28 | | * Ga op de TRAC-website onder "Timeline" naar de vorige release, en loop zorgvuldig de changesets na die sindsdien zijn ingevoerd, draai eventueel een DIFF. Dit gebeurt elke week maar moet vlak voor een release nog een keer worden herhaald, zodat op het moment dat de release note uitkomt, alle wijzigingen zijn overgenomen. Wat men daarna inlevert, moet men zelf weten (versiebeheer waarschuwt dan ook). Zie ook [wiki:Ontwikkelhandleiding/Source#Wijzigingenovernemen kopje wijzigingen overnemen] voor technische details. |
| 29 | | * Controleer of alle wijzigingen in de loop van de vorige release zijn overgenomen: development/bin/adaptatie-diff v1.XXX development (vergelijk laatste versie met development). Loop de diff door op vergeten change sets. Als er regelmatig met svn merge is gewerkt is dit wellicht overbodig. |
| 30 | | - '''Test''' - technische en functionele tests van huidige development versie. Hiervoor moet je wel een werkende OpenAC configuratie-directory (bv. `.openac`) hebben. |
| | 31 | [[Image(release.png)]] |
| | 32 | |
| | 33 | Dit diagram laat zien hoe de ontwikkeling ongeveer gaat. Development is altijd gericht op |
| | 34 | de '''volgende''' versie. Op een gegeven moment zijn alle tickets van een |
| | 35 | versie-milestone afgehandeld in development en kan er naar een release |
| | 36 | van die versie toe gewerkt worden. Er zijn vier stappen naar een release: |
| | 37 | |
| | 38 | - Branch. Maak een plek in FENAC source-control om aan de release te werken. |
| | 39 | - Stabilize. Zorg er intern voor dat de nieuwe versie stabiel en bruikbaar is. |
| | 40 | - Test. Doe praktijk en productie-tests met een of meer pilot-ACs. |
| | 41 | - Release. Geef de nieuwe versie vrij voor algemeen gebruik. |
| | 42 | |
| | 43 | De poppetjes in het diagram geven ongeveer aan hoeveel mensen er bij betrokken |
| | 44 | zijn; de zwarte poppetjes zijn FENAC ICT, andere poppetjes zijn van de (pilot) ACs. |
| | 45 | |
| | 46 | Elke stap wordt hieronder in detail beschreven. |
| | 47 | Er is een extra, verborgen [#Pre-Branch stap vooraf aan branchen] |
| | 48 | gevolgd door het [#Branch branchen zelf], [#Stabilisatie een stabilisatie-fase], [#Test een formele test-fase] en uiteindelijk de melding van een nieuwe [#Release release]. |
| | 49 | |
| | 50 | == Pre-Branch == |
| | 51 | |
| | 52 | Voordat het eigenlijke SVN-branchen gebeurt, moet |
| | 53 | development helemaal up-to-date zijn. |
| | 54 | Hiervoor werken we de splash-screen bij, zorgen voor |
| | 55 | het volledig overnemen van adaptatie-wijzigingen |
| | 56 | en zonodig kern-wijzigingen en doen we een pre-branch test. |
| | 57 | |
| | 58 | - '''Splash'''. De splash screen staat in `images/splash.png` en `images/splash.xcf`. Van belang is dat het copyright jaar overeenkomt met het jaar van de release. |
| | 59 | - Open `images/splash.xcf` met GIMP. |
| | 60 | - Klik op de layer ''achtergrond'' om die onzichtbaar te maken. Klik dan op het tekst-tool icoon (vette '''A''' in de toolbox). Dubbel-klik op het tekstveld dat nog een beetje zichtbaar is, dialoog verschijnt. Pas de tekst aan. De tekst luidt steeds ''Copyright (C) 2004-nu'' (waarbij je ''nu'' vervangt door het jaar van de release). |
| | 61 | - Sla het XCF-bestand op (''File'' -> ''Save''). |
| | 62 | - Sla nu een export naar PNG op (''File'' -> ''Save As'' -> vul `splash.png` in, filetype wordt automatisch gekozen -> dialoog verschijnt, kies ervoor om de PNG plat te slaan door het vinkje ''merge visible layers'' aan te zetten. |
| | 63 | - Controleer met een andere plaatjes-viewer dat de splash nog goed is. |
| | 64 | - Commit de twee gewijzigde bestanden. |
| | 65 | - '''Merge'''. Neem alle nog-niet-gemergede wijzigingen over van de lopende release (of meerdere releases) naar development. Adaptatie-wijzigingen sowieso, en kern-wijzigingen volgens beleid. Zie hiervoor de alinea [wiki:/Documentatie/Ontwikkelhandleiding/Source#Wijzigingenovernemen wijzigingen overnemen] in het source-beheer document. |
| | 66 | - '''Clean'''. Schoon de code op door de formatterings-tools er op te gebruiken. Dit wordt beschreven in de source-code handleiding onder het kopje [wiki:/Documentatie/Ontwikkelhandleiding/Source#Clean clean]. |
| | 67 | - '''Test'''. Draai de unittests (voor de kern) om te controleren dat er geen regressies of onverwachte wijzigingen zijn voorgekomen. Je moet wel een werkernde OpenAC configuratie-directory (bv. `.openac`) hebben. |
| 32 | | python unittests.py --enable-all --no-adaptaties |
| 33 | | python unittests.py --with-adaptaties |
| 34 | | }}} |
| 35 | | * Draai de '''unit tests''' en fix zonodig, {{{python unittests.py --enable-all}}} . De unit tests vormen een automatische test die al ruime tijd voor alle releases wordt gedraaid. Deze test simuleert voor elk van de adaptaties een login en "drukt" vervolgens achtereenvolgens alle knoppen van het startscherm in. De unit test maakt gebruik van lege, standalone sqlite3-databases. |
| 36 | | * Draai de '''systeemtest'''. De systeemtest vormt een automatische back-to-back test voor de academische huizen. Deze voeren we bij elke release uit. In overleg met academische huizen wordt het testrapport overlegd, maar meestal blijft dit intern. '''TODO:''' ''hoe'' draai je de systeemtest? |
| 37 | | * Loop het [TestProtocol test protocol] door. Dit is een (gebruikers-)functionele test van OpenAC. |
| 38 | | - '''Opschonen''' - de source code helemaal netjes maken voor release. |
| | 69 | python unittests.py --enable-all --no-adaptaties |
| | 70 | }}} |
| | 71 | De unittests horen regelmatig gedraaid te worden en bij gehouden te zijn, |
| | 72 | maar deze stap vormt een extra controle. Er mogen hier geen |
| | 73 | overwachte FAIL resultaten bijzitten en al helemaal geen ERRORs (dat |
| | 74 | vereist onder andere dat je een bruikbaar Grouper test-certificaat hebt geinstalleerd). |
| | 75 | |
| | 76 | Pas als de unittests "clean" zijn (in het ICT werkoverleg kan worden besloten wat dat precies inhoudt) is de pre-branch fase voltooid. |
| | 77 | |
| | 78 | == Branch == |
| | 79 | |
| | 80 | Het maken van een branch gebeurt door met SVN een '''kopie''' te maken |
| | 81 | van development naar de `release/` directory in de SVN repository. |
| | 82 | Dit gaat het snelst op de SVN server zelf, maar kan |
| | 83 | ook remote: |
| | 84 | {{{ |
| | 85 | SVN=https://svn.openac.fenac.nl/ |
| | 86 | svn cp $SVN/development/ $SVN/release/v2.XXX |
| | 87 | }}} |
| | 88 | Vervang hierbij `v2.XXX` door het nummer van de nieuwe versie. |
| | 89 | Kopieen op deze manier zijn goedkoop: op de server gebruikt het maar |
| | 90 | heel weinig diskruimte. |
| | 91 | |
| | 92 | Daarna kan je (als ontwikkelaar) meteen de nieuwe branch |
| | 93 | uitchecken en eventueel opschoningsacties (ongeschikte |
| | 94 | adaptaties of hulp-directories verwijderen). |
| | 95 | |
| | 96 | [[NoteBox(tip, Voorheen (in versie 1) was er een script `bin/release` dat hielp bij het maken van een release door enkele checks uit te voeren en dan stapsgewijs "het nodige" te kopieren, maar in de praktijk bleek dit niet goed te werken.)]] |
| | 97 | |
| | 98 | == Stabilisatie == |
| | 99 | |
| | 100 | In de stabilisatie-fase gaan we op zoek naar bugs die zich in de kersverse |
| | 101 | release voordoen '''voordat''' dit zichtbaar wordt voor de ACs. Problemen |
| | 102 | die hier gevonden en opgelost worden, kunnen ook zo opgelost worden in development. |
| | 103 | |
| | 104 | - '''Test'''. Draai de unittests nog een keer om te controleren of |
| | 105 | de release nu als aparte versie nog werkt. Draai vervolgens ook |
| | 106 | de adaptatie-unittests: |
| 40 | | sh bin/clean |
| 41 | | python unittests.py --enable-all |
| 42 | | svn commit |
| 43 | | }}} |
| 44 | | * Draai {{{bin/clean}}} en commit eventuele bestanden die nog geen eol-style LF hadden. |
| 45 | | * Draai nog 1x de unit tests, {{{python unittests.py --enable-all}}} |
| 46 | | * Doe nog eens reindent om de code style recht te trekken, {{{python bin/reindent.py `find . -name *.py`}}} |
| 47 | | - '''Branch''' - in SVN de branch maken |
| 48 | | * Draai {{{bin/release 1.XXX}}} om development te kopiëren naar de nieuwe release in SVN. Geef een versie-nummer op, met of zonder "v", die overeenkomt met de gewenste branch-naam onder `release/`. |
| 49 | | - '''Test nogmaals''' - of het na de branch nog doet. |
| 50 | | * Check de nieuwe versie uit en controleer nogmaals dat het -- nu als eigen release -- nog steeds start. Loop nogmaals |
| 51 | | cluchtig het test protocol door. |
| 52 | | * Start een eerdere versie op, ga naar versiebeheer en controleer dat (1) de nieuwe release in de versies lijst staat en (2) opschakelen naar de nieuwe release kan. |
| 53 | | - '''TRAC Bijwerken''' - |
| 54 | | * Maak de adaptatiemap in de nieuwe release schrijfbaar voor centra door 3 regels te kopiëren in de TRAC configuratie. Pas `apache/auth/openac-svn.auth` in sysconfig aan. |
| 55 | | * Maak in TRAC via de Admin panel een nieuwe versie aan in [/admin/ticket/versions] zodat die voortaan te selecteren is in de web-interface. Zet geen "v" in deze versienummers. |
| 56 | | * Maak eventueel een nieuwe milstone aan voor een nieuw en toekomstig te plannen release. Meestal hebben we nu drie releases vooruit milestones. |
| 57 | | * Maak ook in het voren alvast een release-notes pagina aan voor een volgende release. |
| 58 | | - '''Announce''' - maak de nieuwe versie bekend |
| 59 | | * Maak een nieuwe starterkit. |
| 60 | | * Werk '''VERSIES.txt''' bij door de releasedatum aan de laatste versie toe te voegen en de omschrijving af te maken. Daardoor verschijnt het in de beschikbare versies lijst van de ACs. |
| 61 | | * Stuur een release-bericht naar openac@fenac.nl. Denk daarbij goed na welke migraties er allemaal gebeuren bij deze nieuwe versie. |
| | 108 | python unittests.py --enable-all --no-adaptaties |
| | 109 | python unittests.py --with-adaptaties |
| | 110 | }}} |
| | 111 | De gewone unittests gebruiken de geconfigureerde OpenAC adaptatie, |
| | 112 | terwijl de adaptatie-unittests voor elk van de adaptaties een login simuleert en vervolgens op alle knoppen "drukt". De unit test maakt gebruik van lege, standalone sqlite3-databases. |
| | 113 | - '''Systeemtest'''. De systeemtest vormt een automatische back-to-back test voor de academische huizen. Deze voeren we bij elke release uit. In overleg met academische huizen wordt het testrapport overlegd, maar meestal blijft dit intern. '''TODO:''' ''hoe'' draai je de systeemtest? |
| | 114 | - '''Testprotocol'''. Loop het [wiki:Documentatie/Ontwikkelhandleiding/TestProtocol testprotocol] door. Dit is een handmatige test van functionaliteit door eindgebruikers. Het testprotocol wordt af-en-toe uitgebreid met nieuwe specifieke situaties om uit te proberen. Het is nuttig om het protocol uit te printen en vervolgens stappen af te strepen. |
| 63 | | == Starter Kit == |
| | 116 | Als de nieuwe versie na enig serieus getest stabiel lijkt, |
| | 117 | is de stabilisatiefase voorbij (mits de unittests nog |
| | 118 | met succes doorlopen worden). Let hierbij op dat er wel |
| | 119 | een volledige ketentest van gebruikershandelingen uitgevoerd wordt. |
| | 120 | |
| | 121 | == Test == |
| | 122 | |
| | 123 | TODO: procedure met pilot-AC is ergens beschreven? |
| | 124 | |
| | 125 | == Release == |
| | 126 | |
| | 127 | De technische handelingen voor het uitbrengen van een release |
| | 128 | hebben te maken met SVN en TRAC. Daarnaast wordt meestal een |
| | 129 | nieuwe starterkit en technische documentatie gemaakt, en tot slot |
| | 130 | wordt de release van de nieuwe versie aangekondigd aan de ACs. |
| | 131 | |
| | 132 | - '''TRAC Bijwerken'''. |
| | 133 | - Maak de adaptatiemap in de nieuwe release schrijfbaar voor centra door 3 regels te kopiëren in de TRAC configuratie. Pas `apache/auth/openac-svn.auth` in sysconfig aan. |
| | 134 | - Maak in TRAC via de Admin panel een nieuwe versie aan in admin/ticket/versions zodat die voortaan te selecteren is in de web-interface. Zet geen "v" in deze versienummers. |
| | 135 | - Maak een nieuwe milstone aan voor een nieuw en toekomstig te plannen release. Meestal hebben we nu drie releases vooruit milestones. |
| | 136 | - Maak ook in het voren alvast een release-notes pagina aan voor een volgende release. |
| | 137 | - '''SVN Bijwerken'''. |
| | 138 | - TODO: ook hier permissies aanpassen? |
| | 139 | - VERSIES.txt bijwerken in development. Voeg een nieuwe regel toe bovenaan VERSIES.txt om de nieuwe versie zichtbaar te maken in het versiebeheerscherm van OpenAC. We houden tegenwoordig de release-notes op TRAC bij, dus er hoeft geen lang verhaal in te staan. Een regel met de versie en een regel samenvatting is genoeg. Let op de twee lege regels! |
| | 140 | {{{ |
| | 141 | v2.002, 22-10-2012 |
| | 142 | <leeg> |
| | 143 | * OpenAC 2.0 met DOT/Grouper |
| | 144 | <leeg> |
| | 145 | }}} |
| | 146 | - '''Starterkit'''. Zie [#Starterkit het kopje starterkit], hieronder. |
| | 147 | - '''Technische Documentatie'''. Zie [#TechnischeDocumentatie het kopje technische documentatie], hieronder. |
| | 148 | - '''Announce'''. TODO: voorbeeldaankondiging. |
| | 149 | |
| | 150 | |
| | 151 | |
| | 152 | = Starterkit = |
