SVN server, per Florim, è installato su server di test, anche se la sua configurazione può avvenire in qualsiasi ambiente.

Transcript

1 Siti FLORIM SVN Subversion Il sistema di versioning viene illustrato nell immagine seguente: Sistema locale dello sviluppatore, si parla di working copy ( copia dei file dal server in produzione) SVN server, per Florim, è installato su server di test, anche se la sua configurazione può avvenire in qualsiasi ambiente. Temi presenti su SVN Server: Florimweb Presskit Hub Comandi generali su SVN Server: Update: aggiornamenti degli ultimi file all interno del SVN che sono stati modificati; (Svn up)

2 Commit: invio al server dei file modificati in locale. (Svn commit m nuovo header ); Ø indica l history dei file con un comment in fase di commit. Info: visualizza il percorso svn; visualizza dove sta puntando la tua working copy. (Svn info) Status: Visualizza file modificati (Svn status) Ø In produzione e su test deve dare sempre insieme vuoto, in quanto le modifiche devono essere fatte unicamente in locale. Add: Aggiungere un file (Svn add header.css) Ø Attività da effettuare prima del commit in locale, deve fare l add nel versioning central. Checkout: attività di recupero la prima volta quando si crea un nuovo sito (un checkout per ogni Wordpress installato); Attributi principali E visto come un repository di file di testo per le versioni del source code e ha tre attributi principali: Il versioning Ø Procedura per congelare una versione per permetterci il rollback futuro: Creazione di tags (etichette) e branches (rami) paralleli In parallelo al main development trunk possono coesistere più branches su cui è possibile fare il checkout della version. Ad ogni commit c è una revision con un contatore che indica il salvataggio di quella determinata revision. Possono esistere due linee parallele di sviluppi contemporanei. Comandi per il versioning: Copy: creazione di un branch (ramo del trunk) o tag;

3 (svn copy /florimwebsite/siti/trunk[linea di sviluppo] [destionazione] -m creazione versione alpha-1 ) Switch: Cambia a working copy; cancella e recupera i file della versione cambiando da una linea parallela all altra (utile nel server di produzione) (svn switch Lavoro in parallelo Ø Nel caso in cui più persone lavorano allo stesso file è possibile effettuare il merge di più moduli; quindi se si lavora a moduli differenti anche se sullo stesso file non crea nessun conflitto di accesso. Al contrario se si dovesse lavorare allo stesso modulo è possibile trovarsi in stati inconsistenti del modulo stesso con dirty read o dirty write di versioni non aggiornate. History di cosa accade ai file Ø Chi? Ø Quando? Ø Quali modifiche sono state effettuate? E buona norma per SVN: Da produzione o test devono venir effettuati solo update o eventualmente switch; Non devono esserci modifiche pending su test o produzione; Non fare commit da produzione o test; Non devono avvenire i rollback in produzione; Non si devono effettuare modifiche direttamente sul DataBase in produzione ma utilizzando la procedura di deploy (che analizzeremo in seguito) dall hub per i contenuti. Per l allineamento degli ambienti Manuale per ogni sito: Ø Connessione in ssh al server; (ssh srvtest) Ø Cd directory del tema; Ø Caricare gli update da SVN Server. Automatico: (Svn up) Ø Dal proprio pc lanciare lo script che si connette in ssh a tutti i server di produzione e lancia gli update da tutti i server; (./svnupdate [t] or [p]) t: test p: produzione Configurazione siti Di seguito l immagine che raffigura l architettura dei siti Florim:

4 Nel tema, pagina HTML con SRC= path dell immagine SRVMEDIA Server Apache per le immagini delle collezioni e dei progetti. Vengono richieste tramite opportuni path dal browser. All interno dell Hub prod vengono gestite tutte le logiche di inoltro (contatti e fattura), anche se i contenuti sono all interno di ogni sito). Nel dettaglio: $HUB_DB_CONNECTION_TYPE = local Hub_config $HUB_DB_CONNECTION_TYPE = remote

5 All interno dell Hub prod, è presente un wordpress e un database unico con i contenuti di tutti i siti; durante la fase di deploy sui siti in produzione, viene fatta la pubblicazione di una porzione per ogni Wordpress all interno del server. Ogni Wordpress infatti si interfaccia solo con il suo database molto più ridotto per favorire l ottimizzazione delle risorse; ad esempio nel DB c è scritto quanti e quali colori, poi le anteprime vengono richiamate tramite HTML con IMG SRC= SRVMEDIA. Al contrario il server di test è connesso direttamente al Database dell Hub in quanto non è richiesta una particolare ottimizzazione del tempo di latenza e inoltre, in questo modo, è possibile testare in diretta i cambiamenti. All interno di hub_config (presente in hub common per sapere quali DB interrogano): $ENV = florim [si committa sempre con florim] $HUB_DB_CONNECTION_TYPE = remote o local [local per far puntare i wordpress ai db locali, mentre remote per far puntare i wordpress direttamente all HUB DB PROD] PHP package hub All interno del Florimhub sono presenti due package php: hub: collezioni e progetti, con tutte le funzionalità di scrittura; hub-common: file python comune (in caso di modifiche saranno da effettuare in questo package). All interno di hub-common, esiste il file db_access che contiene le query di sola lettura anche per il sito di front-end in modo da evitare SQL INJECTION. All interno del Florimweb e in altri temi sono presenti due package php: hub: non è un external, ma una semplice organizzazione in cartelle; <<externals>> hub-common:

6 all interno del tema FlorimWeb si ha la necessità di alcuni metodi presenti nell hub e quindi si ri-utilizza del codice comune presente nell hub. Si fa uso degli <<externals>> in SVN, che inglobano alcuni file che sono nell hub. Flusso delle dynamic page All interno dell HTML appare solo lo scheletro della pagina, poi, utilizzando datatable si richiama la componentistica javascript che effettua le chiamate AJAX per popolare la tabella, le quali richiamano le query da db_access che restituisce un JSON al Javascript che renderizza la datatable in HTML. Nota: struttura dati JSON 1:1 con Javascript Regole Apache File.htaccess: Ø File che regola gli accessi dall esterno a determinati file.php; Ø Regola eventuali esclusioni di contenuti di wordpress (nella root o in una cartella specifica); Ø Mettendolo all interno di wp_admin, quelle regole valgono per quella determinata cartella. Varnish Di seguito l architettura della cache di Varnish: E installato su ciascun server, tranne per l hub in cui non è presente, e anche se non viene utilizzata questa funzionalità le richieste passano comunque da Varnish per lo smistaggio. All interno del file di configurazione, è possibile eliminare parti di domini (es. il login non utilizza MAI la cache in quanto deve sempre fare collegamenti con il database).

7 File di configurazione.vcl: #ignore domini If(request.http.host- test.cerim.it/login ) [ ] Return(pass) le inoltra ad Apache senza passare dalla cache Caratteristica di Varnish: Varnish salva su variabile l IP del chiamante, in quanto nell.htaccess di Apache, si va a leggere l IP in quella variabile invece che nella sorgente standard in quanto sarebbe sempre perché l IP del chiamante è sempre Varnish. La cache di Varnish si trova dinnanzi all Apache in modo da evitare accessi di I/O e accessi al file system. Per le chiamate che devono essere servite da Apache, transitano comunque da Varnish per smistare le richieste. Configurazione /etc/default/varnish

8 [file di configurazione per dimensionare la RAM della cache in Varnish] /etc/varnish/default.vcl Riavviare Service varnish restart Vuotare cache Varnishadm ban.url./slim [vuota le cache solo per quegli URL in cui appare la stringa /SLIM] Procedure HUB function (L 80% delle funzionalità dell HUB sono gestite nel seguente modo) Browser Return JSON Il browser effettua delle GET() alla page-<funzione>.php (nomi delle funzioni per progetti e collezioni) la quale ritorna la parte statica della pagina, return html(); la parte dinamica della pagina avviene dopo un qualsiasi click() tramite chiamate AJAX al layer page-ws.php che espone le URL per poi smistarle alle funzioni dedicate. La funzione dedicata <funzione>_api.php effettua le query interfacciandosi con il layer che si occupa di interrogare il database, db- <funzione>.php. Le informazioni ritornano in formato JSON, perché le chiamate avvengono in formato AJAX; sarà poi il javascript a trasformare il JSON in HTML. NOTA: per i siti non è possibile avere questo tipo di architettura, in quanto l HTML è generato direttamente dal server; questo è derivante da problemi di indicizzazione, in quanto Google Bot non riconosce il Javascript, in quanto deve esserci già del testo all interno.

9 Deploy (Per la procedura di pubblicazione sono necessari due click lato utente) HUB Server FTP Sito di Front-end Server Primo Click Secondo Click L architettura software dell HUB e del sito di front-end è three-layers: Espone i servizi (*-ws.php) Logica (*_api.php) Query (db-*.php) *-ws.php: contengono le chiamate che provengono dall esterno (possono essere chiamate sia dal browser, come in questo caso, che da un altro server). Non fa nessun controllo ma espone le URL web services, per poi smistarli alle funzioni dedicate; *_api.php: è il layer che si occupa di smistare le richieste e contiene tutte le logiche di controllo; db-*.php: è il layer che si occupa di interfacciarsi direttamente con lo strato del database (contiene le query) Twoclick() Ø Click crea_versione() Viene creata prima la versione del deploy: 1. Page-ws.php espone la richiesta; 2. Passa il controllo a deploy_api.php tramite la chiamata do_create_package_ws(); 3. Tramite get_deploy_list() che si interfaccia con il database, permette di reperire l ultimo valore della versione, per poi incrementarlo; 4. Exp_td(): dopo aver ricevuto la version, fa l export delle tabelle all interno di un file di testo; 5. deploy_api.php zippa il file di testo dell export in locale; 6. insert_deploy(): scrive una riga bozza nella tabella delle versioni; Ø Click pubblica() Avviene la pubblicazione vera e propria: HUB:

10 1. Page-ws.php espone la richiesta; 2. Passa il controllo a deploy_api.php tramite la chiamata do_deploy_ws(); 3. deploy_api.php prende il pacchetto zip del file di testo e lo invia tramite PUT() al front-end del server FTP (sulla porta 21), andando a creare un demon sul server FTP; 4. deploy_api.php chiama il web service del layer di front-end dei siti (template-hub-ws.php) per comunicare che sul server FTP è presente un nuovo file (action=import). /hub-webservices/?action=import&brand=flo&versione=1() SITO DI FRONT-END SERVER 5. template-hub-ws.php si occupa dello strato di smistamento da deploy e smista le richieste al layer api.php tramite import_ws(); 6. deploy_api.php mette in produzione la versione=1, andando a unzippare il file; 7. deploy_api.php chiama l import sul database tramite import_hub_db() il quale chiama le query opportune, tramite il layer db-deploy.php, cancellando prima tutte le tabelle per poi andare a fare l import di quelle nuove (si cancellano direttamente e si ricreano).

11 Fatture (La conferma avviene in due passaggi) (Il sistema delle fatture segue sempre il sistema a 3 componenti: 1 componente: espone i servizi, 2 componente: logica, 3 componente: query.) Sito di Front-end HUB Componente.NET per interfacciarsi con SAP Server di posta SAP Va a leggere il token Invio form() 1. L utente invia i suoi dati; 2. Template-hub-ws.php è lo strato che espone il web services (i servizi possono essere chiamati sia dal browser [come in questo caso], oppure da un altro server [come nel caso del deploy]); 3. Tramite invia_fattura_ws() si richiamano le logiche all interno di hub/ws/fatture_api.php che richiama richiesta_cliente_fattura(); richiama il web service esposto dal front-end dell HUB page_ws.php, 4. Il front-end dell HUB va a richiamare richiesta_cliente_fattura_ws(): che va a verificare che sia presente su SAP (/verifica() > wsclienti.asmx). wsclienti.asmx non fa nessuna logica, espone le URL e le smista; salva sul database, tramite db_fatture.php, un token che corrisponde all del cliente che viene generato tramite insert_registrazione_fattura(); richiama la funzione send() che invia l di conferma. Nota token: all interno del token appaiono i dati della form abbinato alla mail del cliente; in seguito, per la conferma, si andrà a recuperare questo token per poi effettuare il conferma (all interno dell URL apparirà anche il token con i dati della form). È necessario salvarsi i dati della form perché la conferma avviene in due passaggi. Click link conferma() In questa fase si va a recuperare il token dei dati della form salvato precedentemente sul database, per poi scrivere definitivamente su SAP.