Creare un archivio di testing per terze persone usando git & pbuilder

Succede che uno fa un lavoro e che qualcun’altro (il committente) debba visionarlo per dare un giudizio o feedback su quanto fatto, ma succede anche che questo non se ne intenda di computer, quindi per fare un test di un progetto django in locale, mantenuto tramite git, non possa dirgli di "clonarsi il repository dall’URL blabla e inizializzare il database in maniera opportuna e poi leggi il README per le istruzioni e se non funziona RTFM".

La soluzione è creare un mitico archivio con tutte i file del progetto, uniti ai file che non si desidera tenere sotto versioning in quanto di progetti esterni (basti pensare alle librerie jquery o nel mio caso a django-pagination che ho installato in locale); la soluzione più semplice sarebbe di creare un archivio con il tree su cui sto lavorando io, però questa soluzione non è ottimale perché probabilmente ci sarebbero dei file spuri e non rappresenterebbe un test vero e proprio della deploiabilità del progetto. Del resto come ci insegna lo zen dell’admin, "Don’t deploy what you can’t maintain".

Quindi per prima cosa bisogna creare un archivio con il contenuto del progetto allo stato attuale e con git è di una disarmante facilità (quanto sono fico neh…)

$  git archive –prefix=my-project/ –format=zip
                        –output=/tmp/my-project-`git describe –tags`.zip
                        HEAD

 Poi per evitare di scrivere uno script da inserire nell’albero dei sorgenti per generare il rimanente, si può usare gli alias all’interno di git: prima di tutto all’interno del repository eseguire git config -e che aprirà ilvostro editor di fiducia e aggiungete la seguente riga

 [alias]
        snapshot = "!VERSION=`git describe –tags`; rm -vfr /tmp/my-project/ &&
                mkdir /tmp/my-project &&
                cp -r /usr/src/django-pagination-1.0.5/pagination
                        /tmp/my-project/ &&
                cp –parents media/js/jquery.js /tmp/my-project/ &&
                cp –parents media/js/jquery-ui.js /tmp/my-project/ &&
                cp –parents media/css/jquery-ui.css /tmp/my-project/ &&
                cp -r media/css/no-theme/images /tmp/my-project/media/css/ &&
                git archive –prefix=my-project/ –format=zip
                        –output=/tmp/my-project-${VERSION}.zip
                        HEAD &&
                cd /tmp/  && 
                zip -r my-project-${VERSION}.zip
                        my-project/*"

(N.B: modificato dalla pubblicazione iniziale a causa del modo in cui vengono prefixati i file nell’archivio). Notare il punto esclamativo all’inizio dell’alias che indica a git che quello è proprio un comando della shell e non un sottocomando di git. Per eseguire questo popo di routines dare git snapshot; vi ritroverete con un archivio nella directory temporanea contenente tutto il (minimo) necessario per usare il progetto.

Adesso si necessita di avere un ambiente pulito in cui testare l’archivio per sapere quali pacchetti bisogna far installare al nostro committente: per questo ci viene in aiuto pbuilder; pbuilder è un programma che permette di creare un chroot apposito per compilare pacchetti debian ma può essere usato anche per eseguire comandi in un ambiente cristallino. Prima di tutto installate pbuilder (leggetevi il manuale per sapere come fare) e create uno script in /tmp/ con il seguente contenuto

#!/bin/sh

apt-get install -y unzip python python-django python-reportlab
cd /tmp/
unzip my-project-v0.2.3-2-g152ce86.zip || exit 1
cd my-project
deploy/startup.sh || exit 1
python manage.py runserver

(deploy/startup.sh è un mio script per generare in automatico il database con i dati minimi necessari per il login all’interno del sito); poi per il test eseguire

 # pbuilder –execute –bindmounts /tmp/ — script.sh

Quest’ultimo comando crea come detto già sopra un(a?) chroot montando all’interno la directory /tmp/ in modo da poter vedere l’archivio creato con il comando snapshot. L’unico problema è la lentezza, ma se il tutto funziona almeno si è sicuri che nei limiti dell’umano il progetto django funzionerà anche in qualsiasi altro computer (a patto di installare django of course). Puntando il browsera localhost:8000 dovreste vedere il sito girare. Può sembrare una cazzata quanto esposto, ma vi assicuro che automatizzare il tutto aiuta non poco a sveltire il processo produttivo e noi lo sappiamo quanto è importante il PIL… ahhahahahahah