SharePoint 2010: Monte o ambiente apropriado
A maneira como você configura seus ambientes e processos de desenvolvimento e teste pode afetar imensamente seus aplicativos.
Steve Wright e Corey Erkes
Adaptado de "Pro SharePoint 2010 governança" (Apress, 2012)
Ao longo de qualquer projeto de grande desenvolvimento, você precisará gerenciar diferentes tipos de informações. É preferível ter um repositório central de informações que integra com as outras ferramentas utilizadas pela equipe de desenvolvimento.
Existem diversos produtos para ajudar as equipes de desenvolvimento, de colaborar e comunicar, e Microsoft Visual Studio Team Foundation Server (TFS) tem vantagens quando utilizado para desenvolvimento do SharePoint. Ele é totalmente integrado com o Visual Studio e SharePoint. Se sua organização já não tem essa ferramenta e será o desenvolvimento de aplicações, principalmente para o ambiente Microsoft Windows, você deve considerar o TFS.
Independentemente do produto e o método que você escolher, existem algumas características que a plataforma deve ter, incluindo:
- **Controle de código fonte:**Isso mantém um registro de todas as alterações para cada arquivo de origem na solução. Versionamento de biblioteca do SharePoint não é apropriado para esta finalidade. Um sistema de controle de fonte de verdade suporta muitas funcionalidades para além de uma única seqüência de alterações de arquivo de rastreamento.
- **Gestão de exigência:**Esta traça cada bug, trabalho e o arquivo de origem item volta para as exigências a que está relacionada.
- **Acompanhamento do Item de trabalho:**Isso registra o relatórios de bugs, bilhetes de balcão de ajuda, solicitações, lançamentos e tarefas associadas com o projeto.
- **Automação de Build:**Isso compila os arquivos de fonte em arquivos de solução implantável.
- **Gerenciamento de testes:**Isso registra casos de teste automatizados e manuais, automatiza testes de unidade e de regressão, gerencia a implantação para farms de servidor de teste e realiza testes de carga.
Nem todas as plataformas de desenvolvimento de equipe vão apoiar todas essas características. No entanto, o controle de código fonte é uma função que é absolutamente necessária para manter um aplicativo estável base. As outras funções podem ser mais ou menos importantes para uma determinada organização. Também pode ser aceitável usar ferramentas separadas, não integrados para essas funções.
Ambientes de desenvolvedor
Um dos aspectos mais desafiadores de desenvolvimento do SharePoint é estabelecer um ambiente de desenvolvimento produtivo. Refere-se à área onde um desenvolvedor individual pode trabalhar para criar e depurar seus componentes atribuídos ou atualizações. O SharePoint é uma tecnologia de servidor, então componentes concebidos para executar em um servidor do SharePoint, geralmente tem que ser desenvolvido em um também.
Um erro comum é ter um "servidor de desenvolvimento" usado por todos os desenvolvedores da equipe. A menos que os membros da equipe estão trabalhando em componentes totalmente independentes e nunca precisam fazer comum coisas como reiniciar o IIS ou anexar um depurador a um processo do IIS, esse tipo de ambiente geralmente não funciona bem. Os desenvolvedores precisam controle total sobre o servidor efetivamente depurar problemas. Isolar os desenvolvedores entre si é a melhor maneira de manter todos produtivos.
Um outro equívoco é que você pode desenvolver em um sistema de cliente executando Visual Studio e depuração em um servidor remoto executando o SharePoint. Enquanto você pode depurar uma solução do SharePoint em execução no outro servidor, você deve ainda ter o SharePoint instalado no sistema de compilação de código do lado do servidor do SharePoint. As bibliotecas que usa o código do lado do servidor estão disponíveis somente em um servidor do SharePoint. Você não pode tê-los instalados separadamente em um computador cliente para permitir que o código seja compilado. Se você estiver desenvolvendo aplicativos cliente usando somente o cliente objeto modelos novos (cliente OMs) introduzido com o SharePoint 2010, você pode compilá-los em um sistema que não tem o SharePoint instalado.
Um ambiente de desenvolvimento do SharePoint mínimo deve incluir o seguinte:
- Um 64-bit sistema operacional Windows compatível com o SharePoint 2010 (Windows 2008 Windows Vista SP1 ou Windows 7)
- Visual Studio 2010
- SQL Server Express Edition
- Componentes do Windows SharePoint Services ou servidor conforme necessário
As seguintes ferramentas são frequentemente úteis e você deve incluí-las sempre que possível:
- Aplicações de Microsoft Office
- SQL Server Developer Edition
- Microsoft Visio
- InfoPath Designer
- SharePoint Designer (download grátis)
Você também tem várias opções a considerar sobre onde instalar estas ferramentas. A opção primeira e mais simples é para carregar todas as ferramentas e o SharePoint diretamente no computador do desenvolvedor. Isso requer um sistema operacional de 64 bits compatível com o SharePoint. Esta configuração é fácil de usar, pois todas as ferramentas necessárias estão prontamente disponíveis.
Infelizmente, esta configuração é limitada pelo poder do computador desktop, o armazenamento de disco rígido e o fato de que você só pode usar uma configuração do SharePoint. Um desenvolvedor que move-se com frequência entre projetos pode encontrar este tipo de configuração difícil de gerir.
Opções de desenvolvimento
A próxima opção é usar um produto de virtualização de desktop como Oracle VirtualBox ou VMware Workstation. Novamente, você deve estar certo de que você usar qualquer ferramenta de virtualização oferece suporte a um sistema operacional de convidado de 64 bits. Essa configuração tem muitas das mesmas limitações como instalar diretamente o meio ambiente na área de trabalho. Normalmente, o desempenho não é muito bom e você vai precisar de arquivos de disco grande para suportar a virtualização de desktop.
A vantagem deste tipo de ambiente é que ele permite que você hospede várias configurações do SharePoint em separado máquinas virtuais (VMs) na mesma área de trabalho. Normalmente, os requisitos de memória e desempenho não permitem que você executar VM mais de uma vez, no entanto.
Você também pode criar um arquivo de disco rígido virtual (VHD) e executá-lo diretamente no sistema sem passar por um produto de virtualização de desktop. Isso é semelhante para a instalação de "dual-boot" antigo para um sistema. Em vez de usar uma partição separada para o sistema operacional segundo, você usaria um arquivo VHD dentro do sistema de arquivos do sistema operacional existente. Essa configuração tem a vantagem de usar todo o hardware do sistema sem a necessidade de um segundo consecutivo de sistema operacional para hospedar o servidor de desenvolvimento.
A única desvantagem é que qualquer aplicativo carregado no cliente na área de trabalho sistema operacional não está disponível durante a execução do ambiente de desenvolvimento. Isso está se tornando rapidamente a configuração mais popular para desenvolvedores do SharePoint porque ele fornece a flexibilidade da virtualização do desktop sem incorrer em custos de desempenho. Para obter mais informações sobre a execução de vários SOS usando a nova configuração de inicialização do Windows 7, consulte Keith Combs' blog, "Dual Boot de VHD usando Windows 7 e Windows Server 2008 R2."
A configuração final usa virtualização de servidores. Este poderia ser o Microsoft Hyper-V, VMWare ou qualquer outro produto de virtualização de servidor. Esta é uma excelente opção para uma empresa com uma infraestrutura de virtualização boa. Provido de uma máquina virtual em um servidor do host da VM e usar esse servidor para abrigar o ambiente de desenvolvimento inteiro.
Usando um cliente de Remote Desktop Protocol (RDP), seu colaborador tem acesso a um completo ambiente sem fazer quaisquer alterações ou instalações em seu ambiente local. A única desvantagem com essa configuração é que você deve ser capaz de se conectar ao servidor VM para realizar tarefas de desenvolvimento. Você não pode "levá-lo."
Ambientes de teste
Concluído o desenvolvimento, você terá que colocar o aplicativo através de um regime de teste rigoroso, bem definido. Isso requer que você carregá-lo em um ou mais ambientes de não produção antes da implantação de produção. Esses ambientes vão por muitos nomes, incluindo integração, teste, fase, testes de aceitação de usuário (UAT), pré-produção, e assim por diante.
Você pode usar um farm de integração para testar todos os componentes compilados em um ambiente que não contém quaisquer ferramentas de desenvolvimento. A presença de Visual Studio ou outras ferramentas de desenvolvimento em um sistema, às vezes pode mascarar erros que ocorrem apenas quando essas ferramentas não estão disponíveis.
Uma vez que o lançamento é testado, entregá-lo para o grupo de garantia de qualidade, ou de qualquer departamento é responsável por UAT. Então esse grupo de testes será carregado a liberação para a fazenda de pré-produção. Esta fazenda deve ser semelhante para a fazenda de produção possível ajudar o grupo de testes avaliar a prontidão de produção do lançamento.
Por exemplo, se a fazenda de produção possui vários servidores Web front-end, assim, também, se a fazenda de pré-produção. Servidores virtuais são muitas vezes substituídos por servidores físicos para tornar os ambientes de teste mais rentável. Uma vez UAT é completa, você pode implantar o aplicativo para o farm de servidores de produção final.
Quando uma nova versão de teste, é importante usar o conteúdo como similar ao conteúdo na produção possível. Por exemplo, se um usuário tiver personalizado algum item em um site do farm de produção que interfere com a mudança feita para o aplicativo, você pode não notar se a mudança só é verificada com dados de teste "falso". Uma excelente fonte de dados de conteúdo realistas para o teste é o farm de servidores de produção. Você pode facilmente fazer backup e restaurar os produção conteúdo bancos de dados em ambientes de teste, na maioria dos casos.
Outra configuração comum para testar e implantar aplicativos do SharePoint é usar um farm de servidor de preparo. Com esta técnica, há dois farms de servidores completo, funcionando em todos os momentos. Seus usuários usam um e outro está por receber a nova versão. Uma vez que o lançamento é implantado para a fazenda de preparo, a rede é reconfigurada para rotear o tráfego de entrada para a fazenda de preparo. Assim, os servidores de teste se tornam a produção e os servidores de produção mudar para encenação.
Esta é uma técnica útil para sites voltados para o público em que você não pode permitir tempo de inatividade. O tempo necessário para trocar os farms de servidores é só enquanto ele toma para redirecionar o tráfego de rede. Obviamente, é vital que todas as atualizações de conteúdo de produção são movidas para a fazenda de preparo antes da implantação da nova versão. Para evitar atualizações depois que o conteúdo começa a ser copiado, SharePoint permite temporariamente bloquear conteúdo bancos de dados.
Quando você usar essa técnica, o ambiente de preparação também pode servir como um hot standby para o farm de produção. Se a produção sofre uma falha catastrófica, você pode rapidamente abrir o servidor de teste para restaurar o serviço. Se esta é a parte do seu plano de recuperação de desastres, regularmente deve copiar conteúdo de produção para a fazenda de preparo, mesmo quando você não está implantando novos lançamentos. Também pode ser útil ter as fazendas de encenação e produção hospedadas em locais físicos separados para fornecer redundância de localização. Qualquer uma destas técnicas e configurações pode ajudá-lo a desenvolver um ambiente de desenvolvimento do SharePoint que melhor se adapte às suas necessidades e recursos.
.jpg)
Steve Wright é gerente sênior de gestão de inteligência de negócios (BIM) para Sogeti USA LLC em Omaha, Nebraska Ao longo dos anos 20-última Plus, Wright trabalhou no controle de tráfego aéreo, financeiro, seguros e uma infinidade de outros tipos de sistemas. Ele tem o autor e realizadas avaliações técnicas para muitos títulos anteriores cobrindo produtos Microsoft, incluindo Windows, SharePoint, SQL Server e BizTalk.
.jpg)
Corey Erkes é Consultor Gerente Sogeti USA LLC em Omaha, NEB. Erkes trabalhou com uma vasta gama de empresas em diferentes pontos do ciclo de vida de suas implementações de SharePoint. Ele também é um dos membros fundadores do grupo de usuários do SharePoint de Omaha.
© 2012 Apress Inc. Todos os direitos reservados. Impresso com permissão da Apress. Copyright 2012. "Pro SharePoint 2012 governação" por Steve Wright e Corey Erkes. Para obter mais informações sobre este título e outros livros similares, visite por favor apress.com.