Come si memorizza la pagina di conservazione / manutenzione di un sito Web in Git?

Naviga le tue risposte
1

Sto cercando di mettere in ordine i repository Git per i pochi siti che gestisco. Per ciascun sito, di solito creo una filiale separata nel repository che contiene una "pagina di manutenzione" o una "pagina di attesa", che effettuo il checkout se devo ritirare il sito per qualsiasi motivo. Questo ramo è solitamente chiamato maintenance_page . Lo sviluppo normale viene eseguito rispetto a master e il sito attivo viene anche distribuito da lì.

Sebbene il codice del sito nel ramo maintenance_page abbia lo stesso stile del sito principale (live) in master , in realtà non condivide alcuna cronologia con il ramo principale - pensa di esso come una versione mini del sito live, ma con il proprio codebase sostanzialmente non correlato. Di tanto in tanto, le modifiche apportate allo stile, alle immagini, ecc. In master sarebbero utili nel ramo maintenance_page e in queste situazioni, di solito git cherry-pick da master a maintenance_page .

Ho lavorato con questo setup per un po 'di tempo, tuttavia, sono consapevole che l'idea di avere i due rami ( master e maintenance_page ) coesistono nello stesso repository, ma non hanno nulla veramente in comune tra loro non è in realtà il "modo Git di fare le cose". Ho pensato di memorizzare il ramo maintenance_page nel proprio repository (poiché ha molto poco in comune con il ramo master), tuttavia questo sembra complicare l'amministrazione dei repository e anche la semplicità di essere in grado di semplicemente checkout il ramo maintenance_page , quando ho bisogno di abbattere elegantemente il sito.

Ho letto bene (vedi qui) (e qui) per cercare di scoprire come altre persone gestiscono questo genere di cose, ma io Non riesco a trovare stranamente alcun suggerimento su come raggiungere gli altri.

Qualcuno ha qualche suggerimento su modi migliori per raggiungere questo obiettivo?

    
posta JoeNyland 19.07.2014 - 16:47
fonte

2 risposte

0

Come già detto MainMa, la pagina di manutenzione è una funzionalità del sito. Sono non due siti . La pagina di manutenzione è una pagina speciale del sito e dovrebbe quindi accompagnarla nello stesso albero .

Le filiali sono grandi per la storia parallela, ma non sono adatte per qualsiasi altra cosa. Per diverse varianti, l'unico modo pratico è riunirle nell'albero e utilizzare una sorta di inclusione condizionale. Lavoro sul progetto (non sul web, ma il principio è lo stesso) che offre versioni leggermente diverse per più di 10 clienti su 5 diverse piattaforme. Con la compilazione condizionale questo funziona bene, i rami sarebbero devoluti alla follia molto tempo fa. In caso di sito web, l'inclusione condizionale è controllata dalla configurazione del server.

Si noti che non esiste un modo di git di fare le cose. Solo "best practice per il controllo delle versioni" che si applicano a tutti i sistemi di controllo delle versioni, sia che si usi git, subversion o directory, tarball e patch (come Linus ha fatto per 10 anni prima che scrivesse git). E questi dicono che i rami sono per la storia parallela, non varianti parallele. Git rende i rami più facili da usare, ma ciò non significa che diventerebbero improvvisamente appropriati per cose che prima non erano.

    
risposta data 28.07.2014 - 10:49
fonte
3

Poiché la pagina di manutenzione è una funzionalità dell'applicazione Web, non vi è alcun motivo per inserirla in un ramo o un repository separato. Invece, avere una directory dedicata, o forse anche solo un file alla radice. Ciò renderà possibile:

  • Condividi tutti i file statici come le immagini, CSS o JavaScript,

  • Sfrutta il codice comune invece di duplicarlo con il rischio che la pagina di manutenzione non venga aggiornata correttamente quando cambia la stessa applicazione web.

Probabilmente non sarai in grado di condividere tutto, specialmente dal momento che, presumo, la tua app web utilizza template mentre la pagina di manutenzione è statica, ma è ancora molto meno fastidiosa di mantenere un branch o un repository diverso.

È quindi possibile passare dall'applicazione Web alla pagina di manutenzione modificando la configurazione del server (come un reindirizzamento automatico di qualsiasi richiesta GET diversa da favicon.ico e robots.txt alla pagina di manutenzione e un HTTP 500 per Richieste POST).

Nota che quando la tua applicazione web crescerà, starai alla ricerca di modi più user-friendly per mettere comunque la tua app web in manutenzione. Questo include:

  • Avere un flag di sola lettura, simile alla modalità di sola lettura di Stack Exchange che impedisce a chiunque di accedere e pubblicare, commentare e aggiornare.

    Una tecnica simile è usata anche su altri grandi siti web; ad esempio, su B & H , uno dei più grandi siti di e-commerce per i fotografi, a volte non sei in grado di acquistare prodotti, mentre tu puoi ancora sfogliare il catalogo.

  • Avere un'infrastruttura solida che rende possibile portare un server offline, fare manutenzione su di esso, portarlo online e fare la stessa cosa con un altro server.

    Questo approccio è più avanzato, poiché non disturba gli utenti finali: per loro, il sito web è sempre online e tutte le operazioni che stavano facendo quando sono passati da un server a un altro sono conservate.

risposta data 27.07.2014 - 19:56
fonte

Leggi altre domande sui tag

Come prendere il codebase considerevole, senza avere accesso a chi ha implementato? [duplicare] Molte variabili di istanza all'interno della mia classe suggeriscono Design imperfetto?