SVN, ticketing, collaborazione: servizio managed o fai da te?
8 September 2009 » In informatica, open source
Tag: assembla, repository, svn, ticketing
Da qualche tempo ho introdotto SVN in azienda per i progetti principali (o meglio i principali e tutti i nuovi). Accanto ad SVN ho testato Redmine come strumento per la gestione dei ticket e della collaborazione con il cliente (a differenza di Trac gestisce molteplici progetti). Interfacciandosi ad SVN, Redmine rappresenta la giusta connessione tra il team ed il cliente che può vedere in tempo reale ed in modo piuttosto trasparente ciò che succede al suo progetto.
Ora che sono ben chiari i vantaggi di una struttura del genere è giunto il momento di capire quale sia la miglior strada da seguire per mettere effettivamente a disposizione del cliente questi strumenti. Servizi managed o fai da te? Rispondere non è facile, credo ci siano molti aspetti da valutare prima di potersi schierare da una o dall’altra parte.
Ciò che riporterò di seguito sono una serie di considerazioni che spero mi aiutino a decidere al meglio.
Fai da te
Si ipotizza dunque di creare e gestire il servizio completo in proprio. Di cosa abbiamo bisogno?
- web server pubblico (per Redmine, Trac…)
- svn server
- backup
- connettività
Il primo è un semplice server web (LAMP) che installato a dovere si occupa di rendere pubblico il punto d’accesso del sistema di ticketing. Tale server dev’essere esposto al web quindi c’è bisogno di un ip pubblico (possibilmente statico) da utilizzare, inoltre avendo bisogno di accedere al server svn (che ipotizziamo essere nella LAN dell’ufficio) si capisce subito che i due devono poter comunicare tra loro. Ipoteticamente potrebbero anche essere rappresentati da una stessa macchina, la scelta dipende poi dalla disponibilità di risorse e da quanto si voglia spostare verso l’esterno i propri dati.
Infatti se per lo strumento di ticketing non credo ci si possano porre molte domande riguardo alla sicurezza (sistema web based che contiene un numero limitato di informazioni) è guardando all’svn (collegato al primo) che sorgono i primi dubbi. Quanto è pericoloso esporre il codice sorgente di tutti i propri progetti in una configurazione del genere? Nonostante si attuino tutte le best-practice per la gestione del servizio: autenticazioni, https, accesso in sola lettura dalla macchina web del ticketing, firewall decente per bloccare tutte le connessioni non necessarie…
Backup è un altro punto importante da non sottovalutare. Svn non è uno strumento di backup, si occupa di versioning ed in quanto tale la replicazione dei dati in caso di necessità deve essere gestita altrove. Ecco quindi che nasce una nuova attività da gestire oltre a quelle sopra elencate. Ma siamo sviluppatori ed i guadagni arrivano con il software o con i sistemi che dobbiamo gestire per lavorare?
Connettività indispensabile per erogare il servizio in modo continuativo ai clienti con una certa qualità. Spesso le offerte adsl aziendali lasciano molto a desiderare. Che sia davvero consigliabile intraprendere questo cammino?
Fai da te con deroga
Ipotizzando di avere un datacenter a disposizione, una colocation, un cage da qualche parte insomma che evita il problema della connettività e della sicurezza se vogliamo della lan aziendale come cambia la situazione? Resta ancora aperto il discorso della gestione dei sistemi che richiedono un minimo di manutenzione per quanto riguarda gli aggiornamente di sicurezza come minimo dei S.O. e dei software utilizzati. Inoltre non va trascurato il costo annuale di avere 1-2 server impegnati per tali compiti con N Gb di spazio disco occupati e tutte le altre risorse a contorno.
Servizio managed
Ok decidiamo di tenere “in casa” (o meglio “in ufficio”) meno cose possibili. Concentrandoci sul fatto che il core-business è realizzare software e non gestire sistemi. Ipotizziamo di appoggiarci ad un servizio tipo Assembla (per citare forse il più popolare?) che offre tutto ciò di cui abbiamo bisogno a prezzi che variano in base alle nostre richieste: repository, ticketing, collaborazione e strumenti di management. Si paga e si utilizza. Sicuramente fino ad una certa dimensione, sia in termini di numerosità che di spazio occupato dai progetti, questa pare essere la soluzione più economica.
I progetti risiedono fisicamente in una nuova posizione. Il cliente ha un suo posto dove richiedere nuove feature, verificare l’avanzamento dei lavori, consultare il wiki e condividere documenti. Gli sviluppatori utilizzano il repository per lavorare all’applicazione eseguendo i check out verso il server di sviluppo ed i commit (check in) verso il repository stesso dopo aver testato le modifiche introdotte. Chi di dovere potrà verificare i tempi da fatturare, le richieste già chiuse e quelle ancora in lavorazione.
Molti dei dubbi derivanti dalla configurazione precedente non esistono più, tuttavia ne resta uno bello grosso: c’è da fidarsi a caricare tutti i propri sorgenti su sistemi di terze parti?
Concludendo
Io un’idea me la sono fatta e credo si sia capito da ciò che ho scritto. Tuttavia mi farebbe piacere leggere eventuali consigli da parte di chi ha già attraversato questa fase e, perchè no, sentire eventuali valutazioni in merito fatte a suo tempo. I commenti sono aperti!
Potrebbero interessarti anche...
Commenti
4 Commenti per “SVN, ticketing, collaborazione: servizio managed o fai da te?”
Lascia un commento
Te come sei riuscito a convincere le alte sfere ad un cambiamento così drastico? Purtroppo da me siamo a livello di preistoria come workflow di lavoro, abbiamo un piccolo server privato casalingo su cui lavoriamo (per cui non c’è una separazione tra ambiente di dev e quello di test), senza un VCS qualsiasi e ci appoggiamo a widestore per un server che seppur dedicato, è un pacchetto tipicamente italiano preconfigurato (PHP5.2 con safe mode attivo, estensione filter disattivata, solo mysql) senza un subversion qualsiasi, ed ovviamente senza accesso alla shell, caricando e scaricando tutto tramite server ftp.
Mi da fastidio solo a pensarci, ma oggettivamente funziona, e non riesco a trovare degli argomenti validi per far installare un VCS su quel server (magari configurandolo decentemente e con accesso alla shell), e passare ad un metodo di lavoro diverso qua in azienda. Sono tutte cose per le quali avrei vantaggi io, non il capo a livello economico. E vaglielo a spiegare…
A proposito, al phpDay ho conosciuto Bazaar come alternativa a Subversion, l’ho provato per un pò ma non mi sono trovato benissimo (anche un pò per la lentezza), ora ho preso un libro su Git e vediamo se con questo mi trovo meglio.. Te hai mai provato un sistema distribuito al posto del modello centralizzato di Subversion? Concettualmente è più giusto come approccio, ma poi son gusti..
@Davide
Se hai vantaggi tu nel lavoro di tutti i giorni inevitabilmente questi si tramutano in vantaggi a livello economico.
La “mia” situazione di partenza è forse ancora peggiore: server di sviluppo Linux che tramite Samba condivide dello spazio disco con i client Win. Lì si faceva sviluppo e testing direttamente sul “repository” (se così si può chiamare). Non ti dico i problemi quando in 2 si doveva lavorare sullo stesso progetto…per non parlare di quando elimini qualcosa per sviluppare altro di nuovo e poi i cliente richiede la roba vecchia. O ti riempi di directory “_old” oppure passi ad SVN ed utilizzi strumenti come il revert.
Al phpDay c’ero ma non sono riuscito a seguire quel talk, tuttavia ho letto parecchio a riguardo di Git ed anche di Mercurial. Al momento resto con SVN con cui mi trovo molto bene.
Per quanto riguarda il fatto di far accettare il cambiamento alle alte sfere credo che tu li debba mettere di fronte alla cruda realtà dei fatti. Non è pensabile lavorare in quel modo, esistono strumenti utilizzati da molte aziende (grandi e piccole) in tutto il mondo con successo: perchè non sfruttarli? Credo che non ti sarebbe difficile stilare una lista di punti deboli dell’attuale sistema con conseguente focalizzazione su tutte quelle possibilità che possano portare a perdita di codice (sovrascritture per esempio) più facilmente quantificabili in vil denaro (perdi una giornata di codice? TOT euro).
In bocca al lupo!
La situazione di partenza è esattamente la stessa, non l’ho specificata bene ma anch’io mi ritrovo con /var/www condiviso tramite samba e ci lavoro con windows.. E se serve qualcosa, aprire Putty e lavorare da li.. Una sofferenza che immagino capisci..
Ecco allora armati di coltel… pazienza e fai valere le tue ragioni. Fai in modo che i colleghi capiscano i reali motivi per il cambiamento e siano dalla tua parte quando gli verrà chiesto dal capo “ma cos’è che pensi te di quello che dice?”.