consiglio su code management
71 views
Skip to first unread message
Sandro guly Zaccarini
Jan 14, 2015, 6:32:05 AM1/14/15
to devops...@googlegroups.com
ciao all, sono di fronte alla ristrutturazione completa
dell'infrastruttura di sviluppo di un cliente che lavora principalmente
su php.
ragionando sui vari aspetti, ho pensato sia utile confrontarsi con
come operate anche voi devops.
le necessita' sono relativamente semplici:
* versioning del codice, integrato con la gestione delle issue
* continuous integration, con preferenza su uno strumento che consenta
di eseguire script piuttosto che usare linguaggi "proprietari"
* issue tracking/ticketing
* wiki base
* gestione milestone
e' verosimilmente indifferente soluzione hosted o SaaS, ma e'
preferibile un ambiente che abbia le soluzioni integrate.
non e' possibile, per particolarita' dei frontend, fare lo swap delle
macchine a caldo usando ad esempio gli strumenti che offre amazon.
al momento le alternative in scouting sono gitlab, codeship,
phabrikator+jenkins (e un altro paio che ora mi sfuggono).
al dunque: avete consigli o esperienze che potete/volete condividere?
grazie
sz
--
/"\ taste your favourite IT consultant
\ / gpg: http://www.guly.org/guly.asc
X
/ \
dell'infrastruttura di sviluppo di un cliente che lavora principalmente
su php.
ragionando sui vari aspetti, ho pensato sia utile confrontarsi con
come operate anche voi devops.
le necessita' sono relativamente semplici:
* versioning del codice, integrato con la gestione delle issue
* continuous integration, con preferenza su uno strumento che consenta
di eseguire script piuttosto che usare linguaggi "proprietari"
* issue tracking/ticketing
* wiki base
* gestione milestone
e' verosimilmente indifferente soluzione hosted o SaaS, ma e'
preferibile un ambiente che abbia le soluzioni integrate.
non e' possibile, per particolarita' dei frontend, fare lo swap delle
macchine a caldo usando ad esempio gli strumenti che offre amazon.
al momento le alternative in scouting sono gitlab, codeship,
phabrikator+jenkins (e un altro paio che ora mi sfuggono).
al dunque: avete consigli o esperienze che potete/volete condividere?
grazie
sz
--
/"\ taste your favourite IT consultant
\ / gpg: http://www.guly.org/guly.asc
X
/ \
Michele Finelli
Jan 14, 2015, 12:03:31 PM1/14/15
to devops...@googlegroups.com
2015-01-14 12:32 GMT+01:00 Sandro guly Zaccarini <gu...@luv.guly.org>:
> ciao all,
ciao giovane
> ragionando sui vari aspetti, ho pensato sia utile confrontarsi con
> come operate anche voi devops.
>
> le necessita' sono relativamente semplici:
> * versioning del codice, integrato con la gestione delle issue
> * continuous integration, con preferenza su uno strumento che consenta
> di eseguire script piuttosto che usare linguaggi "proprietari"
> * issue tracking/ticketing
> * wiki base
> * gestione milestone
>
> e' verosimilmente indifferente soluzione hosted o SaaS, ma e'
> preferibile un ambiente che abbia le soluzioni integrate.
> non e' possibile, per particolarita' dei frontend, fare lo swap delle
> macchine a caldo usando ad esempio gli strumenti che offre amazon.
>
non sono sicuro di avere capito questo passaggio: qual'è il limite di
avere ad esempio i servizi su AWS ?
> al momento le alternative in scouting sono gitlab, codeship,
> phabrikator+jenkins (e un altro paio che ora mi sfuggono).
>
> al dunque: avete consigli o esperienze che potete/volete condividere?
>
dunque, do per scontato che nel 2015 intendano usare git, come per
altro si deduce dal fatto che tu stia valutando gitlab
noi (in biodec) abbiamo usato redmine + SVN per anni ma da qualche
mese abbiamo migrato i progetti su git.biodec.com che è un server
gitlab
gitlab lo trovo fatto molto bene, l'unica cosa è che per la gestione
dei ticket secondo me redmine è meglio (rispetto all'issue tracker di
gitlab), ma magari sono io che cerco cose che a voi invece non
interessano: per cui i ticket rimangono su redmine, tengo
sincronizzati i repo con uno script, giusto perché se uno è su
redmine, è comodo vedere i file di cui parlano i ticket sotto
'repository'
jenkins è sempre esistito e integrarlo con gitlab è una banalità,
anche più semplice di avere un account 'amministrativo' autorizzato a
fare checkout, come facevamo con redmine
codeship non so cos'è, mentre phabrikator l'ho solo scorso, ho visto
che ha il componente per fare le code review, che trovo un'idea molto
bella, ma non l'ho mai provato seriamente
stai attento che mescolare la pianificazione, la schedulazione, la
rendicontazione, ecc. (cioè tutte le attività di project management)
dentro a strumenti pensati per fare sviluppo (quindi di base preposti
a gestire gli issue, le review, mostrare i repo, ecc.) è
fondamentalmente _male_ e garantirà solo bestemmie in quantità
non ti dico di usare M$ project, ovviamente, ma stai in occhio alla
distinzione fra gli ambiti, che è un attimo scoprire che si è messo in
piedi un sistema della madonna e trovarsi a litigare con qualcuno
perché non c'è un modo di rendicontare le ore _esattamente_ come
quella persona era abituata / aveva in mente / fa per tradizione
famigliare dai tempi dei Cesari
my 0.02$
> ciao all,
ciao giovane
> ragionando sui vari aspetti, ho pensato sia utile confrontarsi con
> come operate anche voi devops.
>
> le necessita' sono relativamente semplici:
> * versioning del codice, integrato con la gestione delle issue
> * continuous integration, con preferenza su uno strumento che consenta
> di eseguire script piuttosto che usare linguaggi "proprietari"
> * issue tracking/ticketing
> * wiki base
> * gestione milestone
>
> e' verosimilmente indifferente soluzione hosted o SaaS, ma e'
> preferibile un ambiente che abbia le soluzioni integrate.
> non e' possibile, per particolarita' dei frontend, fare lo swap delle
> macchine a caldo usando ad esempio gli strumenti che offre amazon.
>
avere ad esempio i servizi su AWS ?
> al momento le alternative in scouting sono gitlab, codeship,
> phabrikator+jenkins (e un altro paio che ora mi sfuggono).
>
> al dunque: avete consigli o esperienze che potete/volete condividere?
>
altro si deduce dal fatto che tu stia valutando gitlab
noi (in biodec) abbiamo usato redmine + SVN per anni ma da qualche
mese abbiamo migrato i progetti su git.biodec.com che è un server
gitlab
gitlab lo trovo fatto molto bene, l'unica cosa è che per la gestione
dei ticket secondo me redmine è meglio (rispetto all'issue tracker di
gitlab), ma magari sono io che cerco cose che a voi invece non
interessano: per cui i ticket rimangono su redmine, tengo
sincronizzati i repo con uno script, giusto perché se uno è su
redmine, è comodo vedere i file di cui parlano i ticket sotto
'repository'
jenkins è sempre esistito e integrarlo con gitlab è una banalità,
anche più semplice di avere un account 'amministrativo' autorizzato a
fare checkout, come facevamo con redmine
codeship non so cos'è, mentre phabrikator l'ho solo scorso, ho visto
che ha il componente per fare le code review, che trovo un'idea molto
bella, ma non l'ho mai provato seriamente
stai attento che mescolare la pianificazione, la schedulazione, la
rendicontazione, ecc. (cioè tutte le attività di project management)
dentro a strumenti pensati per fare sviluppo (quindi di base preposti
a gestire gli issue, le review, mostrare i repo, ecc.) è
fondamentalmente _male_ e garantirà solo bestemmie in quantità
non ti dico di usare M$ project, ovviamente, ma stai in occhio alla
distinzione fra gli ambiti, che è un attimo scoprire che si è messo in
piedi un sistema della madonna e trovarsi a litigare con qualcuno
perché non c'è un modo di rendicontare le ore _esattamente_ come
quella persona era abituata / aveva in mente / fa per tradizione
famigliare dai tempi dei Cesari
my 0.02$
Marco Vito Moscaritolo
Jan 14, 2015, 6:59:47 PM1/14/15
to devops...@googlegroups.com
Ciao,
negli ultimi due anni nelle aziende dove ho lavorato ho portato/spinto l'adozione di Gitlab per la parte di code versioning, e nessuno se ne è pentito :)
Per la parte di issue tracking sia redmine (self hosted) che jira (saas) e sono facilmente integrabili con Gitlab con qualche configurazione. L'issue management interno di gitlab IMHO lascia a desiderare (eg: numero di stati della issue prefissati, una sacco di label, ma non c'è la possibilità di avere attributi custom, ..) quindi consiglio redmine o (cosa che sto guardando da un pò ma non ho ancora usato in produzione) Taiga (https://taiga.io/) solo se fate pesantemente/in maniera stretta agile.
Per la parte di CI si apre un mondo.
* Gitlab CI ( https://about.gitlab.com/gitlab-ci/ )
* Jenkins ( http://jenkins-ci.org/ - http://jenkins-php.org/ )
* Phpci ( https://www.phptesting.org/ )
Per uso personale sto usando gitlab CI (per ciò che non è PHP) e PHPCI (a cui sto contribuendo) per la parte PHP (più che altro perché lo estendo/customizzo molto più facilmente).
Per lavoro -invece- jenkins per il fatto che ha una moltitudine di plugin già pronti (anche integrazione con gitlab) che è facilmente usabile anche da altri stack tecnologici (spesso PHP è una parte del processo, poi c'è java, python,node, ruby, ...) ed è "uno standard de facto".
Phabricator l'ho spinto molto all'inizio da me in azienda, ma purtroppo non ci siamo, ha delle cose IMHO fantastiche (vedi arcanist) ma per il resto è decisamente meno usabile di gitlab (a meno di usi veramente particolari, tipo CR pre commit, per la quale casomai consiglierei gerrit), o se vuoi qualcosa di veramente cross-tutto fatto pressapoco benino (gamification+wiki+issue tracking+code review+...).
Per il code versioning ti lascio un paio di progetti interessanti Gitblit (http://gitblit.com/) e Gogs (http://gogs.io/) da usare al posto di gitlab (fanno circa la stessa cosa su stack tecnologico diverso).
Un paio di consigli su cose che spesso ho visto sottovalutare:
- Non sottovalutare la migrazione del codice versionato, sopratutto se attualmente è sotto altri sistemi (bzr/hg/svn/...)
- Non sottovalutare la migrazione delle issue-progetti attualmente presenti (e dello storico delle stesse)
E un paio di consigli su cose spesso ignorate:
- USA GLI HOOK DI GIT (perdi tempo per configurare dei buoni hook, pre commit, post recive, update, ..)
- Sviluppa i tool di CLI che ti servono a velocizzare il lavoro dei dev, in base a cosa usi e al workflow che decidi di costruire in azienda.
Questo ultimo punto è imho FONDAMENTALE a rendere veramente produttivi gli sviluppatori e a fare le cose "per bene". Per capire di cosa parlo mi riferisco a cose TIPO integrazioni tra git e issue tracker:
(considera che per me sono degli scheletri di partenza, poi vanno customizzati di conseguenza), o integrazioni tra git / issue tracker / gitlab (per creare automaticamente MR & c.)
Spero di averti dato qualche cosa su cui lavorare :)
Sintetizzando:
* gitlab
* redmine/taiga/jira
* jenkins
Ciao
Marco
2015-01-14 12:32 GMT+01:00 Sandro guly Zaccarini <gu...@luv.guly.org>:
--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Devops Italia" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a devops-itali...@googlegroups.com.
Per ulteriori opzioni, visita https://groups.google.com/d/optout.
Giovanni Toraldo
Jan 15, 2015, 6:41:43 AM1/15/15
to devops...@googlegroups.com
Ciao,
2015-01-14 18:03 GMT+01:00 Michele Finelli <m...@pavis.biodec.com>:
> 2015-01-14 12:32 GMT+01:00 Sandro guly Zaccarini <gu...@luv.guly.org>:
> gitlab lo trovo fatto molto bene, l'unica cosa è che per la gestione
> dei ticket secondo me redmine è meglio (rispetto all'issue tracker di
> gitlab)
+1 per redmine, ti permette anche di definire a livello di issue tutti
i field custom che ti servono per tener impegnato il project manager,
e se i developer sono abbastanza disciplinati da segnare tutte le ore
perse dietro ad ogni ticket, anche specificando il tipo di attività, è
possibile associarci un costo e poter generare un report (o comunque
esportare un csv delle ore spese e farti i conti con l'abaco).
Il wiki integrato non è epico ma è comunque mediamente sopportabile,
idem per la gestione delle milestone.
-1 per redmine per la gestione dei repository git che non è supportata
nativamente, noi stiamo ancora usando un plugin mantenuto dalla
community che integra redmine con gitolite:
https://github.com/jbox-web/redmine_git_hosting, mi pare che siamo già
al terzo fork, e ogni volta che mi viene in mente di aggiornare ci
perdo 2 giorni per continuare a farlo andare come prima..
> jenkins è sempre esistito e integrarlo con gitlab è una banalità,
il suddetto plugin di redmine espone anche da gui la possibilità di
configurare degli hook, tipicamente per mandare una richiesta GET al
plugin git di jenkins per dirgli di rinfrescare il repository che c'è
ciccia nuova.
Per il resto Jenkins è tutto abbastanza immediato, noi abbiamo uno
script jenkins.sh nella root di ogni repository che fa cose, nel tuo
caso per php potresti fargli eseguire i vari linter (vedi tipo phpmd),
installare le dipendenze col workspace sempre pulito con composer (se
lo usate), test con phpunit, e magari alla fine se è andato tutto
liscio fare anche un git pull su una macchina di staging.
Ci sono una miriade di plugin per parsare lo standard output o i
report prodotti da questi task, così che poi tu abbia sulla gui i
famosi grafici e report navigabili.
p.s.: avevo rimosso dell'esistenza di questa mailing list, siamo
davvero così timidi? :D
--
Giovanni Toraldo
http://gionn.net
2015-01-14 18:03 GMT+01:00 Michele Finelli <m...@pavis.biodec.com>:
> 2015-01-14 12:32 GMT+01:00 Sandro guly Zaccarini <gu...@luv.guly.org>:
> gitlab lo trovo fatto molto bene, l'unica cosa è che per la gestione
> dei ticket secondo me redmine è meglio (rispetto all'issue tracker di
> gitlab)
i field custom che ti servono per tener impegnato il project manager,
e se i developer sono abbastanza disciplinati da segnare tutte le ore
perse dietro ad ogni ticket, anche specificando il tipo di attività, è
possibile associarci un costo e poter generare un report (o comunque
esportare un csv delle ore spese e farti i conti con l'abaco).
Il wiki integrato non è epico ma è comunque mediamente sopportabile,
idem per la gestione delle milestone.
-1 per redmine per la gestione dei repository git che non è supportata
nativamente, noi stiamo ancora usando un plugin mantenuto dalla
community che integra redmine con gitolite:
https://github.com/jbox-web/redmine_git_hosting, mi pare che siamo già
al terzo fork, e ogni volta che mi viene in mente di aggiornare ci
perdo 2 giorni per continuare a farlo andare come prima..
> jenkins è sempre esistito e integrarlo con gitlab è una banalità,
configurare degli hook, tipicamente per mandare una richiesta GET al
plugin git di jenkins per dirgli di rinfrescare il repository che c'è
ciccia nuova.
Per il resto Jenkins è tutto abbastanza immediato, noi abbiamo uno
script jenkins.sh nella root di ogni repository che fa cose, nel tuo
caso per php potresti fargli eseguire i vari linter (vedi tipo phpmd),
installare le dipendenze col workspace sempre pulito con composer (se
lo usate), test con phpunit, e magari alla fine se è andato tutto
liscio fare anche un git pull su una macchina di staging.
Ci sono una miriade di plugin per parsare lo standard output o i
report prodotti da questi task, così che poi tu abbia sulla gui i
famosi grafici e report navigabili.
p.s.: avevo rimosso dell'esistenza di questa mailing list, siamo
davvero così timidi? :D
--
Giovanni Toraldo
http://gionn.net
Roberto Franchini
Jan 15, 2015, 7:41:38 AM1/15/15
to devops...@googlegroups.com
2015-01-14 22:59 GMT+01:00 Giovanni Toraldo <m...@gionn.net>:
> Ciao,
>
> 2015-01-14 18:03 GMT+01:00 Michele Finelli <m...@pavis.biodec.com>:
>> 2015-01-14 12:32 GMT+01:00 Sandro guly Zaccarini <gu...@luv.guly.org>:
[cut]
> Ciao,
>
> 2015-01-14 18:03 GMT+01:00 Michele Finelli <m...@pavis.biodec.com>:
>> 2015-01-14 12:32 GMT+01:00 Sandro guly Zaccarini <gu...@luv.guly.org>:
>
> +1 per redmine, ti permette anche di definire a livello di issue tutti
> i field custom che ti servono per tener impegnato il project manager,
> e se i developer sono abbastanza disciplinati da segnare tutte le ore
> perse dietro ad ogni ticket, anche specificando il tipo di attività, è
> possibile associarci un costo e poter generare un report (o comunque
> esportare un csv delle ore spese e farti i conti con l'abaco).
Noi abbiamo proprio un campo custom che è il "codice progetto" che ha
> +1 per redmine, ti permette anche di definire a livello di issue tutti
> i field custom che ti servono per tener impegnato il project manager,
> e se i developer sono abbastanza disciplinati da segnare tutte le ore
> perse dietro ad ogni ticket, anche specificando il tipo di attività, è
> possibile associarci un costo e poter generare un report (o comunque
> esportare un csv delle ore spese e farti i conti con l'abaco).
corrispondenza 1a1 con i codici dell'applicativo dell'amministrazione
per la contabilità analitica.
Li carichiamo direttamente sul db di redmine, "da sotto".
In questo modo il management è contento ed il dev può tracciare in un
posto solo.
FRANK
--
Roberto Franchini
"L'impossibile è inevitabile"
jabber:ro.fra...@gmail.com skype:ro.franchini
Sandro guly Zaccarini
Jan 15, 2015, 1:10:39 PM1/15/15
to devops...@googlegroups.com
grazie a tutti delle risposte, leggo capisco e digerisco prima di
prendere una decisione.
On Wed, Jan 14, 2015 at 10:59:08PM +0100, Giovanni Toraldo wrote:
>
> p.s.: avevo rimosso dell'esistenza di questa mailing list, siamo
> davvero cos?? timidi? :D
credo abbiamo solo bisogno di essere stimolati :)
prendere una decisione.
On Wed, Jan 14, 2015 at 10:59:08PM +0100, Giovanni Toraldo wrote:
>
> p.s.: avevo rimosso dell'esistenza di questa mailing list, siamo
credo abbiamo solo bisogno di essere stimolati :)
Reply all
Reply to author
Forward
0 new messages