Parece que você precisa de alguém com experiência em ambos os lados da barreira.
O IIS / Web Applications tem sido um problema complicado nas lojas em que trabalhei ao longo do tempo.
Por um lado, o IIS é um serviço embutido no servidor (em geral) e é normalmente de responsabilidade dos administradores do servidor para manter e configurar. Quando um problema surge, eles sabem o que precisa acontecer, ou podem pelo menos diagnosticar até o ponto em que dizem "algo está errado com o aplicativo da Web" e fazer com que o desenvolvedor depure o código.
No entanto, cada aplicativo da web no servidor é único e tem muitas nuances que podem ser complexas com base nos problemas em questão.
Por outro lado, cada aplicativo da Web é único de várias maneiras e tinha problemas específicos que precisam ser resolvidos e o desenvolvedor é a pessoa que mais sabe sobre o aplicativo. Se o arquivo web.config precisar ser modificado para depuração, ou se um IIS começar a gerar problemas para o aplicativo da Web, o desenvolvedor deve saber onde está o problema e corrigi-lo de acordo, seja devido ao IIS ou ao próprio aplicativo.
No entanto, permitir que um desenvolvedor entre e desenvolva o IIS por si só se torna um problema sério, porque algumas configurações / otimizações podem prejudicar seriamente o desempenho e a estabilidade do servidor.
Então onde está o equilíbrio? Os administradores do servidor devem ser gurus do IIS e lidar com todos esses problemas e eu simplesmente envio os arquivos do site pela implantação, ou o desenvolvedor deve assumir a responsabilidade pelos problemas do servidor e do IIS e lidar com eles de acordo?
Na minha experiência (com empresas de menor porte), a equipe de TI / sysadmin não tem tempo, interesse ou conhecimento específico do aplicativo da Web para manter adequadamente as configurações do IIS. Eles levarão as coisas até o sistema operacional e passarão o IIS para mim, o desenvolvedor.
Obviamente, eu preciso ser "mais do que apenas um codificador" para fazer isso funcionar corretamente; Eu tenho que estar ciente dos problemas no nível do sistema (segurança e outras coisas). Eu tenho feito gerenciamento de sistemas de baixo nível por anos, então estou confiante com esse tipo de tarefa (na verdade, eu ensinei a alguns administradores de sistemas profissionais ao longo dos anos). No entanto, nem todo desenvolvedor tem essa capacidade.
Ainda assim, pelo que eu vi, existem mais desenvolvedores com habilidades de sysadmin, então existem sysadmin com habilidades de desenvolvimento (webapp).
Como sempre, YMMV.
Eu pessoalmente não gostaria que um desenvolvedor mexesse no IIS, especialmente se isso significasse que poderia causar problemas em outro aplicativo com outro desenvolvedor ter que solucionar problemas, sem parar.
Se houver problemas no IIS, faça com que o SysAdmin examine e, se houver um problema com um aplicativo específico, envie-o de volta para o desenvolvedor. Se o desenvolvedor tiver um problema, leve-o ao SysAdmin, que pode então tentar tomar uma decisão informada sobre se deve fazer alguma alteração e descobrir como isso afetará a todos.
Nós (os administradores de sistemas) tratamos nossos desenvolvedores da mesma forma como faríamos com um fornecedor terceirizado - quando eles querem que nós implantemos um aplicativo, eles precisam fornecer documentação se eles esperam que ele seja suportado. Isso inclui rotinas de solução de problemas comuns e um caminho de escalonamento de suporte (requisitos de tempo de atividade combinados com uma responsabilidade de desenvolvedor documentada, no caso de uma interrupção inaceitável).
Obviamente, não é preto-e-branco, mas é muito para aliviar a tensão entre desenvolvedores e administradores. Os desenvolvedores agora percebem que precisam fornecer um software de qualidade inversamente proporcional à sua disposição de serem paginados após o expediente, e os desenvolvedores agora têm ferramentas e documentos para percorrer sem se sentirem presos a ferramentas que não criaram.
Assim, no seu cenário, isso significaria que os desenvolvedores criam seu aplicativo em seu próprio servidor IIS e, em seguida, fornecem o software e a documentação para os administradores instalarem no servidor de produção.
Should the server admins be IIS gurus and handle all of those issues and I simply send the site files over deployment, or should the developer assume responsibility for the server and IIS issues and deal with them accordingly?
Resposta: encontre uma pessoa e anote-as "WSA" (Administrador do Servidor da Web) . Eles podem ser um administrador ou um desenvolvedor; isso realmente não importa. Mas eles precisam mergulhar em ambos os aspectos do trabalho, e o restante da equipe (de ambos os lados) precisa respeitar seus conhecimentos.
Não é diferente de como os DBAs ocupam a linha entre TI / dev. Dada a importância dos servidores da Web em uma organização com um produto baseado na Web, acho que esse é um papel importante e muitas vezes negligenciado.
Como a web ainda é jovem (em comparação com os bancos de dados), é difícil recrutar esse indivíduo. Você provavelmente precisará cultivar / preparar alguém para o cargo.
Com novos utilitários, como a Ferramenta de Implantação da Web (que se tornará o padrão Uma maneira de publicar um aplicativo da Web a partir do Visual Studio 2010), a Microsoft parece estar seguindo o caminho de permitir que desenvolvedores ou pelo menos engenheiros de instalação escolham configurações do IIS (certificações, configurações de pool de aplicativos, etc.). Eles são incorporados ao pacote de instalação do msdeploy e aplicados automaticamente ao servidor IIS quando o pacote é implantado em servidores.
Parece um compromisso razoável. Os desenvolvedores não usam manualmente as configurações nos servidores de produção ao vivo, e os administradores do sistema não precisam ter o conhecimento específico da webapp. E, no entanto, as configurações desejadas do IIS são claramente visíveis para os administradores de sistema que desejam entender o que acontecerá antes da instalação do pacote.
Tags iis web-applications