Exportar (0) Imprimir
Expandir Tudo
Expandir Minimizar

Estabilizando a implantação de aplicativos

Estabilizar

Publicado em: 30/11/2006

Durante as Fases Estabilizar e Implantar do projeto de implantação no computador, a equipe de recursos do gerenciamento de aplicativos está concentrada em solucionar rapidamente quaisquer problemas detectados nas instalações personalizadas.

A figura 20 mostra as atividades concluídas durante a Fase Estabilizar.

Bb490285.SE_AppMan20(pt-br,TechNet.10).gif

Figura 20. Atividades durante a Fase Estabilizar
Nesta página

Funções e responsabilidades
Testando os aplicativos implantados
Etapa: Prontidão da implantação revista

Funções e responsabilidades

Todos os seis grupos de função do Modelo de Equipe do MSF desempenham uma função nesta fase do projeto. O Guia Planejar , Criar , e Implantar apresenta essas funções e define as áreas de enfoque para cada grupo de função. A tabela 14 define essas áreas de enfoque dos diferentes grupos de funções para esta fase do projeto. Para obter mais informações sobre os grupos de funções do MSF, consulte Microsoft Solutions Framework (em inglês) em http://www.microsoft.com/technet/itsolutions/msf/default.mspx.

Tabela 14. Funções e responsabilidades durante a Fase Estabilizar

Grupo de função

Foco

Gerenciamento de produto

  • Execução do plano de comunicação

  • Planejamento do início da implantação

Gerenciamento de programa

  • Acompanhamento do projeto

  • Gerenciamento de bugs

Desenvolvimento

  • Resolução de bugs

Experiência do usuário

  • Material de treinamento

Teste

  • Testes e relatórios de bugs

Gerenciamento de versões

  • Gerenciamento e suporte ao piloto

  • Planejamento da implantação

  • Treinamento de operações e suporte

Testando os aplicativos implantados

Uma das primeiras etapas na fase Estabilizar é testar a implantação de diferentes pacotes criados na fase Desenvolver. O teste garantirá que os aplicativos principais e complementares sejam implantados e funcionarão corretamente depois da implantação. Como os aplicativos principais e complementares dependem da implantação da imagem no sistema operacional, os testes desses pacotes precisam ser sincronizados com os testes da imagem no sistema operacional. Para obter mais informações sobre os testes das imagens implantadas, leia a seção intitulada “Performing Lab Tests and Pilot Deployment” (em inglês) no Deployment Feature Team Guide (em inglês).

Execute dois tipos de testes para simplificar o isolamento e a solução de problemas de compatibilidade:

  • Testes da unidade. Teste recursos específicos de um aplicativo em um computador limpo, a fim de verificar as funções do aplicativo complementar em um ambiente ideal.

  • Testes de integração. Teste recursos específicos de vários aplicativos em um computador que tenha uma matriz mais complexa de aplicativos, de forma que seja mais semelhante aos computadores de produção.

À medida que os membros da equipe de recursos do gerenciamento de aplicativos realizarem os testes, eles devem avaliar e registrar os resultados. Se os testes revelarem problemas, primeiramente certifique-se de que sejam problemas de compatibilidade em vez de problemas com o ambiente de teste ou um aplicativo existente. Antes de supor que o problema seja de compatibilidade com o Windows, sempre execute as duas etapas a seguir:

  • Verifique se o problema não é relativo ao ambiente de teste. O problema pode ser o resultado de um problema de configuração de hardware, software ou rede em vez de um problema de compatibilidade de aplicativos.

  • Verifique se o problema não ocorre na versão do Windows atualmente em uso. Execute exatamente o mesmo teste na versão do Windows na qual o aplicativo é executado atualmente para verificar se funciona corretamente nessa instância. Se o mesmo erro ocorrer na plataforma atual, o problema não é de compatibilidade.

O processo de teste é interativo, identifica e soluciona problemas, bem como executa os testes novamente. As etapas no processo variam dependendo da natureza dos problemas detectados e da natureza da resolução. Os problemas que são solucionados pela aplicação de uma correção de compatibilidade de aplicativos, por exemplo, são gerenciados de forma diferente dos problemas solucionados pela modificação do código-fonte ou pela obtenção de atualizações do fornecedor.

Para problemas que possam ser solucionados pela aplicação de uma correção de compatibilidade de aplicativos, crie uma Fase Resolver na Fase Testar. Isso significa que, à medida que os membros da equipe de recursos do gerenciamento de aplicativos detectarem problemas, eles aplicarão as correções de compatibilidade de aplicativos e executarão os testes novamente até que o aplicativo esteja pronto para a implantação. Se os membros da equipe modificarem o código-fonte, o processo interativo será um ciclo mais tradicional de teste, depuração, codificação e recompilação, e novamente a execução do teste. Se o membro da equipe de recursos do gerenciamento de aplicativos não puder identificar uma correção de compatibilidade de aplicativos para solucionar o problema e não tiver o código-fonte, o membro da equipe deve entrar em contato com o fornecedor do aplicativo para obter uma atualização dele.

A Figura 21 ilustra o processo de testes.

Bb490285.SE_AppMan21(pt-br,TechNet.10).gif

Figura 21. O processo de testes do aplicativo.

A identificação do problema e a resolução de acompanhamento são fundamentais para um ciclo bem-sucedido de testes. A resolução de problemas é importante e o acréscimo desses problemas a uma base de conhecimento pesquisável auxiliará muito o grupo de funções da experiência do usuário quando for necessário treinar a equipe de suporte técnico. É imprescindível poder demonstrar não somente o problema e a resolução mas também o processo de solução do problema executado para corrigi-lo. Além disso, é melhor passar esse conhecimento aos outros e estimulá-los a fazer parte do processo em vez de concentrar o conhecimento em poucas pessoas.

Essa implantação de aplicativos complementares é somente uma pequena parte de um projeto cujo alcance afeta todos dentro e fora da empresa. Uma boa experiência de usuário obtém aceitação e uso, já a experiência negativa pode causar prejuízos não somente o projeto atual mas futuros projetos.

Os aplicativos freqüentemente podem ter incompatibilidades com outros aplicativos, especialmente se o aplicativo tiver sido reempacotado. Faça testes para verificar possíveis compatibilidades em qualquer uma das três seguintes formas:

  • Teste manualmente a implantação em ambiente de laboratório. Crie um ambiente de laboratório que tenha uma variedade de computadores da sua empresa. Quanto mais semelhantes esses computadores forem aos computadores clientes reais, mais confiável será o teste. Idealmente, os membros da equipe de recursos do gerenciamento de aplicativos utilizarão clones dos computadores cliente reais para os testes. Como os diferentes tipos de usuários podem ter diferentes aplicativos instalados, é imprescindível que os membros da equipe testem a implantação do aplicativo em uma variedade de computadores cliente.

  • Teste com ferramentas que não sejam da Microsoft. O AdminStudio Professional Edition e o Wise Package Studio incluem o recurso de simular a implantação de um pacote e relatar quaisquer problemas, detectar e solucionar conflitos em potencial de aplicativos e executar o teste de garantia de qualidade (QA, Quality Assurance) nos aplicativos depois da instalação nos computadores de destino.

  • Teste durante uma implantação em etapas. Depois que os membros da equipe de recursos do gerenciamento de aplicativos tiverem testado a implantação de aplicativos em um ambiente de laboratório, eles podem testá-la em computadores de produção através da inicialização de uma implantação limitada e em etapas. A implantação deve instalar aplicativos em bem poucos computadores até que a equipe esteja confortável com o fato de que o novo pacote não terá impactos negativos.

Estratégias da solução de problemas

Ao solucionar problemas de instalação de software, observe e identifique os sintomas dos problemas. Tente obter mais informações sobre as circunstâncias nas quais os problemas ocorrem e familiarize-se com o comportamento do sistema antes do surgimento dos problemas. Use as ferramentas que o Windows Server 2003 fornece para solucionar os problemas relacionados à instalação de software.

As estratégias abordadas nas seguintes seções geralmente se aplicam aos pacotes do Windows Installer. A solução de problemas da configuração baseada no InstallShield é abordada em “Solução de problemas do InstallShield” anteriormente neste guia. Para obter mais informações sobre as estratégias gerais de solução de problemas, consulte “Conceitos e estratégias da solução de problemas” no Microsoft Windows Server 2003 Resource Kit. Os links para os kits de recursos podem ser localizados na seção “Formação e referências” posteriormente neste guia.

Validando pacotes

A Microsoft recomenda a validação a cada pacote novo ou recém-modificado antes de tentar instalá-lo pela primeira vez. A equipe de recursos do gerenciamento de aplicativos pode usar a maior parte das ferramentas de criação do Windows Installer para executar a validação do pacote. Por exemplo, para validar os seus pacotes utilizando o Orca, incluído no Windows Installer Software Development Kit (SDK), a partir do menu Tools, clique em Validate.

A maior parte das ferramentas de criação do Windows Installer utiliza ICEs (Internal Consistency Evaluators, avaliadores de consistência interna) para executar a validação do pacote. Os ICEs são ações personalizadas escritas em VBScript, Microsoft JScript® ou como um arquivo .dll ou .exe. Quando executado, um ICE verifica o banco de dados do pacote, a fim de identificar entradas que sejam válidas individualmente mas que possam causar um comportamento incorreto no contexto de todo o banco de dados.

As ações personalizadas do ICE retornam quatro tipos de mensagens:

  • Informações. As mensagens informativas fornecem informações a partir do ICE e não indicam um problema com o banco de dados. Com freqüência, as informações são sobre o próprio ICE, como uma breve descrição. Essas mensagens também podem fornecer informações sobre andamento durante a execução do ICE.

  • Avisos. Os avisos relatam a criação de banco de dados que causa comportamento incorreto em determinados casos. Os avisos também podem relatar efeitos colaterais inesperados da criação de banco de dados (por exemplo, a inserção de duas condições separadas do mesmo nome de propriedade digitado da mesma forma mas com uma diferença de letras maiúsculas/minúsculas – como Alto e alto). Como o Windows Installer diferencia as maiúsculas de minúsculas, ele trata essas condições como duas propriedades diferentes.

  • Erros. Os erros relatam a criação de banco de dados que causa comportamento incorreto. Por exemplo, os GUIDs (identificadores globais exclusivos) do componente duplicado fazem com que o Windows Installer registre incorretamente os componentes.

  • Falhas. As falhas relatam a falha da ação personalizada do ICE. As falhas são geralmente causadas por um banco de dados com problemas tão graves que o ICE pode não ser executado.

Log de eventos

O log de eventos no Windows XP Professional e no Windows Vista fornece um método padrão e centralizado para que os aplicativos e o sistema operacional registrem eventos importantes de software e hardware. O serviço de log de eventos armazena os eventos de várias fontes em uma única coleção denominada um log de eventos.

O Windows Installer também grava entradas no log de eventos, o qual registra os eventos como:

  • O êxito ou a falha da instalação, remoção ou reparo de um produto.

  • Erros que ocorrem durante a configuração do produto.

  • Detecção dos dados de configuração corrompidos.

  • Informações sobre os componentes faltando que fazem com que um aplicativo precise ser reparado.

Se uma grande quantidade de informações for gravada, o arquivo de log de eventos poderá ficar cheio. Quando isso acontecer, o Windows Installer exibirá a mensagem: “The Application log file is full” (O arquivo de log do aplicativo está cheio).

Registro interno em log

O Windows Installer registra os erros e eventos em seu próprio log de erros interno (Nome_do_arquivo.log) e no log de eventos. As informações de diagnóstico que o Windows Installer grava nesses arquivos de log podem ajudar os membros da equipe de recursos do gerenciamento de aplicativos e os usuários a compreender por que uma instalação falha.

O tipo de registro em log que o Windows Installer executa é definido quando o modo de registro em log for definido. A equipe de recursos do gerenciamento de aplicativos pode usar vários meios para habilitar o modo de registro em log, como:

  • A opção da linha de comando /L do Msiexec.exe

  • O Registro

Com o uso da opção da linha de comando /L do Msiexec.exe, os membros da equipe de recursos do gerenciamento de aplicativos podem especificar exatamente o que é registrado em log e onde. A tabela 15 descreve os argumentos para registro em log quando a opção da linha de comando /L for utilizada.

Tabela 15. Argumentos para registro em log usando a opção da linha de comando /L

Argumento

Efeito

I

Mensagens de status

W

Avisos não fatais

E

Todas as mensagens de erro

A

Inicialização das ações

R

Registros específicos por ação

U

Solicitações do usuário

C

Argumentos iniciais de IU

M

Sem memória ou informação fatal de saída

O

Mensagens de que não há espaço em disco

P

Propriedades do terminal

V

Saída detalhada

+

Acrescentar a arquivo existente

!

Liberar cada linha para o log

*

Registre em log todas as informações, exceto para a opção V; para incluir a opção V, especifique /L*V

Para criar um arquivo de log normal para uma instalação da linha de comando, acrescente /L* LOGFILE.NAME à janela do prompt de comando Msiexec. Isso gera um arquivo de log normal com todos os argumentos selecionados, exceto para aqueles marcados com a opção da linha de comando V. Para um log detalhado, o qual tenha informações muito mais detalhadas, acrescente /L*V LOGFILE.NAME à janela do prompt de comando Msiexec. A sintaxe a seguir é um exemplo de um comando de log normal:

Msiexec /i Testdbsetup.msi /l* msi.log

A sintaxe a seguir é um exemplo de um comando de log detalhado:

Msiexec /i Testdbsetup.msi /l*v Msi.log

A sintaxe a seguir habilita o registro em log detalhado durante uma instalação sem qualquer interface. O arquivo de log é Program.log e reside na raiz da unidade C:

msiexec /qn /l*v c:\program.log /i \\server\share\setup.msi

Se o recurso de registro em log permanecer sempre ativado ou se uma instalação registrada em log não estiver em execução a partir da linha de comando, como uma instalação por demanda ou de auto-reparo, defina o valor do Registro REG_SZ Registro em log como icewarmup na chave de Registro HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer. Para criar um log detalhado, defina o valor de Registro como icewarmupv.

Os membros da equipe de recursos do gerenciamento de aplicativos devem usar essa diretiva somente se não tiverem habilitado o registro em log através da opção da linha de comando /L. Se a Diretiva de grupo for definida nesse caso, um arquivo log será criado no diretório Temp com o seguinte nome aleatório: .msi*.x.LOG.

Lendo um arquivo log

Suponha que o seguinte comando será utilizado para iniciar uma instalação:

msiexec.exe /I <path>\myapplication.msi /Lpiwaeo logfile.log

A tabela 16 apresenta os argumentos para registro em log utilizados no comando anterior.

Tabela 16. Argumentos do arquivo log

Argumento

Efeito

p

Propriedades do terminal

i

Mensagens de status

w

Avisos não fatais

a

Inicialização das ações

e

Todas as mensagens de erro

o

Mensagens de que não há espaço em disco

Por padrão, o Windows Installer não usa o registro em log detalhado. No entanto, os membros da equipe de recursos do gerenciamento de aplicativos podem instruí-lo a usar o registro em log detalhado utilizando uma entrada da linha de comando como:

<path>\setup.exe /L*v c:\logfile.log

ou

msiexec.exe /I <path>\myapplication.msi /Lpiwaeo logfile.log

Quando as ações forem concluídas com êxito, um valor de retorno de 1 (um) será exibido para a ação. Por exemplo, o resumo a seguir é de um log não detalhado:

=== Logging started: 5/17/06 13:55:41 ===
Action start 13:55:41: INSTALL.
Action start 13:55:41: CheckOSandSPAction.
Action ended 13:55:41: CheckOSandSPAction. Return value 1.

Os valores de retorno também são especificados nos logs detalhados junto com mais detalhes. O seguinte resumo de um log detalhado corresponde às mesmas ações que o exemplo anterior:

Observação Algumas partes do trecho de código a seguir foram exibidas em várias linhas para ficarem mais legíveis. Elas devem ser inseridas em uma única linha.

Action start 11:28:42: INSTALL.
MSI (c) (D6:6E): UI Sequence table 'InstallUISequence' is present and populated.
MSI (c) (D6:6E): Running UISequence.
MSI (c) (D6:6E): Skipping action: ResumeInstall (condition is false).
MSI (c) (D6:6E): Doing action: CheckOSandSPAction.
Action start 11:28:42: CheckOSandSPAction.
MSI (c) (D6:6E): Creating MSIHANDLE (1) of type 790542 for thread 110.
Action ended 11:28:42: CheckOSandSPAction. Return value 1.

Quando uma ação não puder ser concluída até que a próxima reinicialização do computador, geralmente será exibido um valor de retorno de 4 – por exemplo:

Observação Algumas partes do trecho de código a seguir foram exibidas em várias linhas para ficarem mais legíveis. Elas devem ser inseridas em uma única linha.

Action 14:18:30: InstallMMCExe.
Action 14:18:33: ForceReboot.
Action ended 14:18:33: ForceReboot. Return value 4.
Info 1101. Error reading from file: ScriptsDisabled. System error 
2. Verify that the file exists and that you can access it.
Action 14:18:35: RollbackCleanup. Removing backup files.
Action ended 14:18:37: INSTALL. Return value 4.
Action ended 14:18:38: ExecuteAction. Return value 4.
Action ended 14:18:38: INSTALL. Return value 4.

A tabela 17 apresenta os possíveis valores de retorno.

Tabela 17. Possíveis valores de retorno

Valor

Descrição

0

Ação não chamada; é mais provável que não exista

1

Ações concluídas com êxito

2

O usuário concluiu a ação prematuramente

3

Ocorreu um erro irrecuperável

4

Seqüência suspensa; será retomada posteriormente

Estratégias da solução de problemas

Se a equipe de recursos do gerenciamento de aplicativos usar uma interface para a instalação de software e a instalação falhar, uma mensagem de erro identificará a causa. Se o registro em log detalhado estiver habilitado, os membros da equipe podem encontrar informações adicionais sobre o erro no log. O arquivo log pode ajudar a definir a causa do problema.

Se um erro for interno, a documentação sobre o código de erro específico estará disponível no Windows Installer SDK. Geralmente, os erros internos resultam de um problema com o pacote ou com o serviço do Windows Installer.

Mensagens de erro

Inicie procurando pelo erro da palavra no arquivo log do Windows Installer. Se for exibido um número após o erro da palavra, o significado da mensagem de erro será exibido no tópico “Mensagens de erro do Microsoft Windows Installer” no arquivo de ajuda Msi.chm incluído no Windows Installer SDK. No arquivo log, use o número de erro para definir em qual seção o erro ocorreu, como uma gravação de Registro ou uma cópia de arquivo.

Como o Windows Installer não exibe todas as mensagens de erro e algumas mensagens não são exibidas nos logs, os membros da equipe de recursos do gerenciamento de aplicativos podem precisar usar uma tática alternativa para localizar o problema. As quebras incomuns nos carimbos de data e hora nas instruções do log, por exemplo, podem ajudar a definir a causa do problema. Essas quebras implicariam um atraso na rede ou no hardware.

Lembre-se de que um log detalhado fornece mais detalhes, como por que determinado arquivo foi ou não copiado – por exemplo:

Observação Algumas partes do trecho de código a seguir foram exibidas em várias linhas para ficarem mais legíveis. Elas devem ser inseridas em uma única linha.

MSI (s) (8B:82): Executing op: SetTargetFolder(Folder=D:\WINNT\inf\)
MSI (s) (8B:82): Executing op: SetSourceFolder(Folder=G:\Windows\inf\)
MSI (s) (8B:82): Executing op:
FileCopy(SourceName=agtinst.inf,DestName=agtinst.inf,
Attributes=8192,FileSize=7766,,,InstallMode=25427968,
PerTick=32768,IsCompressed=0,,VerifyMedia=1,,)
MSI (s) (8B:82): File: D:\WINNT\inf\agtinst.inf; 
Overwrite; Existing file is unversioned and unmodified
Reversões

Como as configurações do Windows são baseadas em transações, ocorrerá uma conversão se a configuração não for concluída. Procure pela conversão da cadeia de caracteres no log de configuração. Ignore a linha que diz removendo arquivos de conversão; os arquivos de conversão serão removidos no término da configuração bem-sucedida.

O resumo a seguir é de um log de uma instalação não concluída:

Observação Algumas partes do trecho de código a seguir foram exibidas em várias linhas para ficarem mais legíveis. Elas devem ser inseridas em uma única linha.

1: exsec32.dll 2: C:\Program Files\Common Files\System\Mapi\1033\
Internal Error 2925. C:\Program Files\Common Files\System\Mapi\1033\exsec32.dll,
 -2147024865
Action ended 12:25:04: InstallFinalize. Return value 3.
Action 12:25:08: Rollback. Rolling back action:
Rollback:

Aparentemente, a conversão está ocorrendo como resultado do erro com o arquivo Exsec32.dll. Localize o número do erro (erro interno 2925) no tópico “Mensagens de erro do Microsoft Windows Installer” no arquivo de ajuda Msi.chm incluído no Windows Installer SDK.

Computer Restarts

A menos que as reinicializações do computador sejam intencionalmente suspensas, as instalações iniciais podem requerer uma reinicialização do computador. Certifique-se de que a instalação continue após a reinicialização do computador.

Action start 16:47:38: ForceReboot.
Action 16:47:38: GenerateScript. Generating script operations for action:
Action 16:47:38: ForceReboot.
Action ended 16:47:38: ForceReboot. Return value 4.

Etapa: Prontidão da implantação revista

As etapas são pontos de sincronização de toda a solução. Para obter mais informações, consulte o Plan , Build , and Deploy Guide (em inglês).

Esta etapa, mostrada na tabela 18, representa a revisão bem-sucedida do ambiente de implantação e os resultados do teste; além disso, apresenta os seguintes resultados, os quais são os mesmos da etapa anterior.

Tabela 18. Resultados da etapa de revisão da prontidão da implantação

ID do resultado final

Descrição

Ambiente de implantação

Os servidores de implantação, dados e aplicativos estão disponíveis no ambiente de produção e prontos para implantação.

Relatório de teste

Os resultados do processo de teste serão documentados.

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2014 Microsoft