Ero qui che cogitavo e mi son domandato....
Ma visto che è molto più semplice per me lavorare in locale (e ti credo, penserete tutti)... sarebbe possibile installare una drupal in locale, il suo specchio in rete, e gestire modifiche ai contenuti e agli aggiornamenti da locale.
Così, solo facendo la domanda mi vengono in mente 6667 problemi possibili ma chissà, magari qualcuno ci ha provato, o mi può indicare un po' di documentazione? Non saprei nemmeno come impostare la ricerca su google :-)
Ciao a tutti e buon drupaling
Simone
è un'idea del tutto fondata, lo stesso esempio potrebbe valere per due installazioni diverse.. una di produzione e una di testing.
il modulo Feature in parte fà già questo, infatti ti permette creare dei settaggi su Drupal, selezionarli, ed esportarli... ma questo non vale per i contenuti (almeno che io sappia...)
in alternativa in generali hai due cose che ti tocca esportare
1) i file
2) il database
Per i file si potrebbe usare un sistema di Repository come Git o svn, mentre per il db per quanto la mia esperienza mi permette di comprendere l'unico metodo è comunque l'importazione tramite sql.
Secondo me il problema principale che si potrebbe incontrare è la eterogeneità dei componenti di Drupal, nel senso che spesso le modifiche possono essere circoscritte a qualche tabella del DB, altre volte invece sono dei moduli, altre volte ancora possono essere entrambi e così via...
Slice2Theme Servizio per la conversione di Design in markup HTML e/o temi.
WeBrain Solution | Pillsofbits Of Bits
E proprio come descrive kiuz che tanti qui lavorano (me compreso). Features sistema parzialmente il seguente problema - ma non per il contenuto: mentre tu stai modificando la tua copia del db, anche gli utenti lo stanno modificando quello in rete. Come 'amalgamare' entrambi le modifiche? Soprattutto se entrambi hanno creato un diverso node/123. Domanda da $1,000,000...
Più imparo, più dubito.
Interessante, ai 6667 problemi che avevo pensato lavorando da solo, se ne aggiungono il doppio per il lavoro in gruppo.
Effettivamente basta un commento a un articolo che già i contenuti cambiano.
eh si, Jhon è sempre più conciso di me nel spiegare le cose, si vede che ha come lingua madre l'inglese... :D
Comunque penso che un primo passo verso la risoluzione del problema può essere nel tuo caso iniziare a pensare di separare le cose che pensi possano essere realizzate prima in locale e poi trasferite, e dall'altra parte le cose che sai che dipendono con certezza dall'installazione on-line.
Es.
-> Contenuti sono dipendenti fortemente dall'installazione in produzione
-> Il tema se non implica particolari impostazioni nel db puoi benissimo prepararlo in locale e trasferirlo...
Slice2Theme Servizio per la conversione di Design in markup HTML e/o temi.
WeBrain Solution | Pillsofbits Of Bits
io sto lavorando su questo:
http://drupal.org/node/670460
ho dovuto interrompere a metà per impegni incombenti, ma vorrei portare a termine una prova "seria" entro qualche settimana.
Posterò qui i risultati...
Certified to Rock
Grazie bohz, in effetti è più o meno quello che sto già usando. Rsync risolve il problema di sincronia dei files (se stai molto attento), ma neanche Drush risolve il problema del doppio node/123.
E soprattutto non tutti i hosting offrono rsync. Quelli che scelgo io si, ma quelli populare (leggi poco costoso) quasi mai...
Ho 'eliminato' il problema del file settings.php, semplicemente testando il domino per capire quale $db_url usare. Questo mi permette anche di tenere questo file sotto version control per tutti i siti (locale, staging, produzione):
if ($_SERVER['HTTP_HOST'] == 'www.staging.it') {$db_url = 'mysql://user1:pword1@sql_dominio1/nome_db1';
}
else if ($_SERVER['HTTP_HOST'] == 'www.produzione.it') {
$db_url = 'mysql://user2:pword2@sql_dominio2/nome_db2';
}
else { // locale
$db_url = 'mysql://user3:pword3@sql_dominio3/nome_db3';
}
Per la domanda di $1,000,000 (contanti, grazie), ci sono tre soluzioni - che io ritengo validi (per discete quantità di valido):
1. Tenere liste separati di tabelle 'sistema' e 'contenuto' spedendo solo 'sistema' al staging/produzione - ma questo ha il fallo che devi seguire la lista ogni volta che aggiungi/togli un modulo che usa tabelle proprie, ed anche che sei costretto a creare contenuto sul sito produzione
2. Usare una tecnica di 'slicing' dei identificatori di riga tabella (esempio dispari per locale, pari per produzione) - ma non tutte le tabelle usano un identificatore - comunque in questo modo non possono essere due node/123
3. Qualche meccanismo di registrazione delle modifiche, con playback su staging/produzione. Questo mi sembra lavora ad un livello di astrazione sufficiente alto per funzionare - ma non esiste! I più vicini sono Features, Exportables, Services... Ma nessuno di questi sembra di essere arrivati alla massa critica (critical mass) - hanno tutti il diffetto che richiedono la 'collaborazione' di tutti i moduli che modificano il db - un bel diffetto.
Un pò come le regole della vita:
E' sicuramente un argomento che riceve molto spazio ai varie DrupalCon:
http://dc2009.drupalcon.org/session/staging-and-deployment-panel-discussion
http://greenash.net.au/posts/thoughts/deployment-and-migration-hot-at-dr... - bellissimo riassunto, se non leggi altro, leggi questo
http://paris2009.drupalcon.org/session/staging-drupal-managing-your-proj...
e anche drupalcamp:
http://crema2009.drupalcamp.it/talk/deploy-di-applicazioni-drupal - una panoramica da mavimo, che di deployment ha tutte le ciccatrice di uno che sa bene il problema
Ma non sono ancora convinto...
Più imparo, più dubito.
l'idea di drush rsync ma soprattutto di drush sql-sync è decisamente molto interessante.
La questione è.. non serve granchè se la si usa solo per trasferire i dati da server a locale e viceversa.
Potrebbe invece avere invece un interessante utilizzo utilizzandolo per sincronizzare i db e creare una sorta di mirroring "semplificato" dove potoer switchare in caso di necessità. insomma 2 DB simcronizzati ... da utilizzare per lo stesso sito.
Insomma un cluster simulato e semplificato: 2 db sincronizzati e il file settings.php come gateway.
a me piace! soprattutto per le potenzialità, per i bassissimi costi di gestione e risolverebbe tantisismi problemi. Sarebbe un'idea di DB Disaster Recovery.. semplice.
Oppure.. altra domanda che adesso mi sorge. ma MYSQL ha strumenti per fare una cosa di questo genere.. cioè sincronizzare due database?
http://www.sanisapori.eu
Interessante .... perchè non provare a testare qualcosa di Custom.
Slice2Theme Servizio per la conversione di Design in markup HTML e/o temi.
WeBrain Solution | Pillsofbits Of Bits
Hmm, non riesco seguirti...
??? Perchè conosci un modo migliore? O non lo trasferisci mai?
Ma quante volte bisogna eseguire il commando per essere "sincronizzato"? E sempre una soluzione backup, non sincronizzato.
A tonnellate. Solo che per le maggioranza sono difficile (se non impossibile) da usare su shared hosting. Quello forse meno ovvio è mysqldump stesso. Leggi qui: http://linuxcommand.org/man_pages/mysqldump1.html, verso la fine, sotto "mysqldump is also very useful for populating databases by copying data from one MySQL server to another"...
Non osano chiamarlo un sincronizzazione, ma sicuramente sarà veloce quanto drush, credo...
Altro (forse) utile informazione: http://www.mysqlperformanceblog.com/category/replication/, http://www.mysqlperformanceblog.com/category/tools/, se hai il tempo ovvio...
Più imparo, più dubito.
jhl.verona io non trasferisco mai i siti in locale?!.. Non mi serve.
Preproduzione e Produzione sono tutti su server remoti. Non avrei alcuna utilità a trasferirmi la preproduzionei in locale, ne avrei solo tanto lavoro in+.
D'altra parte se io per esempio andassi in ENI e mi mettessi a trasferire in locale i loro siti per lavorarci o mi mettessi a creare una preproduzione sul mio computer di casa ...mi brucerebbero.
Se lavori sul web su progetti professionali, non capita mai o quasi che i siti vengano trasferiti sui computer degli utilizzatori.
io non lo faccio, non lo concedo, per il semplice fatto che i siti web con cui lavoro danno da mangiare ad alcune persone.
Non a caso io ho il problema di gestire i grossi database e di studiarmi soluzione in tal senso che siano economiche e semplificate.
Per MySQL ho notato la questione del replication, ma devo approfondire.
l'idea di drush sql-sync è molto utile per esempio per salvarsi dal disaster in quel caso particolare in cui fai aggiornamenti in preproduzione e poi facendo il deploy in produzione si incasina il database e non funziona + il sito. A quel punto fai puntare al DB sincronizzato che non ha subito le modifiche, il sito torna a produrre e tu cerchi di capire cosa si è incartato facendo gli upgrade, perdendo il minimo necessario di ritorni economici.
http://www.sanisapori.eu
Bè .. veramente ( secondo me ) e inevitabile lavorare in locale per un prodotto sano.
Io non li transferisco ; Ma quando arrivo a una struttura conveniente in locale, lo ricostruisco in un paio di ore(?) online.
----------------------------------------
bI’Iqchugh’ yIvang !
Se sei triste, agisci!
Proverbio Klingon
jscm, non per la prima volta dobbiamo essere in accordo... di essere in disaccordo
Sviluppo, debugging e testing? D'accordo per preproduzione (se in realtà è staging) e produzione. Quando inserisci nuovo funzionalità dove lo sviluppi o fai il testing? Su un sito accessibile agli utenti finale? E con quale dati? Quello del sito staging/produzione? Invece di locale (termine che uso io per indicare la "non accessibilità" dai utenti) tu stai usando il termine preproduzione?
Ah, hai clienti che vogliono fare vedere informazione su internet ma non ti permettono di copiarlo per lavorare sopra? Hmm. Non esaggerare - non ti stavo chiedendo di fare preproduzione (staging?) sul tuo PC. Sviluppo e testing però si, o su PC dei tuoi sviluppatori.
Non so perchè mi da l'impressione che sei solo tu che lavora su progetti professionale...O progetti che dà da mangare. Non è la prima volta che noto questo sensazione... Perchè poi questi siti dovrebberanno essere trasferiti su computer degli utilizzatori? Sviluppano e testano loro per te?
Se lavori su progetti professionale, gestendo grossi database, sarebbe una mossa astuto. Ma va al di fuori dei discorsi di un forum Drupal - e anche della mia esperienza. Su progetti anche piccoli, ma con clienti con la propria reparto IT, ho sempre chiesto l'aiuto di un buon DBA, o meglio, dato che lui/lei era risponsabile per tutti i db del cliente, lui/lei obbligava me a collaborare. E ci sono stati clienti dove ho dovuto lavorare in situ, per accedere al DB. Ma per la maggioranza dei casi, si poteva usare VPN, o altro.
Forse questi possono aiutare: http://www.mysqlitalia.it/, http://www.mysql.it/ (che nostalgia, c'è ancora il logo Sun).
No, fai puntare al DB di riserva, backupato dal originale n secondi/minuti fa. Un mirror, casomai. E se questo succede, dove e come fai questa ricerca per capire cosa si è incartato? Sul sito preproduzione? Su un altro sito ancora? Su un sito 'sorella' del sito produzione (cioè stessa macchina, stessa connesione db, ma dominio/db diverso)?
Forse stiamo solo usando termine diverso per la stessa cosa - o forse abbiamo visioni diverso del problema. Comunque quello che intendo io è spiegato molto bene qui:
http://developmentseed.org/blog/2009/jul/09/development-staging-producti...
http://paris2009.drupalcon.org/session/staging-drupal-managing-your-proj...
http://drupal.org/node/181128
Più imparo, più dubito.
Trasferire in locale può avere diversi significati, quello + comune è trasferirsi i file sul proprio computer personale (qualunque esso sia).
Nella mia esperienza la preproduzione è caratterizzata da diverse realtà ma essenzialmente si tratta di apposite macchine dedicate che supportano diverse architetture verticali spesso definite "ambienti" (così sono stati sempre finiti fin da quando installavo gli ambienti di preproduzione per il Billing&Rating di Vodafone), ma possono essere chiamati in un casino di modi diversi. La mia preproduzione è caratterizzata da un server con 37 siti web adibiti allo sviluppo, al debugging e test.
Il test può essere fatto in modi diversi, uno di questi è l'utilizzo di apposite piattaforme di test (ma non sono necessarie nel caso dei siti di publishing che uso io)... ecc ecc ecc ecc ecc ecc ecc ecc ecc ecc ecc ecc ecc ecc ecc ecc ecc ecc ecc ecc ecc ...[ se no stiamo qui fino a domani ]
Attualmente io mi occupo di Marketing e Sviluppo del Business, non faccio lo sviluppatore, per tantissimi anni in passato ho fatto il Sistemista Unix in H3G, Vodafone, Fastweb. Il mio lavoro di oggi è più concentrato sul mantenere le relazioni con i centri media e le concessionarie e sviluppare strategie di crescita, ma questo non vuol dire che non si debba avere l'apertura mentale per operare su più cose. Siamo in pochi quindi bisogna essere versatili dove si può, secondo il principio delle learning organization.
Io ho avviato tempo fa, questi nuovi progetti di publishing ed ero da solo a curarli, oggi ci lavoriamo in 2, essendo stato io ad averli avviati sono io che pongo domande e cerco soluzioni e accorgimenti vari, contribuisco nel tirare fuori nuove idee e cose da fare e implementare: faccio la ma parte per portare avanti le cose affinchè crescano come si deve. Poi ci sono i collaboratori esterni, che si occupano dei contenuti in generale e della ricerca delle fonti di informazione valide. Gli interessi sono molteplici dai normali canali di publishing alle applicazioni su facebook e se riusciamo magari anche quelle mobile. Stiamo tentando di estendere il publishing fuori dall'italia per vedere come va ed abbiamo fatto un sito di publishing in inglese.
Questo è il quadro generale!
In questa attuale condizione strutturata è chiaro che cerchiamo idee e soluzioni che siano di per se il più possibile semplici e implementabili senza richiedere mesi di pianificazione e lavorazione.
E' chiaro che questo in cui scriviamo è un blog su drupal però è pure vero che drupal si appoggia su macchine apposite e necessita di DBMS e quindi fare una domanda relativa agli strumenti necessari a drupal per funzionare, a chi lavora con drupal si occupa di progetti importanti porta ad avere una risposta sistematica in merito a problematiche non specificatamente rivolta a drupal.. e questo è un buon input o suggerimento validissimo per approfondimenti e per andare avanti.
Io ho lavorato per coloro che hanno acquisito Splinder e lo hanno rinnovato. Splinder è tutto realizzato con Drupal ed allo sviluppatore se gli chiedevo come gestire qualcosa attinente a progetti fatti con drupal, ma che si riferiva a ciò che è necessario a drupal per funzionare bene, mi rispondeva senza difficoltà (mentre eravamo a pranzo).
Dal mio punto di vista la questione è porre problemi e cercare soluzioni assieme. Infondo siamo qui apposta e tutte le domande che facciamo sono sempre rivolte a creare ottimi progetti usando drupal.
Questo è il mio modo di operare. Pongo domande e dalle risposte ne ottengo input da approfondire e quindi una valiada indicazione su come ricercare la giusta soluzione ad un problema.
http://www.sanisapori.eu