Chi è responsabile della manutenzione di IIS per le app Web?

IIS / Applicazioni Web è stato un problema difficile nei negozi in cui ho lavorato nel tempo.

Da un lato, IIS è un servizio integrato nel server (in generale) ed è in genere la responsabilità degli amministratori del server di mantenere e configurare. Quando si presenta un problema, sanno cosa deve accadere o possono almeno diagnosticare al punto in cui dicono "Qualcosa non va con l'app Web" e fare in modo che lo sviluppatore esegua il debug del proprio codice.

Tuttavia, ogni applicazione Web sul server è unica e presenta molte sfumature che possono essere complesse in base ai problemi a portata di mano.

D'altra parte, ogni applicazione web è unica in molti modi e ha avuto problemi specifici che devono essere affrontati e lo sviluppatore è la persona che sa di più sull'applicazione. Se il file web.config deve essere modificato per il debug o un IIS inizia a dare problemi all'applicazione Web, lo sviluppatore dovrebbe sapere dove si trova il problema e risolverlo di conseguenza, a causa di IIS o dell'applicazione stessa.

Tuttavia, consentire a uno sviluppatore di entrare e modificare IIS da solo diventa un problema serio perché alcune impostazioni / ottimizzazioni possono compromettere seriamente le prestazioni e la stabilità del server.

Allora, dove sta l'equilibrio? Gli amministratori del server dovrebbero essere guru IIS e gestire tutti questi problemi e devo semplicemente inviare i file del sito durante la distribuzione o lo sviluppatore dovrebbe assumersi la responsabilità dei problemi del server e IIS e affrontarli di conseguenza?

Sembra che ciò di cui hai veramente bisogno sia qualcuno con esperienza su entrambi i lati della recinzione.

Nella mia esperienza (con aziende di piccole dimensioni), il personale IT / amministratore di sistema non ha il tempo, l'interesse o le conoscenze specifiche di webapp per mantenere correttamente le configurazioni IIS. Prenderanno le cose fino al sistema operativo e mi daranno IIS, lo sviluppatore.

Ovviamente, devo essere "più di un semplice programmatore" per farlo funzionare correttamente; Devo essere consapevole dei problemi a livello di sistema (sicurezza e quant'altro). Ho gestito la gestione dei sistemi a basso livello per anni, quindi sono fiducioso in questo tipo di attività (in effetti, ho insegnato agli amministratori di sistema alcune cose nel corso degli anni). Tuttavia, non tutti gli sviluppatori hanno questa capacità.

Tuttavia, da quello che ho visto, ci sono più sviluppatori con capacità di amministratore di sistema, quindi ci sono amministratori di sistema con abilità di sviluppo (webapp).

Come sempre, YMMV.

Personalmente non vorrei che uno sviluppatore si scherzasse con IIS, soprattutto se ciò potesse causare problemi con un'altra applicazione con un altro sviluppatore che doveva risolvere i problemi, e così via.

Se ci sono problemi con IIS, fai esaminare SysAdmin e se c'è un problema con una particolare app, rispediscilo allo sviluppatore. Se lo sviluppatore ha un problema, portalo al SysAdmin, che può quindi tentare di prendere una decisione informata sull'opportunità di apportare modifiche e capire come influenzerà tutti.

Noi (amministratori di sistema) trattiamo i nostri sviluppatori proprio come faremmo con un fornitore di terze parti: quando vogliono che noi distribuiamo un'app, devono fornire la documentazione se si aspettano che sia supportata. Ciò include routine di risoluzione dei problemi comuni e un percorso di escalation del supporto (requisiti di uptime combinati con una responsabilità documentata dello sviluppatore nel caso di un'interruzione inaccettabile).

Ovviamente non è in bianco e nero, ma ha fatto molto per allentare la tensione tra sviluppatori e amministratori. Gli sviluppatori ora si rendono conto che devono fornire software di qualità inversamente proporzionale alla loro disponibilità ad essere cercati dopo ore, e gli sviluppatori ora hanno strumenti e documenti da utilizzare senza sentirsi agganciati per strumenti che non hanno creato.

Quindi, nel tuo scenario, ciò significherebbe che gli sviluppatori creano la loro app sul proprio server IIS e quindi forniscono il software e la documentazione che gli amministratori devono installare sul server di produzione.

Gli amministratori del server dovrebbero essere guru IIS e gestire tutti questi problemi e devo semplicemente inviare i file del sito durante la distribuzione o lo sviluppatore dovrebbe assumersi la responsabilità dei problemi del server e IIS e affrontarli di conseguenza?

Risposta: trova una persona e annunciala "WSA" (Web Server Administrator) . Potrebbero essere un amministratore o uno sviluppatore; non importa davvero. Ma devono immergersi in entrambi gli aspetti del lavoro e il resto della squadra (da entrambe le parti) deve rispettare le proprie competenze.

Non è diverso da come DBA a cavallo della linea tra IT / sviluppo. Data l'importanza dei server Web in un'organizzazione con un prodotto basato sul Web, penso che questo sia un ruolo critico e spesso trascurato.

Poiché il Web è ancora giovane (rispetto ai database), è difficile reclutare questo individuo. Molto probabilmente dovrai far crescere / governare qualcuno nel ruolo.

Con nuove utility come lo strumento di distribuzione Web (che diventerà il modo standard incorporato per pubblicare un'app Web a partire da Visual Studio 2010), Microsoft sembra essere in procinto di consentire agli sviluppatori o almeno agli ingegneri di installazione di scegliere cose come le impostazioni IIS ( certificati, impostazioni del pool di app, ecc.). Vengono integrati nel pacchetto di installazione di msdeploy e applicati automaticamente al server IIS quando il pacchetto viene distribuito ai server.

Sembra un ragionevole compromesso. Gli sviluppatori non riescono a confondere manualmente con le impostazioni sui server di produzione live e gli amministratori di sistema non devono avere le conoscenze specifiche di webapp. Eppure le impostazioni IIS desiderate sono chiaramente visibili agli amministratori di sistema che vogliono capire cosa accadrà prima dell'installazione del pacchetto.