Gerenciando o Reporting Services

Question

Estamos expandindo o uso de nossos serviços de relatórios e estamos tentando definir algumas diretrizes para desenvolvedores e administradores sobre gerenciamento e desenvolvimento do sistema.

Você tem algum conselho sobre como manter um servidor de relatórios funcionando bem e organizado?

Existe alguma coisa que você possa ter feito diferente?

Estamos usando 2005 e planejamos mudar para o 2008 R2 em um servidor dedicado no próximo ano.

Nosso processo planejado se parece com isso:

1. O desenvolvedor obtém ferramentas
2. O desenvolvedor inicia um novo projeto e trabalha com usuários para identificar relatórios prioridades baseadas nas necessidades e viabilidade
3. Traduzir relatórios para especificações usando planilha de especificações - eliminar dados Exportações de relatórios
4. Os usuários assinam a especificação do relatório
5. Desenvolver e testar o relatório
6. O relatório é revisado pelo membro da equipe para código e especificação
7. O relatório é testado pelo usuário e aceito / rejeitado
8. O relatório é implantado para produção e testado pelo administrador, desenvolvedor e usuário
9. O relatório é revisado periodicamente para falta de uso, códigos de erro, tempo de execução excessivo

Answer 1

O seu plano parece essencialmente o que fazemos na minha empresa. Certifique-se de que você tenha bons backups de sua chave de criptografia para o Reporting Services. Essa seria a coisa mais comum que encontrei com instalações do Reporting Services que é problemática. Eu uso o Scripter do Reporting Services de Jasper Smith para facilitar o desenvolvimento de migrações de QA para produção. Eu também garanto que todos os relatórios usam procedimentos armazenados, o que me dá flexibilidade como um DBA para ajustar o Código TSQL mais facilmente.