Resumo: Há algo de errado em enviar conteúdo diretamente para produção? Isto não é alteração de código ou alteração de funcionalidade. Apenas edição/adição de conteúdo. Atualmente usamos 4 servidores para fazer isso, é um pouco complicado. Para obter detalhes, leia abaixo.
Acabei de herdar uma rede SMB que possui todos os tipos de idiossincrasias. Uma dessas idiossincrasias é desconcertante pela sua complexidade. Tenho certeza de que é como uma máquina Rube-Goldberg, mas quero ter certeza.
Temos um aplicativo cliente/servidor que usa um servidor de aplicativos baseado em IIS. Este servidor de aplicação medeia a interface web e uma conexão de banco de dados - que no nosso caso, está hospedado em outro servidor (MSSQL2005). Existem arquivos .tif que são carregados por meio deste aplicativo e armazenados no banco de dados como um blob. Há também dados que fazem uma máscara sobre a imagem (para que possa fazer formulários preenchidos). Também hospedamos um servidor público que atua como repositório dessas imagens/máscaras para que outras pessoas não tenham que criá-las manualmente.
OK, comigo até agora? Basicamente, o arquivo .tif e os dados vão de um lado e do outro o público pode baixar essa imagem/dados.
Aqui está a parte estranha. Em vez de fazer com que nossos usuários carreguem essas imagens completas (e com controle de qualidade) diretamente para a produção, elas vão para um servidor interno. Um processo extrai o blob e recria o arquivo .tif. Este processo também extrai apenas os dados necessários para os formulários. Em seguida, ele vai para um servidor temporário. Este servidor de teste é uma duplicata do servidor de produção, mas nunca usamos essa parte dele - exceto para este processo. Uma vez na preparação, outra tarefa é executada para finalmente replicar a imagem e os dados para o servidor de produção. O servidor temporário é, entretanto, usado para desenvolvimento web. Se algo acontecer, poderá quebrar essa cadeia de eventos e interromper as replicações.
Também é importante notar que o backup deste servidor de produção é feito regularmente, portanto, o teste não se destina à recuperação de desastres. O servidor temporário também não é público, portanto não é usado para redundância. Está simplesmente lá.
Para piorar a situação, essas tarefas parecem ser realizadas com scripts VBS, arquivos bat e tarefas agendadas do Windows, em vez de qualquer tipo de tarefa/gatilho do SQL Server.
Minha pergunta é "tudo isso é necessário?" Por que um gatilho não pode ser configurado no servidor SQL original para atualizar o servidor de produção sempre que um sinalizador de controle de qualidade for definido como verdadeiro? Por que passar por toda essa cópia? Existe uma razão para eu estar ausente?
Só quero ter certeza de que estou fazendo a coisa certa para resolver nossa rede.
Obrigado por ler.
Responder1
Sinto o rastro fétido da preguiça. Suponho que em algum momento durante o processo de desenvolvimento deste aplicativo específico, algo não funcionou. Ou melhor, funcionou no Staging, mas não na Produção. E para fazer as coisas funcionaremagora mesmoeles conectaram o servidor de teste à produção da maneira que você mencionou. O que aconteceu. E como estava funcionando, quem não se incomodou tentou descobrir por que não estava funcionando e simplesmente desistiu.
Entre você.
Porque é este caminho? Porque funciona.
Como isso ficou assim? Desconhecido, mas acho que algo quebrado foi uma parte fundamental do motivo pelo qual tudo ficou assim.
Sinta-se à vontade para resolver issocertocaminho.