Procedure ottimali di implementazione / manutenzione di ASP.NET

Le applicazioni ASP.NET MVC sono compilate. Ciò significa che non puoi semplicemente caricare i file modificati, come ad esempio con un sito Web PHP. Questo significa anche che quando inizierai ad aggiornare il sito, gli utenti attuali verranno buttati via (per esempio, perdono le sessioni).

C'è anche molto altro da fare che aggiornare semplicemente i file: devi gestire:

• Permessi

  La nuova versione potrebbe richiedere un diverso set di permessi sul server.

• Configurazione

  La nuova versione potrebbe richiedere l'installazione del servizio Distributed Transaction Coordinator (MSDTC) o potrebbe voler utilizzare un server SMTP diverso o avere accesso ad Active Directory, ecc. Ciò comporta la modifica della configurazione dell'applicazione e di il server stesso.

• Dipendenze

  Ad esempio, uno dei problemi che vengono spesso incontrati dai principianti è che mantengono vecchie DLL in /bin mentre ne aggiungono di nuove con nomi diversi: l'applicazione può ancora usare quelle vecchie, il che crea una situazione pazzesca dove si modifica il codice dell'applicazione, ma il comportamento dell'applicazione rimane lo stesso.

• Dati

  Che cosa succede se lo schema del database è cambiato e l'applicazione utilizza un normale server SQL anziché NoSQL? Come eseguire la modifica nello schema? Come mantenere i dati corretti durante la modifica?

Gestire la transizione tra una versione vecchia e una nuova dell'applicazione è un compito difficile. Alcuni anni fa, era uno dei problemi, in cui una nuova versione dell'applicazione era pronta, ma impiegavano giorni o settimane per gli amministratori di sistema da distribuire. DevOps affronta questo problema, ma richiede agli sviluppatori di descrivere (tramite codice o configurazione) il sistema che ospiterà l'applicazione.

Più è grande l'applicazione, più complicata è questa attività.

• Per una piccola applicazione web, copiare i file sorgente sul server è sufficiente,

• Per qualcosa di più grande, devi avere un processo automatico che si occupa del processo di aggiornamento e il rollback nel caso qualcosa vada storto,

• Per i sistemi ancora più grandi, ad ogni nuova versione, vengono create e distribuite nuove VM e quelle vecchie vengono riciclate, assicurando una transizione senza interruzioni degli utenti dalla vecchia alla nuova versione.

Le applicazioni compilate semplicemente forzano / incoraggiano ad automatizzare il processo in precedenza.

the business contacted us to update some of the text and add a link to a new pdf document. The rest of my team were quick to say that this should not be done because the site is now live

IMO, non ci sono vere ragioni tecniche per questo rifiuto; vogliono solo evitare di farlo, perché, se non automatizzato, l'attività è soggetta a errori .

Di solito succede che:

1. L'applicazione viene distribuita per la prima volta.

2. Il team impiega alcune ore a modificare la configurazione per farlo funzionare. Poiché il team doveva consegnare tre settimane fa, tutti si precipitano e nessuno prende le note dei cambiamenti.

3. L'applicazione è ora disponibile e funzionante.

4. Per alcune settimane, mesi o anni, alcune persone casuali cambiano alcune cose casuali sul server: ad esempio spostano un database in una posizione diversa, oppure la password SMTP cambia, causando le modifiche in Web.config .

Se aggiorni la nuova versione ora, torni al primo passaggio e potrebbero essere necessari giorni per ripristinare la configurazione corretta. Poiché il sito web è attivo, questo dovrebbe essere evitato a tutti i costi.

Hai manager di progetto, un responsabile dello sviluppo o qualcun altro oltre agli altri sviluppatori?

Fa capire a ZERO che non è possibile eseguire una distribuzione dopo l'attivazione.

Ovviamente, questi cambiamenti devono essere pianificati, con costi e risorse tra le altre cose, ma solo dire "no" è una sciocchezza.

La ragione principale del comportamento che stai vedendo è che questi tipi di modifiche sono soggetti a errori. L'aggiornamento manuale dell'applicazione porta a cose dimenticate e alla sincronizzazione. Dovresti comunque essere in grado di fare nuove versioni (e dovrebbe essere facile) , non solo patch parziali.

Aggiornamenti parziali come la modifica di alcuni CSS o testo su un sito live potrebbero portare a saltare test, ambienti di test o stage che non sono sincronizzati, o addirittura a non commettere codice per il controllo del codice sorgente. Se si tratta di un cambio di codice, si potrebbe anche finire per rompere il sito dal vivo senza piano di recupero.

In .NET, poiché il codice è compilato, possono esserci altri problemi, come tempi di caricamento lunghi e perdita di sessioni utente. Questi problemi potrebbero essere mitigati dal mio scambio in un ambiente caldo e utilizzando lo stato di sessione fuori processo. Tuttavia, a meno che non si desideri riflettere su questo tipo di problemi e su altri aspetti specifici dell'applicazione ogni volta che si desidera eseguire una distribuzione. Quindi l'applicazione di patch ai siti Web live è una cattiva idea.

Man mano che la tua applicazione cresce di dimensioni e le persone vanno e vengono, può passare da un inconveniente a un problema serio. Quindi, per rendere le cose più sicure, seguiamo regole come: Per aggiornare un sito web dal vivo, deve essere una distribuzione completa, mai solo rattoppata.

Se non stai ancora automatizzando le tue implementazioni (il che rende facile e veloce seguire la regola). Le nuove distribuzioni vengono solitamente eseguite accanto alla versione esistente e quindi il sito Web è solo un puntatore alla versione desiderata (lo schema del database Nota lo rende un po 'più complesso).

1.0.0  // Old version you can roll back to   
2.0.0 <-- IIS points here

In realtà, penso che tutte le implementazioni siano realmente automatizzate e che includano anche implementazioni non .NET, per ragioni simili . Una volta che avvii l'automazione delle distribuzioni, puoi garantire che sono costantemente veloci e affidabili.

Riesco a ripubblicare / ridistribuire regolarmente diversi siti Web ASP.NET MVC distribuiti su Amazon AWS, Windows Azure e server Web privati e non vedo alcun motivo per cui il tuo team ne faccia una così grande quantità.

Tuttavia, dovresti progettare i tuoi siti web in modo tale che le attività come l'aggiornamento di testi e collegamenti debbano essere eseguite attraverso il database tramite l'interfaccia di amministrazione del sito web.

Il mio punto è che, mentre le modifiche a un sito web live sono OK (si chiama sviluppo), la ridistribuzione dell'applicazione per modificare una stringa di testo è probabilmente indicativa di una progettazione errata. Non sto suggerendo che la ripubblicazione potrebbe essere eseguita senza cura.