Content Staging para um aplicativo específico

1

Resumo: há algo errado em enviar conteúdo diretamente para a produção? Isso 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 de porco. Para detalhes, leia abaixo.

Eu apenas herdei uma rede SMB que tem todos os tipos de idiossincrasias. Uma dessas idiossincrasias é desconcertante em sua complexidade. Tenho certeza que é como uma máquina tipo Rube-Goldberg, mas eu quero ter certeza.

Temos um aplicativo cliente / servidor que usa um servidor de aplicativos baseado em IIS. Esse servidor de aplicativos medeia a GUI da web e uma conexão de banco de dados - que, no nosso caso, está hospedada em outro servidor (MSSQL2005). Existem arquivos .tif que são carregados por meio desse aplicativo e armazenados no banco de dados como um blob. Há também dados que fazem uma máscara sobre a imagem (para que ela possa fazer formulários preenchidos). Também hospedamos um servidor público que atua como um repositório para essas imagens / máscaras, para que outros não precisem criá-las manualmente.

OK, comigo até agora? Basicamente, o arquivo .tif e os dados vão em uma extremidade e na outra extremidade, o público pode baixar essa imagem / dados.

Aqui está a parte estranha. Em vez de fazer com que nossos usuários façam upload dessas imagens concluídas (e QAed) diretamente na produção, elas entram em um servidor interno. Um processo, em seguida, extrai o blob e recria o arquivo .tif. Esse processo também extrai apenas os dados necessários para os formulários. Em seguida, vai para um servidor de teste. Esse servidor de temporariedade é uma duplicata do servidor de produção, mas na verdade nunca usamos essa parte dele - exceto por esse processo. Uma vez em preparação, outra tarefa é executada para finalmente replicar a imagem e os dados no servidor de produção. O servidor de teste é, no entanto, usado para desenvolvimento da web. Se algo acontecer, pode quebrar essa cadeia de eventos e interromper as replicações.

Também é importante notar que este servidor de produção é submetido a backup regularmente, portanto, o teste não é destinado à recuperação de desastres. O servidor intermediário também não é público, portanto, não é usado para redundância. Está apenas lá.

Para adicionar insulto à injúria, essas tarefas parecem ser feitas com scripts vbs, arquivos bat e tarefas agendadas do Windows, em vez de qualquer tipo de tarefa / acionamento 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 é definido como verdadeiro? Por que passar por toda essa cópia? Existe uma razão pela qual estou ausente?

Eu só quero ter certeza de que estou fazendo a coisa certa para resolver nossa rede.

Obrigado pela leitura.

    
por Tim 26.08.2012 / 01:33

1 resposta

3

Eu sinto o rastro fétido de preguiça. Em um palpite, em algum lugar durante o processo de desenvolvimento deste aplicativo em particular, algo não funcionou. Ou melhor, funcionou em Staging mas não em Production. E para fazer as coisas funcionarem agora, eles colocaram o servidor de teste na produção da maneira que você mencionou. O que aconteceu. E desde que estava funcionando, quem não se incomodou em tentar descobrir por que não estava funcionando em primeiro lugar e apenas o deixou.

Entre em você.

Por que é assim? Porque funciona.

Como ficou assim? Desconhecido, mas eu acho que algo quebrou foi uma parte fundamental do porquê isso aconteceu.

Sinta-se à vontade para resolver isso da maneira correta .

    
por 26.08.2012 / 01:44

Tags