Flusso di lavoro adatto a più persone con più livelli di abilità

Question

Flusso di lavoro adatto a più persone con più livelli di abilità

#1 da (2 voti)

1

Ho letto e provato vari flussi di lavoro con Wordpress / git. C'è un numero di opzioni disponibili e ho alcuni flussi di lavoro modellati approssimativamente, ma non importa quale io scelga c'è sempre qualcuno o qualcosa che perderà.

Adottatori del flusso di lavoro

Sviluppatori (competenti, abituati a git)
Designer (non usato per git, ma competente)
"Utenti CMS" (meno competenti)

Configurazione

Questa parte non è realmente soggetta a modifiche a meno che un flusso di lavoro non sia realmente, ne valga davvero la pena.

Il server di produzione viene estratto dal ramo prod / master
Il server di sviluppo interno recupera le ultime novità dal ramo di sviluppo
Sono disponibili test unitari che devono essere eseguiti prima del push locale al server
Quando lo sviluppo riceve una spinta e c'è un nuovo tag, i test automatici vengono eseguiti sul server Dev. Se passano, si fondono con la produzione

Opzione A

Tutti i file memorizzati in git
Schema del database e amp; contenuto memorizzato in git
uso dei file local-config.php per una facile implementazione locale
non consentire l'accesso al pannello di amministrazione per il sito live sul server di produzione e sviluppo

Pro

tutto il lavoro svolto localmente
facile da ridistribuire
tutto è controllato da git per la tracciabilità
versione funzionante conosciuta (non ci sono aggiornamenti automatici per far confondere le cose potenzialmente)

Contro

le modifiche minori ai post / le pagine devono essere eseguite tramite il controllo del codice ogni volta
i non-dev possono finire usando questo sistema più
unire un file SQL grezzo è problematico

Opzione B

Tutti i file memorizzati in git
Schema del database e amp; contenuto memorizzato in git
uso dei file local-config.php per una facile implementazione locale
non consentire l'accesso al pannello di amministrazione per il sito live solo sulla produzione

Pro

principalmente uguale all'opzione A, ma le modifiche ai post / contenuti possono ora essere fatte tramite il server Dev
più facile da comprendere per le persone meno tecniche
passa a Dev site db archiviato automaticamente dal server ogni tanto

Contro

perdere la tracciabilità con i commit in quanto sarà solo un "server" utente che ha commesso una modifica del contenuto della pagina
aprire il potenziale per far lavorare le persone sul server Dev e saltare il locale
pain da gestire

Opzione C

solo modelli / plugin personalizzati archiviati in git
db eseguito il backup con altro metodo (probabilmente manualmente)
post, pagine, installazioni di plugin, aggiornamenti possono essere fatti dal vivo sul sito prod (yuck)

Pro

più user-friendly

Contro

least Dev friendly.
non veloce e facile da ridistribuire
non ho idea se l'aggiornamento al core interrompa un test
non ho idea se un aggiornamento a un plug-in interrompe roba
utenti che modificano le pagine al volo dal vivo

C'è un buon mezzo felice o un modo migliore di lavorare che mi manca del tutto o è un lavoro "succhia e vedi" dove dobbiamo implementarlo, trovare i problemi che la gente sta avendo e sistemare.

workflows

posta ScottMcGready 04.09.2015 - 11:31

fonte

1 risposta

Leggi altre domande sui tag workflows

Come dovrei strutturare queste classi Python? Disabilitare l'immissione dei dati, in base a un insieme di regole [chiuso]

score 2 · Answer 1

Hai tre tipi di dati:

Codice sorgente,
Configurazione,
Contenuto.

I primi due appartengono a un controllo di versione. Questo è ciò di cui hai bisogno per ricostruire l'applicazione web, ad esempio dopo averlo portato a uno stato di funzionamento dopo, ad esempio, il tuo server si blocca. Questo è anche tutto ciò che serve per distribuire l'applicazione su un server diverso in un ambiente diverso o per eseguirlo su un computer dello sviluppatore. Questi dati vengono creati da sviluppatori, artisti grafici, amministratori di sistema e amministratori di database: persone con competenze tecniche nell'IT.

Il contenuto, d'altra parte, appartiene a un database. Potrebbe esserci un controllo di versione incorporato in l'applicazione o il database , o l'applicazione può utilizzare un sistema di controllo delle versioni più comune come Git per tenere traccia delle modifiche al contenuto. Il contenuto è creato dagli utenti finali, persone a cui non è richiesto che abbiano competenze tecniche in ambito IT.

Lo spazio di archiviazione e la versione del contenuto dovrebbero essere trasparenti per gli utenti finali. Non ci si aspetta che facciano svn commit , e ancora meno per capire la differenza tra git commit e git push . In pratica, tale trasparenza è difficile da ottenere: Google Doc ha capito correttamente la versione aggressiva dei più piccoli cambiamenti; SharePoint si è sbagliato tagliando gli utenti finali con i dettagli: numeri di versione, blocchi esclusivi, ecc.

Un'altra differenza è il ciclo di vita del codice sorgente e le modifiche alla configurazione da un lato e le modifiche del contenuto dall'altro. È previsto che il contenuto venga modificato rapidamente. Per cambiare una pagina tramite CMS, era sufficiente un clic sul pulsante "Salva", la modifica era immediatamente in produzione. D'altro canto, le modifiche al codice sorgente e alla configurazione dovevano passare attraverso il controllo delle modifiche, le revisioni del codice, la compilazione, il test e la distribuzione. In passato potevano trascorrere fino a sei mesi tra il momento in cui veniva suggerito il cambiamento e quando alla fine appariva nella produzione. Con l'avvento di Agile e DevOps, il ciclo di vita è molto più breve, a volte solo pochi minuti; tuttavia, di solito, non si inviano modifiche di contenuto a Q & A o si ridistribuiscono tutti i server dopo che l'utente ha corretto un refuso (ma se l'errore di battitura è stato risolto da uno sviluppatore, la storia è molto diversa).

Ciò significa che non è necessario disporre di un singolo flusso di lavoro per tutti. È come scegliere tra chiedere sia ai tuoi sviluppatori che ai tuoi utenti di usare vi o emacs per scrivere sia codice che documenti, o usare Microsoft Word per entrambi i gruppi: il fatto che entrambi i gruppi digitino del testo per fare il loro lavoro è irrilevante ; esigenze diverse richiedono strumenti diversi. Quindi mantieni il flusso di lavoro ordinario per sviluppatori e progettisti e lascia che il CMS (o il database) gestisca il controllo delle versioni dei contenuti.