[PPNL-Techteam] Github

[Bèr Kessels]

Hallo,

TL;DR: Git moet het project in zijn geheel, reproduceerbaar, bevatten.
Dat kan deels door met makefiles de externe meuk binnen te trekken. En
door daar waar dat niet kan, die externe meuk gewoon in het project op
te nemen.
Het is niet alsof opslagruimte bij Github zoveel kost. En het is wél zo
dat de tijd om de juiste versie, fork en of variant te vinden,
downloaden en inzetten heel veel kost.

On 29-05-12 16:57, Bob Sikkema | DigitalForce.eu wrote:
> [snip]
> Git is enkel een repo. 

Nee. Zie onder.

> Je gaat niet modules die je wilt updaten, eerst
> naar git trekken, en vanuit daar updaten. 

Jawel dus, zie onder.

> Volgens mij had Bèr het in
> gedachte om git te gebruiken zodat de huidige opzet (productie)
> beschikbaar is voor andere leden (onder het mom van transparantie?), of
> om vanuit daar een dev environment te maken. Zelf zou ik dan liever
> drush gebruiken, maar 'k weet niet wat Bèr z'n idee exact was, en waarom.


Je zet een RCS op om drie redenenen:

* accountability, responsability.
* reversability.
* joinability.

En soms om een vierde:
* deployability.

## accountability, responsability.

Door Github/git te gebruiken krijgt iedereen credits waar nodig. En kun
je iedereen op zijn donder geven waar nodig (in SVN heet het commando
hiervoor svn blame, met als alias svn praise).

Het moge duidelijk zijn waarom dit allemaal handig en belangrijk is in
een project met veel los-vaste vrijwilligers en een overbezet team
core-members :)

Git is hiermee eerst en vooral een communicatiemiddel: je kunt altijd
opzoeken wie ookalweer die ene module erin zette (en waarom zij dat dat
deed). Je kunt altijd nagaan hoelang een veiligheidslek er al ingezeten
heeft. En je kunt altijd nagaan wie die vervelende bug ookalweer inbouwde.

## reversability.

Door te zorgen dat je git repo de volledige status van je project bevat,
kun je altijd enorm makkelijk terugrollen. Of opnieuw uitrollen.

Er is niets zo tijdrovend als tussen maanden aan (incrementele)backups
te moeten graven naar die ene versie van die ene module die nog goed wel
goed werkte. Helemaal omdat voor het graven (en terugzetten) van backups
root nodig is. Backups zijn noodprocedures. Je project helemaal 1op1
ergens reproduceerbaar klaar hebben staan is gewoon goed werken. :)

Uiteindelijk moet het dan ook zo zijn, dat iedere nieuwe (server)admin
met enkele goedgedocumenteerde commando's het volledige project binnen
een halfuurtje kan heropbouwen. Dat is gelukkig heel makkelijk te doen
met een makefile en git.

Git is hiermee dus een backupsysteem met documentatie van de
veranderingen en scripts om de omgeving snel weer op te kunnen zetten,
zonder daarvoor veel kennis van de interne werkingen en rariteiten van
dat project (je moet niet een Drupal expert zijn om de werkende site op
een nieuwe server uit willen rollen, bijvoorbeeld).

## joinability

Wanneer het zo makkelijk is om het project ergens op te zetten, is niet
langer toegang tot  de enige werkende omgeving (productie) nodig. En is
dat niet langer "de makkelijkste of snelste manier om even wat kleins te
veranderen".

Met drie of vier goedgedocumenteerde commando's heb je de PP.nl immers
op je macbook, linuxbak of windoos draaiend.
Dan kan iedereen die zin, tijd en energie heeft meewerken. In praktijk
verwacht ik vooral dat een wat kleiner team dan gewoon snel even kan
bijspringen als een core-team dat nodig heeft.

Verder is het (specifiek voor Drupal) een drama om "even snel iets te
prioberen". Een productiesite die eenmaal met bijvoorbeeld
organic-groups is geïnfecteerd komt daar nooit meer vanaf. Ja, Drupal
heeft eigenlijk gewoon een Norton Clean Sweep of reg-cleaner nodig ;).
Daarom is het in een goede ontwikkelstraat, met Drupal, zeer
onverstandig om OG (of Panels, of eigenlijk iedere module) "even te
installeren om te zien of het kan werken". Dat doe je dus lokaal, op een
snel opgezet kopietje. In de praktijk werkt dat uiteraard alleen maar
als je dat kopietje ook in een paar minuten draaiend hebt, anders is
"die productieomgeving" altijd makkelijker en sneller om het "even snel
te fixxen" :).

En als laatste werkt iedereen anders: de een wil over ssh met vim op
zijn webserver werken, de ander persé via een virtual-machine op zijn
laptop, weer iemand anders zweert bij XAMPP en emacs. Door decentraal te
werken: iedereen kan snel een kopietje trekken en aan de slag op haar
eigen omgeving, terwijl de productieomgeving dan heel strak volgens de
wensen en eisen van de serverbeheerders (gatekeepers) kan worden.

## Deployability

Als je dit allemaal goed het ingezet, kun je heel makkelijk allerlei
kleine, simpele scripts inzetten. Bijvoorbeeld:

Na een commit naar de "master" branch -aka een "nieuwe release- wordt
automatisch op de server een aantal commando's uitgevoerd die caches
legen, proxies resetten, de nieuwe code binnenhalen en daarmee een
nieuwe release uitrollen. Dit maakt het voor beheerders erg makkelijk:
ze hoeven enkel nog naar de master branch te schrijven, waar zij ook
alleen maar schrijfrechten hebben, en alles draait weer als een zonnetje.

Ik vermoed dat dit in dit project geen groot issue zal zijn, maar in
projecten waar je vijf, zes releases per maand doet, is dit het verschil
tussen 30% downtime en 2% downtime en een fulltime
release-manager/ontwikkelaar of een halfuur per week releasen.

Ook kun je de rest van de OTAP straat dan versimpelen.
Zodanig dat mensen deze ook echt gaan gebruiken.

bijv. altijd de laatste versie op dev.example.com hebben draaien. Of na
iedere commit de hele boel op een testserver neergooien en door de
testmolen te halen.

En natuurlijk is het mooi dat andere PPs het kunnen hergebruiken. En
mogelijk mooie verbeteringen doorvoeren waar wij dan weer wat aan
hebben. Maar dat is niet mijn hoofdgedachte geweest.

Bèr

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

  webschuur.com