Aggiornamenti CMS in subversion - processo di revisione

4

Gestiamo una vasta gamma di siti client creati in Wordpress e Joomla e questi richiedono aggiornamenti regolari per il CMS e le estensioni principali. Manteniamo questi siti in sovversione e posizioniamo gli aggiornamenti in sovversione. Cerchiamo di utilizzare una singola revisione per questo.

Affrontiamo alcune difficoltà nel rendere questo processo efficiente, nel tempo vorremmo automatizzarlo, quindi possiamo offrire il processo a prezzo fisso

Il processo è attualmente come segue

  1. crea una copia dell'intera cartella

  2. stato di svn | grep '^!' | sed 's / ^! \ s * / svn cancella "/ g' | sed 's / $ /" / g' | sh

  3. svn update

  4. stato di svn | grep '^?' | sed 's / ^? \ s * / svn aggiungi "/ g' | sed 's / $ /" / g' | sh

  5. svn ci -m "Messaggio di conferma"

  6. svn remove -m "rimuovi temporaneamente" link

I passaggi 5-6 vengono solitamente ripetuti più volte.

Che cosa sto cercando aiuto con

  • stiamo usando subversion versione 1.6 e 1.7, perché non ci sono cartelle .svn in 1.7 nelle sottodirectory, mi chiedo se il processo è molto più semplice su 1.7?

  • abbiamo aggiunto il passaggio 3 perché riduce il numero di ripetizioni nei passaggi 5-6. Tuttavia questo è stato solo un tentativo ed errore e non riesco a capire perché questo sia

  • A quanto ho capito, il problema nel passaggio 5-6 è che quando un'estensione viene aggiornata, può eliminare un'intera cartella e quindi reinserire quella cartella con i file modificati. In subversion 1.6, questo rimuoverebbe la cartella .svn, che causa un errore 405 Access negato (la cartella viene aggiunta, ma già esiste in svn). Quello di cui ho bisogno è qualcosa che inserisca tutte le cartelle .svn nella mia copia di lavoro se la cartella esiste già in svn. C'è un modo per farlo?

  • Ogni altro miglioramento è stato apprezzato.

posta jdog 15.02.2013 - 03:33
fonte

4 risposte

1

Questo sembra un buon lavoro per esterni . Joomla e Wordpress sono entrambi ospitati in sovversione, cosa che rende gli esterni una scelta naturale. Fondamentalmente, invece di creare la tua copia di una cartella e provare a gestire le modifiche, devi dire che questa cartella dovrebbe essere estratta da una certa revisione da un determinato repository esterno.

    
risposta data 25.02.2013 - 18:08
fonte
0

Il problema che stai affrontando è risolto meglio usando strumenti diversi da SubVersion. Come una caratterizzazione grossolana (errata), SubVersion è stato sviluppato circa 10 anni fa, con l'obiettivo principale di essere migliore di CVS perché gestiva directory e file. Come prodotto di controllo della versione è molto capace, e uno che ho usato in passato su progetti seri. Tuttavia ....

Ciò di cui hai bisogno non è il controllo della versione, ma la gestione delle modifiche. Devi gestire il delta che viene creato da una modifica nel software, ma anche dove questa modifica deve essere applicata.

L'opzione gratuita, userei GIT, ma se la tua azienda ha i soldi, allora Accurev è una scelta tecnica migliore per questo tipo di problema.

Con git, dovresti creare un ramo che contiene solo il codice base per joomla, e quindi fare ciascuno dei tuoi siti clienti in rami separati. Quando sei pronto per inserire la versione corrente di joomla, invierai un comando git come 'git pull origin joomla' per inserire le modifiche dal ramo 'joomla' Mentre questo dovrebbe funzionare, la debolezza è che avresti bisogno di sapere che un l'aggiornamento era in joomla e devi ricordarti di inserire le modifiche.

Con Accurev, dovresti creare uno stream che contenga il codice joomla e taggare ogni versione. Quindi, nel tuo flusso di progetti heirachy, dovrai quindi collegare il link della tua directory joomla al livello di revisione con tag.

I vantaggi che Accurev ti offre è che puoi cambiare in modo esplicito il tuo link incrociato con qualsiasi versione taggata di joomla. Compreso il rollback di una versione. Hai visibilità di quale versione è attualmente in uso, e puoi facilmente trovare dove è attualmente utilizzata ogni versione di taged. (ad esempio, cerca i progetti che utilizzano ancora una versione vecchia e vulnerabile di joomla). Il rovescio della medaglia è il costo del prodotto, la curva di apprendimento per gli sviluppatori di adattarsi al nuovo modo di pensare (che alcuni non lo capiranno), e che gli sviluppatori inevitabilmente si lamenteranno della GUI di Accurev.

    
risposta data 25.02.2013 - 00:28
fonte
0

L'aggiornamento a SVN 1.7 aiuterà molto: rende SVN quasi sopportabile.

Se fossi rimasto bloccato a gestire qualcosa di simile in SVN e non volessi guardare a usare gli esterni di svn, prenderei una tattica molto diversa qui - non farei la versione del core CMS con il framework, ma piuttosto avere quello in un repository separato che potrebbe essere tirato via l'esportazione svn quando necessario. Gli aggiornamenti richiedono solo la distribuzione in una nuova cartella.

    
risposta data 22.03.2013 - 00:30
fonte
0

Hai dimenticato di menzionare alcune cose significative :

  • I siti (in core o | e in moduli) hanno modifiche specifiche del cliente o usano il codice vanilla?
  • I siti dei client sono anche copie di lavoro di repository SVN o di alberi non alterati?
  • Perché (almeno per WP, non posso richiamare lo stato di Joomla per oggi) non usi l'updater incorporato, che può aggiornare tutti i core, i moduli, i temi?

Ad ogni modo, il tuo processo attuale non ha senso (per me). Per aggiornare il codice esterno del tuo repository, servito anche da SCM, puoi avere molte meno operazioni

WP, nessuna modifica locale

  • Collega il tuo trunk (con gli esterni) all'ultima tag del core di WP nel repository WP
  • Collega tutto usato nell'installazione dei plugin Wordpress agli ultimi tag di questi plugin nel repository WP-plugins (combina tutte le definizioni esterne in una posizione comune per una migliore gestibilità)

Quando verrà visualizzata la nuova versione di qualsiasi elemento , hai solo:

  • Cambia esterno di questo qualsiasi elemento per collegarti al nuovo tag
  • Aggiorna albero (gli aggiornamenti appariranno automaticamente nel tuo WC)
  • Conferma le modifiche e distribuisci la nuova versione del sito alla destinazione

WP, modifiche locali

Per le modifiche locali esistenti, il flusso di lavoro verrà modificato solo in alcuni dettagli: il tuo codice sarà in trunk , codice del fornitore - in alcuni (RO) rami (anche externaliz'ed), che tu unisci nel bagagliaio dopo l'aggiornamento

Gli stessi trucchi possono essere applicati a Joomla, forse solo uno o due saranno necessari, quando (se) Joomla cambierà SCM-backend da Subversion

    
risposta data 21.05.2013 - 08:15
fonte

Leggi altre domande sui tag