Hoe ik binnen 10 seconden mijn WordPress blog update

NedStars SmileyIn een vorige post schreef ik al over het Deployment Script dat we vanuit NedStars recentelijk open-source hebben gemaakt. Inmiddels zijn we al bij versie 1.2 aanbeland, en heb ik de tool nu ook ingezet voor deze weblog. Hieronder leg ik uit hoe ik dit heb gedaan, en hoe je zelf ook heel eenvoudig je WordPress installatie kunt updaten met gemaakte wijzigingen. Dit is vooral nuttig voor de ontwikkelaars onder ons, zodat je bijvoorbeeld gemakkelijk een nieuwe versie van je eigen template of plugin online kunt zetten.

Screenshot Deploy Script

Stap 1. Vooraf

In dit artikel ga ik uit van mijn eigen WordPress omgeving. Ik host die op een eigen VPS, en heb dus volledige controle over de geïnstalleerde software en tools. De onderstaande stappen zullen op een shared hosting pakket hoogstwaarschijnlijk niet werken, omdat ze allen SSH access vereisen. Mijn server is als volgt ingericht:

  • Ubuntu Server 12.04 LTS
  • Apache 2.2
  • PHP 5.3
  • MySQL 5.5
  • Git 1.7.9

Bovendien ga ik er in dit artikel vanuit dat je al kennis hebt van Git, en je de broncode van je WordPress blog daar al in hebt staan, of die er in stap 2 zelfstandig in weet te zetten.

Verder is het belangrijk om te weten dat het Deploy Script de volgende stappen doorloopt:

  1. Controleren of er voldoende schijfruimte is voor de uit te voeren operaties
  2. Uit Git ophalen van de geconfigureerde branch of tag (d.m.v. het git archive commando, zodat enkel de files worden gedownload, en niet de complete repository), en in een tijdelijke map plaatsen, bijv. “www.new”
  3. Backup maken van de MySQL database die bij de website hoort (optioneel)
  4. Backup maken van de webroot die bij de website hoort (optioneel)
  5. Kopiëren van bestanden/mappen die niet overschreven mogen worden uit Git naar de nieuwe tijdelijke map (bijvoorbeeld de map wp-uploads, en de wp-config.php file)
  6. Verwijderen van bestanden of mappen die tijdelijk van aard zijn (bij WordPress kunnen dit bijvoorbeeld cache bestanden zijn)
  7. Webroot map hernoemen van bijv. “www” naar “www.old”
  8. Tijdelijke map hernoemen van “www.new” naar “www” zodat dit de nieuwe webroot wordt
  9. Notificaties versturen via e-mail, Pushover of Notifo.

Stap 2. Git inrichten

Voor privé projecten maak ik gebruik van de gratis Git hostingdienst BitBucket (een product van mijn favoriete softwarebedrijf Atlassian). Dit is een concurrent van GitHub die grotendeels dezelfde functionaliteiten biedt, maar met als belangrijkste voordeel dat je met een gratis account onbeperkt private repositories kunt aanmaken.

BitBucket logo

Bij NedStars gebruiken we over het algemeen Vincent Driessen’s Git Branching Model. Dit is een simpele maar robuuste werkwijze, en past erg goed bij Git. Voor privé projecten probeer ik dit model ook aan te houden, maar vaak in afgezwakte vorm. Zo sla ik de stap met release branches vaak over, maar maak ik juist wel weer intensief gebruik van feature branches.

Voor welk branching model of Git hosting provider je ook kiest, ik ga er vanuit dat je na deze stap een werkende Git repository hebt, en je source-code daar ook in hebt staan.

Stap 3. Deploy Script installeren

Log in op de server, en voer het volgende commando uit: (ik heb ervoor gekozen om dit in mijn home directory uit te voeren, maar je kunt het script in elke gewenste map installeren)

git clone git://github.com/nedstars/Deploy-Script.git Deploy-Script

Deze actie maakt een nieuwe map aan genaamd Deploy-Script, met daarin een shell script genaamd “deploy”. Voer vervolgens het volgende commando uit:

cp sources/example.wordpress.conf.xml wordpress.conf.xml

Bewerk vervolgens het bestand met je favoriete editor (in mijn geval nano):

nano wordpress.conf.xml

Stap 4. Configuratie

Deze configuratie file heeft al enkele voorgedefiniëerde waarden specifiek voor WordPress. Op GitHub vind je een volledig voorbeeld bestand, waarin alle opties genoemd staan. Mijn eigen configuratie file ziet er als volgt uit:

<?xml version="1.0"?>
<config version="1.2">
<database>
  <read_from_config>n</read_from_config>
  <host>localhost</host>
  <username>wouterdaan_live</username>
  <password>*************</password>
  <dbname>wouterdaan_live</dbname>
</database>

<git>
  <repo>git@bitbucket.org:wouterdaan/wouterdaan.nl.git</repo>
  <source_folder>source</source_folder>
</git>

<notifications>
  <email_addresses>
    <address></address>
  </email_addresses>
  <notifo_users>
    <user></user>
  </notifo_users>
  <pushover_users>
    <user>************************</user>
  </pushover_users>
</notifications>
<paths>
  <web_live_path>/var/www/wouterdaan.nl/</web_live_path>
  <temp_new_path>/var/www/new.tmp.wouterdaan.nl/</temp_new_path>
  <temp_old_path>/var/www/old.tmp.wouter.daan.nl/</temp_old_path>
</paths>
<backup>
  <folder>/var/backups/www/deploy/live/</folder>
  <retention_days>14</retention_days>
  <make_database_backup>y</make_database_backup>
  <make_file_backup>y</make_file_backup>
</backup>
<preserve_data>
  <folders>
    <folder>wp-content/uploads</folder>
  </folders>
  <files>
    <file>sitemap.xml</file>
    <file>sitemap.xml.gz</file>
    <file>wp-config.php</file>
  </files>
  <google_files>y</google_files>
</preserve_data>
<permisions>
  <user>www-data</user>
  <group>www-data</group>
</permisions>
</config>

In de configuratie file wordt de map voor de MySQL en file backup gedefinieerd. Deze moet nog even worden aangemaakt, met het volgende commando:

mkdir /var/backups/www/deploy/live

Stap 5. Uitvoeren van je eerste deployment

Na deze stappen ben je klaar om je eerste deployment uit te gaan voeren! Uiteraard raad ik aan om dit eerst een keer uit te proberen op een testomgeving, en om voor de eerste keer altijd voor de zekerheid een aparte backup van je WordPress installatie te maken.

Voer het volgende commando uit:

./deploy -c wordpress -b master

Dit commando voert een deployment uit aan de hand van de wordpress.conf.xml configuratie, en haalt de laatste versie uit de master branch. Het deploy script heeft de volgende parameters beschikbaar:

-c <name>           Alias for --config.
-t <tag #>          Alias for --tag.
-b <branch>         Alias for --branch.

--config <name>     Will set file deploy.<name>.conf.php.
--tag <tag #>       Tag to be deployed.
--branch <branch>   Branch to be deployed.
--debug             Debug modes: default = false.
--quiet             Quiet modes, only output warnings and exceptions, default = false.
--version           Shows version information of Oink.

Vervolgens is het een kwestie van even wachten, en je eerste deployment is geslaagd!

Screenshot Deploy Script

In de praktijk

Persoonlijk gebruik ik deze methode voor alle code-wijzigingen aan mijn WordPress blog. Dus ook voor plug-ins & templates updaten of installeren. FTP toegang heb ik om beveiligingsredenen uitgeschakeld, dus via de Admin interface kan ik überhaupt niets installeren of updaten. Bovendien is dat een potentieel gevaarlijke manier van werken: ik ga het liefst op een testomgeving eerst kijken of een plugin wel goed functioneert, voordat ik deze in productie zet. Mijn eigen workflow is daarom als volgt:

  1. Als WordPress een melding geeft dat een nieuwe versie van een plugin beschikbaar is download ik de laatste versie handmatig uit de Plugin Directory.
  2. Op mijn ontwikkelomgeving maak ik een nieuwe feature branch aan (git checkout -b {pluginnaam}-{versienummer}), en daarin kopieer ik de nieuwe versie van de plugin (overschrijf de bestaande bestanden).
  3. Op mijn lokale omgeving test ik of alles nog werkt.
  4. Als dat het geval is merge ik de feature branch weer terug naar develop, en push ik dat naar de origin:
    git checkout develop
    git merge {pluginnaam}-{versienummer}
    git push origin develop
  5. Daarna kan de feature branch verwijderd worden:
    git push origin :{pluginnaam}-{versienummer}
    git branch -d {pluginnaam}-{versienummer}
  6. Zodra ik vervolgens klaar ben voor een volgende release (dit kan direct zijn, maar kan ook zijn nadat ik klaar ben met andere aanpassingen waar ik mee bezig was), merge ik develop naar master, maak ik een tag aan, en voor ik het deploy script uit:
    git checkout master
    git merge --no-ff develop
    git push origin master
    git tag -a v1.x.x -m "Tag 1.x.x. aangemaakt"
    git push origin v1.x.x
    ./deploy -c wordpress -t v1.x.x

Afsluitend

Ik hoop dat dit als eerste introductie een inkijkje geeft in mijn eigen werkwijze, en de mogelijkheden van het Deploy Script. Omdat deze tool inmiddels al op diverse systemen van NedStars in productie wordt gebruikt is deze al goed getest. Wel wordt er nog volop ontwikkeld, en zijn er nog genoeg ideeën voor verdere uitbreiding.

Uiteraard is feedback altijd welkom, en juichen we hulp in de vorm van bugfixes, nieuwe features, of simpelweg ideeën heel erg op prijs!