[PPNL-Techteam] Aanvalsplan website.

[Bèr Kessels]

Hallo,

Hierbij een plan om de beschikbare resources rondom de site wat beter te
kunnen benutten.

Allereerst: we moeten geen lopende zaken omgooien. Laat vooral doorlopen
wat nu al loopt:) Het is vooral een plan om nu op te tuigen voor fase 2
en daarna.
Ik wil graag een reactie op dit plan, evt om het bij te spijkeren, maar
liefst om meteen aan de slag te kunnen.

TL;DR: Github, een dev-server en wat scripts zodat iedereen die dat wil
lokaal kan ontwikkelen en bijdragen en de admins minder werk hebben om
het te deployen, maar toch de enigen zijn die toegang hebben tot
productieservers enszo.

Het idee is om het geheel in te richten als een opensource project. Met
één Linus'-achtige gatekeeper die kan evalueren en deployen naar de
productie. En maar één persoon die admin-rechten heeft op de Drupal
(eventueel kan zij of hij mede-admins aanstellen of weer intrekken)

* Ik maak op github een project en organisatie aan. Voeg daar de juiste
personen met juiste rechten aan toe.
* Iedereen levert mij (per mail of anders) de code aan, ik voeg die
samen en plaats die in git/github.
* Voorlopig laat ik de issue-queue, wiki en dergelijke aldaar uitstaan,
zover dat kan: die hebben we immers al elders.

* Ik zet een -dev server op. Zonder tegenbericht zal ik een linode
aanvragen en voor een half jaar bekostigen/doneren. Liever breng ik dit
echter onder op een bestaande server die in beheer van de PP is, ik
ontvang daarvoor graag informatie :)
* Ik zet een toegangssyteem/-administratie op die -dev op. Met een heel
simpel accountbeheer, waarbij de beheerder (afhankelijk van antwoord
hierboven) gegevens van iemand krijgt en die persoon dan adminrechten
kan krijgen op de Drupal-site op -dev.
* Ik zet een simpel deployment-script op dat ervoor zorgt dat de
develop-branch van bovengenoemde github repo altijd op deze -dev staat:
als daarin code gecommit wordt door de gatekeeper staat het ook meteen
op de -dev.
* Ik maak een simpele tool waarmee de database van drupal rigoreus
ge-anonimiseerd wordt (enkele tables worden geleegd, anderen
ge-sed/awked) en geëxporteerd wordt en nachtelijks in de repo terecht
kan komen.

Dan is al het benodigd materiaal publiekelijk beschikbaar om per direct
aan de slag te gaan. Iedereen kan hiermee op zijn eigen omgeving een
kopie van de pp site opzetten om te gaan klussen. Forken, pull-requesten
en wat dies meer zij.

De gatekeeper krijgt dan, tijdens ontwikkelen van de site, twee zaken
aangeleverd:
* Pull requests (nieuwe modules, theme-aanpassingen, eigen modules,
vertalingen, etcetera)
* Releasenotes: een wikipagina waarop staat welke knoppen, instellingen
enzo in het Drupal-backend ingedrukt moeten worden[1].

Verder:
* Schrijf ik een korte contributers-guide. Met wat opmerkingen over
branching, guidelines en waar meer informatie te vinden is.
* Maak ik later een drush makefile waarmee potentiele contributors nóg
makkelijker en sneller even een pp.nl copie lokaal kunnen installeren.

  Groet,
     Bèr

[1] Dit is helaas een direct gevolg van het model van Drupal: je kunt er
niet omheen:
* Of de developer moet volledige admin toegang krijgen tot de site (en
dus potentieel tot belangrijke delen van server)
* Of de enige admin moet alles zelf administreren.

Een derde optie is features (https://drupal.org/project/features) maar
dat is zo ingrijpend en bovendien eigenlijk gewoon nog niet
productieklaar, dat ik dat nu nog niet zou willen inzetten. TL;DR:
features zorgt voor een mogelijkheid om zo een releasenote (waar klik je
wat voor config ineen in het backend) in code te vangen en met de code
mee te deployen.

-- 
  Open Source Webdevelopment.
  Ruby on Rails development.
  Drupal Development and -consultancy.

  webschuur.com