Gerenciamento do ciclo de vida dos aplicativos do SharePoint
Aplica práticas e conceitos comuns de ALM (gerenciamento do ciclo de vida do aplicativo) para o desenvolvimento de aplicativos usando as tecnologias do SharePoint.
Fornecido por: Eric Charran, Microsoft Corporation
Colaboradores: Vesa Juvonen, Microsoft Corporation | Steve Peschka, Microsoft Corporation
Importante: este tópico se refere aos Suplementos do SharePoint auto-hospedados. O programa de visualização para aplicativos auto-hospedados foi encerrado. Desconsidere todas as referências a Suplementos do SharePoint auto-hospedados.
Visão geral de ALM (gerenciamento do ciclo de vida do aplicativo)
O Microsoft SharePoint oferece aos desenvolvedores várias opções para criar e implantar aplicativos baseados nas tecnologias do SharePoint, tanto para plataformas locais e hospedadas internamente quanto para aquelas em nuvem pública. O SharePoint oferece mais flexibilidade na forma que os aplicativos podem ter, assim como novas opções para o uso de tecnologias baseadas em padrões com aplicativos. Embora esses recursos de aplicativo e opções de implantação proporcionadas pelo novo modelo de aplicativo emSharePoint fornecem um meio eficaz para os desenvolvedores criem aplicativos novos e imersivos, os desenvolvedores devem ser capazes introduzir qualidade, teste e considerações de ALM ao processo de desenvolvimento. Este artigo se aplica a conceitos comuns de ALM e práticas recomendadas para o desenvolvimento de aplicativos usando as tecnologias do SharePoint.
Novidades
O SharePoint estabelece um novo paradigma para a implementação de aplicativos. Devido a essa mudança no desenvolvimento de aplicativos com as tecnologias de SharePoint, desenvolvedores e arquitetos devem ter uma compreensão detalhada dos novos padrões de desenvolvimento de aplicativos, práticas recomendadas e modelos de implantação para SharePoint. É importante observar que, enquanto o modelo de aplicativo para desenvolver soluções com SharePoint foi alterada, muitos dos padrões usados para o desenvolvimento de soluções, incluindo a escolha das tecnologias, técnicas de implementação são alinhado com tecnologias de desenvolvimento de aplicativos web existentes.
Os recursos a seguir descrevem os tipos de aplicativos que podem ser construídos usando tecnologias do SharePoint e contêm considerações para aplicativos locais e na nuvem. Para entender as opções de hospedagem de Suplementos do SharePoint, confira Escolher padrões para desenvolver e hospedar seu Suplemento do SharePoint.
Além disso, a Microsoft recomenda aos clientes avaliar as tecnologias usadas ao desenvolver aplicativos com SharePoint, pois há um conjunto mais amplo de opções para a implementação da solução. Ao criar aplicativos, os clientes podem se concentrar na Aproveitando tecnologias baseadas em padrões, como HTML5 e JavaScript para apresentação e usuário enfrentar camadas, enquanto OData e OAuth podem ser utilizada para acesso baseado no serviço ao fazer encerrar serviços, incluindo o SharePoint. Os clientes devem considerar cuidadosamente se o código de confiança total (ou seja, compilados conjuntos implantados SharePoint ) são necessários. Embora continuam a usar esse paradigma de desenvolvimento, enquanto ainda válido e necessário em algumas situações, impor sobrecarga significativa sobre o processo ALM.
Para saber mais sobre as novas tecnologias de desenvolvimento flexíveis para aplicativos no SharePoint, confira Visão geral de desenvolvimento do SharePoint.
Benefícios e riscos
Porque SharePoint-tecnologias de desenvolvimento de aplicativo compatível agora oferecem uma classificação mais flexível de idiomas e arquiteturas de programação, os desenvolvedores precisam se adaptar práticas ALM existentes ao redor de técnicas de desenvolvimento indispensável para acomodar para sua presença dentro SharePoint. Conceitos como testes, estabelecimento, implantação e controle de qualidade de compilação, pode ser expandida para incluir implantação SharePoint como um aplicativo de SharePoint. Isso significa que, apesar de muitos desenvolvedores estarem acostumados a escrever e implantar soluções de farm do lado do servidor que estendem os recursos de núcleo do SharePoint, as práticas comuns de ALM para o novo modelo de desenvolvimento flexível facilitado por aplicativos do SharePoint devem ser aplicadas ao processo de implementação.
À medida que os clientes continuam a transição para implementações de Microsoft Office SharePoint Online em nuvem, os desenvolvedores precisarão entender como estender os conceitos de ALM para incluir o desenvolvimento, testes e ambientes-alvo de implantação que se situam fora dos limites físicos da organização. Isto inclui a avaliação da estratégia tecnológica para conduzir o desenvolvimento, teste e implementação de aplicativos.
Tanto os arquitetos e desenvolvedores podem se tornar bem versados na soluções que consistem em vários componentes de aplicativo que abrangem ou combinam tipos diferentes de opções de hospedagem para resumir. Durante esse processo de adaptação, procedimentos ALM devem ser aplicados unilateralmente a esses aplicativos. Por exemplo, pode ser que os desenvolvedores precisem implantar um aplicativo que abrange a implantação de serviços locais (ou seja, IIS, ASP.NET, MVC, WebAPI e WCF ), Microsoft Azure, SharePoint e SQL Azure, enquanto também devem ser capazes de testar os componentes de aplicativo para determinar a qualidade ou se alguma regressão foi introduzida desde um build anterior. Esses requisitos podem significar uma mudança significativa nas como desenvolvedores e equipes consideram o processo de compilação e implantação diário que é um procedimento conhecido para soluções do lado do servidor ou local.
Considerações sobre equipe de desenvolvimento
Para organizações que possuem mais de um arquiteto ou desenvolvedor de aplicativos, o desenvolvimento de equipe para SharePoint deve ser planejado cuidadosamente para fornecer os aplicativos de mais alta qualidade, bem como suporte suficiente para produtividade do desenvolvedor. Porque o método para a realização do desenvolvimento de aplicativos aumentou em flexibilidade, equipes precisará ser clara e confiantes não apenas para padrões e práticas ALM, mas também sobre como cada desenvolvedor será escrever código e certifique-se de que o código de qualidade se torna parte do aplicativo construir processo.
Essas considerações começam com selecionando o ambiente de desenvolvimento apropriado. Tradicionalmente, desenvolvimento foi relegado ao conduzir desenvolvimento separados em máquinas virtuais que estão conectados a um repositório comum de código que forneceu compilação, implantação e as capacidades de teste, como Visual Studio TFS 2012. TFS ainda é um componente fundamental forte de uma estratégia ALM e centrais para esforço de desenvolvimento, mas equipes devem ser considerados como aproveitar o TFS os diferentes tipos de opções do ambiente de desenvolvimento.
Dependendo do ambiente de destino, o tipo de solução (isto é, quais componentes serão local e qual será hospedado na infraestrutura de nuvem ou serviços), os desenvolvedores agora podem selecionar entre uma combinação de novas opções de ambiente de desenvolvimento. Essas opções consistirá novas opções, como o modelo de site de desenvolvedor SharePoint, um locatário de desenvolvedor Office 365, bem como as escolhas herdadas como desenvolvimento baseado na máquina virtual usando o Hyper-V em Windows 8 ou Windows Server 2012.
A seção a seguir descreve as considerações de ambiente de desenvolvimento para os desenvolvedores de aplicativos e equipes de desenvolvimento.
Considerações sobre ambiente de desenvolvimento
A seleção de um ambiente de desenvolvimento deve ser feita com base em vários fatores. Essas considerações são amplamente influenciadas pelo tipo de aplicativo sendo desenvolvido, bem como a plataforma de destino para o aplicativo. Tradicionalmente, ao criar aplicativos para SharePoint Server 2010, os desenvolvedores seriam provisionar máquinas virtuais e conduzir o desenvolvimento no isolamento. Isso era devido ao fato de que a implantação das soluções de confiança total pode ter necessárias reinicializações de dependências de SharePoint de núcleo, como IIS, que impediria que vários desenvolvedores usando um ambiente único SharePoint. Como as tecnologias de desenvolvimento foram alteradas e as opções para os desenvolvedores que criam aplicativos aumentaram, desenvolvedores e equipes devem compreender a opção de ambientes de desenvolvimento disponíveis para eles. A Figura 1 mostra o ambiente de desenvolvimento e a mistura de ferramenta e inclui os tipos de soluções que podem ser implantados para os ambientes de destino.
Figura 1. Ferramentas e componentes do ambiente de desenvolvimento
[
Filosofia do ambiente de desenvolvimento
Devido aos investimentos feitos no modo como os aplicativos podem ser criados e implementados usando SharePoint, os desenvolvedores devem determinar se existe a necessidade de conduzir desenvolvimento usando código do lado do servidor. Como os desenvolvedores criar aplicativos que usam o modelo de hospedado em nuvem, o requisito de conduzir desenvolvimento que se baseia em ambientes virtualizados, especificamente para SharePoint, diminui. Os desenvolvedores devem procurar desenvolver soluções com o modelo de desenvolvimento remoto que usa existente baseado em nuvem infra-estrutura (pública e particular). Se os ambientes de desenvolvimento podem ser provisionados de modo rápido e fácil sem ter que criar e orquestram virtualização, os desenvolvedores podem investir mais tempo concentrando-se na produtividade de desenvolvimento e qualidade, em vez de gerenciamento de infra-estrutura.
A decisão de exigir uma instância virtualizada do SharePoint versus o novo modelo de site de desenvolvimento SharePoint dependerá do fato de o aplicativo exigir ou não que o código de confiança total seja implantado no SharePoint e nele executado. Se nenhum código de confiança total for necessário, é recomendável usar o desenvolvedor do modelo de site, que pode ser encontrado em Office 365 inquilinos de desenvolvimento ou dentro de implementação de uma organização do local SharePoint. Modelos de site de desenvolvedor projetados para os desenvolvedores implantar aplicativos diretamente para SharePoint de Visual Studio. sites de desenvolvedor Office 365 são pré-configurados para isolamento de aplicativo e OAuth para que os desenvolvedores podem começar a escrever e testes de aplicativos imediatamente.
As seções a seguir descrevem detalhadamente quando os desenvolvedores podem usar as opções de ambiente diferente a criação de aplicativos.
Sites de desenvolvimento do O365 (nuvem pública)
Figura 2 mostra como os desenvolvedores podem usar Office 365 como um ambiente de desenvolvimento e inclui os tipos de ferramentas produzir SharePoint aplicativos que podem ser hospedados em Office 365.
Figura 2. Desenvolvimento de aplicativos do Office 365
[
Os desenvolvedores com assinaturas do MSDN podem obter um locatário de desenvolvimento que contenha um site de desenvolvedor do SharePoint. The SharePointSite do Desenvolvedor is preconfigured for developing applications. Users can use not only Visual Studio 2012 in developing applications, but with Office 365 developer sites, Napa can be used within the site to construct applications. Para saber mais sobre como aprender a usar um site de desenvolvedor do Office 365, confira Configurar um ambiente de desenvolvimento para Suplementos do SharePoint no Office 365.
Os desenvolvedores podem começar a criar aplicativos que serão hospedados no Office 365, local ou em outra infra-estrutura em um modelo hospedados pelo provedor. O benefício desse ambiente é que a infra-estrutura, virtualização e outras considerações de hospedagem para um ambiente de desenvolvimento do SharePoint são extraídas pela Office 365, permitindo que os desenvolvedores criem aplicativos instantaneamente. Uma consideração principal para esse tipo de ambiente de desenvolvimento é que não podem ser acomodados em aplicativos que exigem o código de confiança total seja implantado emSharePoint. Microsoft recomenda usando o modelo de objeto do cliente de SharePoint (CSOM) e tecnologias do lado do cliente comoJavaScript tanto quanto possível. Que código de confiança total é necessário (mas não é necessária a implantação do código para executar em SharePoint ), é recomendável implantar o código do lado do servidor em uma auto-hospedados ou modelo hospedado em provedor. Observe que essas soluções de código de confiança total que são implantadas em infraestrutura hospedado em provedor também usam o CSOM mas podem usar linguagens como c#. Também é importante observar que esses aplicativos implantados em um modelo hospedado em provedor podem usar outras pilhas de tecnologia e ainda usar o CSOM para interagir com o SharePoint.
As equipes de desenvolvimento criando recursos separados ou aplicativos que contenham uma solução maior precisa um destino de implantação centralizada para integração testará componentes. Como cada desenvolvedor está criando recursos ou aplicativos em seu próprio site de desenvolvedor Office 365, um conjunto de sites centralizado em um ambiente de locatário ou no local de destino deve ser provisionado para que os componentes do aplicativo de cada desenvolvedor podem ser implantados lá. Essa abordagem permitirá que para um local centralizado para conduzir testes entre os componentes da solução de integração. O teste seção deste documento analisa esse processo em mais detalhes.
Sites de desenvolvimento (desenvolvimento remoto)
Para organizações ou desenvolvedores que não queiram usar sites de desenvolvedor Office 365 como o principal meio para o desenvolvimento de aplicativos SharePoint, os sites de desenvolvedor do local podem ser usados para desenvolver aplicativos SharePoint. Nesse modelo, o recurso dos sites de desenvolvedor Office 365 é substituído pelo desenvolvedor local sites hospedados em um farm de SharePoint. Os clientes podem criar uma nuvem privada de desenvolvimento com a implantação de um farm SharePoint para instâncias de site de desenvolvedor house. Os clientes podem fornecer sua própria automação de governança para fornecer criação do modelo de site de desenvolvedor ou usar os recursos do produto de SharePoint para provisionar instâncias de site do desenvolvedor. A Figura 3 ilustra este arquivo de instalação.
Figura 3. Desenvolvimento de aplicativo de local com o modelo de site do desenvolvedor
[
Figura 3 descreve as ferramentas de desenvolvimento e os tipos de aplicativos que podem ser habilitados com sites de desenvolvedor ao usar um farm do SharePoint local como um host. Observe que as ferramentas de desenvolvimento do NapaOffice 365 não podem ser usadas nesse ambiente como são um recurso presente apenas em sites de desenvolvimento Office 365.
SharePoint farm que hospeda as instâncias de Site do Desenvolvedor devem ser monitoradas e reunir service e recuperação tempo níveis objetivos de ponto e para que os desenvolvedores que dependem delas para criar aplicativos podem ser produtivos e não a experiência de interrupções. Os clientes podem aplicar uma malha de gerenciamento e conceitos de nuvem privada, como elasticidade e unidades de escala para este ambiente. Operações e gerenciamento precisam ser aplicada ao farm SharePoint onde os sites de desenvolvedor hospedados também. Isso ajudará a controlar não monitorada proliferação de vários sites para desenvolvedores que estão obsoletas ou não usadas e fornecem uma maneira de entender quando o ambiente tiver a escala.
Os clientes podem optar por usar a infraestrutura como um recursos de serviço (IaaS), como Microsoft Azure para hospedar os farms deSharePoint que contêm e hospedar sites de desenvolvedor ou seus próprios ambientes virtuais ou físicos do local. Observe que usando esse modelo não exigem uma instalação SharePoint para cada desenvolvedor. O desenvolvimento de aplicativos remotos somente exigirá Visual Studio e ferramentas de desenvolvimento do Office e SharePoint na estação de trabalho de desenvolvedor.
Os desenvolvedores devem estabelecer infra-estrutura hospedado em provedor para implantar os aplicativos hospedados pelo provedor. Embora hospedado em provedor componentes de um aplicativo de SharePoint podem ser implementados em uma matriz de toda a das tecnologias, os desenvolvedores devem fornecer uma infra-estrutura para hospedar os componentes do aplicativo que executam externo SharePoint. Por exemplo, se uma equipe é desenvolver um aplicativo SharePoint cuja experiência do usuário e outros componentes que residem em um aplicativo deASP.NET, a equipe de desenvolvimento deve usar versões locais do IIS,SQL Server, e assim por diante prenda em padrões de desenvolvimento de equipe ALM tradicionais para ASP.NET.
Ambientes de farm independentes (desenvolvimento de farm virtualizado)
Para as soluções que exigem que a implantação do código de confiança total sejam executadas em um farm do SharePoint, será necessária uma implementação completa do SharePoint (geralmente virtualizada). For guidance on how to create an on-premises development environment for SharePoint, see Configurar um ambiente de desenvolvimento local para suplementos do SharePoint.
Figura 4 mostra os tipos de aplicativos que podem ser criados usando um ambiente virtualizado do local.
Figura 4. Desenvolvimento de local com um ambiente virtual
[
Os desenvolvedores podem conduzir desenvolvimento remoto para o SharePoint e aplicativos hospedados em nuvem em suas próprias farms SharePoint, bem como o desenvolvimento de confiança total soluções de farm. Nesses farms frequentemente são hospedados em um servidor de virtualização executando na estação de trabalho do desenvolvedor ou em uma nuvem privada virtualização centralizado que pode ser facilmente acessível para os desenvolvedores. O ambiente de farm SharePoint é geralmente separado de farms de outros desenvolvedores e fornece um nível de isolamento que é necessário ao desenvolvimento de código de confiança total que pode exigir a reinicialização dos serviços críticos (ou seja, IIS).
Desenvolvimento remoto pode ocorrer dentro do farm independente, bem como o desenvolvimento de completo código de confiança, conforme cada farm de desenvolvimento é isolada e dedicada a um desenvolvedor única.
Organizações ou desenvolvedores terão que gerenciar e atualizar os farms SharePoint executados nos computadores virtuais. Para os desenvolvedores que estão contribuindo para um único aplicativo, paridade entre os farms de desenvolvimento executando dentro os computadores virtuais deve ser mantida. Essa prática garante que cada componente de código desenvolvido para o aplicativo tem consistência. Outras considerações comuns são uma configuração padrão para os farms, incluindo o acesso ao domínio e credenciais, credenciais do aplicativo de serviço, teste as identidades ou contas e outros elementos de configuração ambientais (por exemplo, certificados).
Semelhante a um farm centralizado para sites de desenvolvimento, essas máquinas virtuais executando developerSharePoint farms podem ser hospedadas em plataformas IaaS, como Microsoft Azure e ofertas de nuvem privada local.
Observe que, embora as máquinas virtuais oferecer uma grande quantidade de isolamento e independência das outras máquinas virtuais de desenvolvedor, equipes devem buscar ter uniformidade entre as configurações de máquina virtual. Isso inclui o domínio comum, conta e segurança, as configurações de SharePoint e uma conexão com um repositório de controle de origem, como Visual Studio Team Foundation Server (TFS).
Considerações de projeto de ALM
Ao construir aplicativos SharePoint, há várias considerações que devem ser atendidos para fornecer a governança e práticas recomendadas de desenvolvimento comuns para consistência e a qualidade. Ao aplicar princípios ALM ao desenvolvimento de aplicativos SharePoint, os desenvolvedores devem focalizar considerações técnicas, bem como considerações orientado no processo.
O suporte de uma plataforma ALM, como Visual Studio Team Foundation Server 2012, geralmente é um requisito ao conduzir o desenvolvimento de aplicativos, especialmente com equipes de desenvolvedores que trabalham no mesmo conjunto de projetos. aplicativos SharePoint, como outras soluções técnicas, exigem o controle de versão e gerenciamento de repositório de código, construir serviços, teste de serviços e práticas de gerenciamento de versão. A seção a seguir descreve as considerações para ALM conforme aplicado aos modelos de aplicativos diferente para SharePoint aplicativos.
Visão geral
Para cada tipo de aplicativo SharePoint, as considerações de ALM devem ser aplicadas sem variação em conceito. No entanto, práticas recomendadas e os procedimentos em torno de compilação, teste e gerenciamento de alteração devem ser ajustados.
Alguns aplicativos SharePoint irá usar tecnologias de cliente. A maioria dos desenvolvedores que têm a experiência de desenvolvimento de aplicativo SharePoint Server 2010 terão ajuste para o desenvolvimento e a aplicação de princípios ALM ao código não compilada. Esse ajuste inclui a aplicação de conceitos, como "compilação" a uma solução que pode não ter código compilado. Plataformas ALM como Visual Studio 2012 têm recursos internos para validar compilações pela primeira o código de compilação e, em segundo lugar, executando compilação verificação testa (BVTs) contra a compilação.
Para aplicativos de SharePoint, o processo relacionadas para criar e testar deve permanecer consistente com processos de desenvolvimento de aplicativos tradicional. Isso inclui a criação de uma agenda de compilação pela plataforma ALM, que será compilar a solução e implantá-lo no ambiente de destino.
Processos de build
Os processos de compilação do aplicativo SharePoint são facilitados pela plataforma ALM. Visual Studio Team Foundation Server 2012 fornece ambos compilar e testar os serviços que podem ser disparados na solução de check-in do Visual Studio 2012 (integração contínua) ou em especificados intervalos programados.
Componentes de build do SharePoint
Ao planejar os processos de criação para o desenvolvimento de aplicativos SharePoint, os desenvolvedores deve considerar as interações entre os componentes, conforme mostrado na Figura 5.
Figura 5. Componentes de compilação do aplicativo hospedado no SharePoint
A ilustração na Figura 5 é uma representação lógica de um aplicativo de SharePoint. Esta ilustração mostra uma suplemento hospedado no SharePoint e destaca os objetos de chave de aplicativo como parte de um projeto desuplemento hospedado no SharePointVisual Studio 2012. O projeto de aplicativo SharePoint contém os recursos, o pacote e o manifesto que será registrado com SharePoint. O projeto também contém páginas, bibliotecas de scripts e outros elementos da experiência do usuário que constituem o aplicativo SharePoint. Além disso, o projeto SharePoint tem os arquivos que incluem os certificados necessários para implantação em um ambiente de destino SharePoint de suporte.
Figura 6. Hospedado em provedor e aplicativos auto-hospedados compilar componentes
Figure 6 shows a SharePoint cloud-hosted application (that is, autohosted or provider-hosted). The main difference in the project structure is that the Visual Studio 2012 solution contains a SharePoint application project in addition to one or more projects that contain the cloud-hosted application components. These may include web applications, SQL database projects, or service applications that will be deployed to Azure or an on-premises provider hosted infrastructure (such as ASP.NET) and other solution components. For guidance on packaging and deployment with high-trust applications, see Embalar e publicar Add-ins do SharePoint de alta confiança.
Figura 7. ALM com o Visual Studio Team Foundation Server
Figura 7 mostra o TFS como plataforma de ALM. As equipes usará o TFS para armazenar o código e conduzir o desenvolvimento de equipe usando o TFS implantados no local ou usando serviços TFS baseado em nuvem da Microsoft. TFS podem ser configurados para conduzir a compilação e atividades de implantação com um aplicativo de SharePoint por meio de criar definições. TFS também pode ser usado para conduzir testes de verificação da compilação (BVTs) que podem ser automatizados por meio da execução de testes de UI codificados que fazem parte da definição de compilação.
Figura 8. Destinos de compilação do TFS
Figura 8 mostra os ambientes de destino onde os scripts executados por uma definição de compilação do TFS implantará os componentes do aplicativo SharePoint. Para aplicativos hospedados pelo SharePoint isso inclui a implantação para qualquer um dos SharePoint Online ou catálogos de aplicativos SharePoint local.
Para aplicativos hospedados em nuvem SharePoint, os componentes da solução que requerem infraestrutura adicional fora SharePoint são implantados para ambientes de destino. Para aplicativos auto-hospedados, esse será Microsoft Azure. Para aplicativos hospedados pelo provedor, essa infra-estrutura pode ser Microsoft Azure, ou outro local ou ambientes hospedados IaaS.
Criar um build para aplicativos do SharePoint
TFS fornece serviços de compilação que podem compilar soluções marcadas para controle do código-fonte e coloque a saída em um local centralizado projetada para implantação nos ambientes de destino de maneira automática. O principal método de configurar o TFS conduzir automatizado cria, implantações, e teste de aplicativos SharePoint é criar uma definição de compilação no Visual Studio. A definição de compilação contém informações sobre qual código projetos para compilar, bem como todas as atividades de pós-compilação como real e teste de implantação para os ambientes de destino. Para obter mais informações sobre o Team Foundation Build Service, consulte Configurar Team Foundation Build Service.
Para obter a integração contínua, a definição de compilação pode ser acionada quando os desenvolvedores verificam no código. Além disso, a definição de compilação pode ser agendada para execução em intervalos definidos.
Quanto aos aplicativos do SharePoint, os desenvolvedores devem usar o projeto de definições de criação Integração Contínua do Office/SharePoint com o TFS 2012 para obter criações programados ou integração contínua. Esse projeto fornece definições de build, scripts do Windows PowerShell e instruções de processo sobre como configurar Visual Studio Team Services ou uma versão local do TFS para compilar e implantar aplicativos do SharePoint em um modelo de integração contínua. Os desenvolvedores devem baixar os componentes desse projeto e configurar a instância do TFS adequada. Para obter instruções sobre como configurar o TFS com a definição de build fornecida para aplicativos do SharePoint e configurar a definição de build para usar os scripts do Windows PowerShell para implantar o aplicativo do SharePoint em um ambiente de destino, confira a documentação Integração contínua de Office/SharePoint com o TFS 2012.
Configurar os procedimentos de build e implantação
Figura 9 mostra um processo padrão para o aplicativo SharePoint baseia-se e implantações quando a definição de compilação tiver sido criada, configurado e implantado instância da equipe do TFS.
Figura 9. Processo de compilação e implantação com o TFS
[
Verifica se o desenvolvedor da solução de Visual Studio 2012SharePoint aplicativo. Dependendo da configuração desejada (ou seja, a integração contínua ou compilação agendada), serviços de compilação do TFS executará as etapas definidas pela definição da compilação SharePoint aplicativos. Esta definição, configurada pelos desenvolvedores, contém o modelo de processo de compilação de integração contínua, assim como as instruções de pós-compilação para executar scripts Windows PowerShell implantação de aplicativos. Observe que as extensões do Shell de gerenciamento de SharePoint Online serão necessária para implantar o aplicativo SharePoint Online. Para obter mais informações sobre as extensões do Shell de gerenciamento de SharePoint Online, consulte a página do SharePoint Online Management Shell no Centro de Download.
Depois que a compilação tiver sido disparada, TFS irá compilar os projetos associados ao aplicativo SharePoint e executar scripts de Windows PowerShell para implantar a solução para o ambiente de destino SharePoint.
Confiar no aplicativo de SharePoint
Após a implantação dos componentes do aplicativo para os ambientes de destino, é importante observar que antes que qualquer pessoa acesse o aplicativo, incluindo testes automatizados que podem ser parte da compilação, um locatário (ou conjunto de sites) administrador precisarão confiar no aplicativo na página de informações do aplicativo no SharePoint. Esse requisito se aplica aos aplicativos auto-hospedados e SharePoint - aplicativos hospedados. Esse processo manual representa uma alteração no processo de criação como testes que normalmente seriam execute o seguinte que implantação para o ambiente de destino terão a ser suspenso até que o aplicativo é confiável.
Observe que para aplicativos (automático e provedor) hospedado em nuvem, desenvolvedores podem implantar os componentes de não -SharePoint à infraestrutura de hospedado em nuvem separadamente do pacote de aplicativo que é implantado em SharePoint.
Figura 10. Implantação de componentes de não-SharePoint
[
Conforme mostrado na Figura 10, quando os desenvolvedores faz alterações à solução que representa o aplicativo SharePoint, pode haver circunstâncias onde as alterações são feitas aos projetos dentro da solução que não se aplicam ao projeto de aplicativoSharePoint em si. Neste caso, o projeto de aplicativo SharePoint não tem a serem reimplantadas conforme não tiver sido alterado. Devem ser reimplantadas as alterações associadas aos projetos hospedados em nuvem.
Alterações ao aplicativo que será implantado à infraestrutura fora SharePoint podem ser feitas isso separadamente dos componentes de aplicativos e são implantados no conjunto de sites de destino ou locatário. Para os desenvolvedores, isso significa que um processo de compilação automatizada pode ser criado para implantar os componentes com freqüência (disparado) e separadamente do projeto SharePoint aplicativo hospedado em nuvem. Assim, a etapa manual para aprovar a permissão do aplicativo na página de informações do aplicativo no SharePoint não será necessária, permitindo uma implantação mais contínua e testar o processo para a definição de compilação. O componente do aplicativo SharePoint da solução só precisa ser implantado em uma circunstância foram os itens dentro dessa project alteradas e necessário reimplantação.
Testar
Conforme descrito na seção processos de criação, testes de aplicativos é um método para determinar se a compilação e a implantação do aplicativo foi bem-sucedida. Usando o teste como um meio de Verificando a compilação e a implantação do aplicativo, a equipe é fornecida com uma compreensão do qualidade, bem como uma maneira de conhecer quando uma recente alteração para o código do aplicativo tiver comprometida o aplicativo SharePoint.
Figura 11 mostra os tipos de abordagens melhor usados com o SharePoint modelos de aplicativo de teste.
Figura 11. Abordagens de teste
[
Figura 11 sugere o uso de diferentes tipos de testes para aplicativos SharePoint por tipo de teste. Testes de UI codificados devem ser usados contra SharePoint-onde a lógica de negócios e a experiência do usuário residem na mesma camada de aplicativos hospedados. Enquanto a lógica de negócios pode ser extraída em bibliotecas de JavaScript, o principal meio de teste essa lógica será por meio da experiência do usuário.
Aplicativos hospedados em nuvem (isto é, auto-hospedados e hospedados pelo provedor) podem usar os testes de UI totalmente codificados durante a utilização também testes de unidade para a verificação dos componentes do serviço da solução. Isso oferece confiança de desenvolvedor na qualidade de implementação de infra-estrutura hospedada do aplicativo de uma perspectiva funcional.
As seções a seguir examinar as considerações para testes de UI codificados e outros tipos de teste em relação à SharePoint aplicativos.
Testes de UI codificados e código do lado do cliente
Para teste (BVT), bem como o sistema completo testes de verificação de compilação, testes de UI codificados são recomendados. Esses testes contam com as ações registradas para testar não apenas a lógica de negócios e de camada intermediária de aplicativo, mas a experiência do usuário. Para aplicativos de SharePoint que usam o código do lado do cliente, grande parte dos pontos de entrada e a execução a lógica de negócios pode existir na camada de experiência do usuário. Por esse motivo, testes de UI codificados não podem testar apenas a experiência do usuário, mas a lógica de negócios do aplicativo também. Para obter mais informações sobre o teste UI codificado, consulte Verificando código pelo usando automação de interface do usuário.
Testes de UI codificados podem ser usados em suplemento hospedado no SharePoint s onde grande parte do eu e a lógica de negócios pode ser combinada. Estes testes, como outros podem ser executados a partir de uma definição de compilação no TFS para que eles podem verificar a funcionalidade de um aplicativo após a implantação (e o aplicativo é confiável pelo SharePoint ).
Testes de UI não codificados
Para circunstâncias onde a lógica do aplicativo existe fora da camada de eu do aplicativo, como em aplicativos hospedados em nuvem, uma combinação de testes de UI codificados e testes de UI codificados não deve ser aproveitada. Testes, como testes de unidade tradicional podem ser usados para validar a qualidade de compilação da lógica de serviço que é implementada em uma infra-estrutura hospedados pelo provedor. Isso fornece o desenvolvedor com uma confiança abrangente nos componentes hospedado em provedor da função solução e são abordados do ponto de vista teste.
Testes de carga e desempenho da Web
Testes de desempenho e a carga da Web oferecem aos desenvolvedores a certeza de que o aplicativo funciona sob cargas de usuário esperado ou previstos. Esse teste inclui determinando a capacidade do aplicativo simultaneamente lidar com uma base de usuários previsível que será escalado razoavelmente ao longo do tempo. Ambos codificada UI e testes de unidade podem ser a origem do desempenho da web e teste de carga. Usando uma plataforma ALM como o TFS, esses testes podem ser usados para carregar o aplicativo de teste.
Observe que o teste da infra-estrutura não é dos principais objetivos desses testes quando usá-los para testar SharePoint aplicativos. A infraestrutura, se SharePoint-hospedados ou hospedado em provedor, deve ter uma semelhante carga e desempenho da linha de base estabelecida. Os testes de carga e desempenho de web para o aplicativo irão destacar os desafios de infra-estrutura, mas devem ser considerados principalmente como um meio para testar o desempenho do aplicativo.
Para obter mais informações sobre os testes de desempenho e a carga da web, consulte executar testes de desempenho em um aplicativo antes de uma versão.
Ambientes de qualidade e de testes
Muitas organizações têm vários ambientes de testes que podem ser físicos, ou virtual e separados uns dos outros. Esses ambientes podem variar com base no processo ALM da equipe, os requisitos normativos ou uma combinação de ambos. Para determinar o número e tipos de ambientes de testes que equipes devem usar, as orientações a seguir baseia-se nas práticas funcionais específicas de aplicativos SharePoint, mas também usa ALM práticas para desenvolvimento de software em grandes.
Testes para desenvolvedores
Teste do desenvolvedor pode ocorrer no ambiente onde os desenvolvedores estiver criando seus componentes da solução. Vários desenvolvedores, trabalhando em diferentes aspectos ou componentes de um aplicativo maior, cada um terá testes de unidade, testes de UI codificados e implantadas em seu site de desenvolvimento de código do aplicativo.
Figura 12. Processo de teste do desenvolvedor
[
Os desenvolvedores executará testes de Visual Studio contra os componentes da solução implantada em seu próprio site de desenvolvedor Office 365 ou local. Para aplicativos hospedados em nuvem, os testes também serão executados em Visual Studio contra os componentes da solução que residem em infra-estrutura hospedados pelo provedor. Esses componentes residem em uma assinatura Microsoft Azure do desenvolvedor.
Observe que essa abordagem presume que os desenvolvedores têm ou sites de desenvolvedor individuais Office 365 e inscrições de Microsoft Azure, que são fornecidas por meio de assinaturas do MSDN. Mesmo que os desenvolvedores estão criando aplicativos para implantação no local, esses serviços de desenvolvedor podem ser usados para desenvolvimento e teste.
Se os desenvolvedores não têm esses serviços ou são necessárias para fazer desenvolvimento inteiramente no local, então executará testes para seus componentes contra o conjunto de sites para desenvolvedores e infraestrutura de desenvolvedor específicos, hospedado em provedor de um farm de local. A infraestrutura hospedado em provedor pode residir em máquinas virtuais do desenvolvedor dedicados. Para o desenvolvimento de soluções de confiança total, os desenvolvedores exigiria seu próprio farm virtual do SharePoint e a infraestrutura hospedados pelo provedor.
Testes de integração e de sistemas
Para testar o aplicativo, todos os componentes de desenvolvimento devem ser montados e implantados em um ambiente centralizado. Esse ambiente de integração fornece um local onde os desenvolvedores podem implantar e observe os componentes da solução criaram interação com outros componentes de solução escritos por outros desenvolvedores.
Figura 13. Ambiente de testes de integração
[
Para esse tipo de teste, a plataforma de ALM compilará e implementará o aplicativo do SharePoint e todos os componentes necessários para os ambientes de destino. Para aplicativos hospedados no SharePoint, isso será um site do Office 365 ou um conjunto de sites do SharePoint IaaS/local estabelecido especificamente para teste de integração e de sistemas. Para aplicativos hospedados em nuvem do SharePoint, TFS também implantará os componentes em uma assinatura centralizado Microsoft Azure onde os serviços serão configurados especificamente para testes de integração/sistemas. TFS, em seguida, executará testes de interface do usuário ou unidade codificados contra o aplicativo SharePoint, bem como quaisquer componentes que exige a solução em infra-estrutura hospedada.
Teste de QA (controle de qualidade) e UAT (teste de aceitação de usuário)
Para (UAT) de teste de aceitação do usuário, as organizações geralmente têm ambientes separados onde essa função é executada, além da integração e teste dos sistemas. Separar esses ambientes de testes impede a cadência automatizado versão contínua e testar interfira com atividades UAT onde os usuários podem executar testes contra uma compilação especificada do aplicativo durante um longo período de tempo.
Figura 14. Teste de UAT
[
Conforme mostrado na Figura 14, os usuários atribuídos a conduzir o teste de aceitação ou recursos de teste organizacionais conduzir scripts de teste em um ambiente estável que se concentra em uma compilação bem divulgada do aplicativo. Enquanto a implantação de código e o teste continua no ambiente de integração, os usuários conduzirá testes manuais para validar que o aplicativo atenda uso necessário ou casos de teste. O aplicativo e qualquer infra-estrutura hospedado em provedor serão implantados, geralmente por um gerente de lançamento, neste ambiente de teste. Uma implantação automatizada também é possível. Esse tipo de implantação usa uma definição de compilação UAT dedicada no TFS que espelha aquela conduz implantação para integração e teste o ambiente de sistemas.
Para hospedado em nuvem de infra-estrutura, implantação em uma assinatura de Microsoft Azure que é compartilhada com os ambientes de teste de integração e os sistemas é possível se os serviços foram nomeados e configurados para serem implantados lado a lado, como serviços diferentes ou bancos de dados. Essa abordagem oferece um conjunto de serviços e bancos de dados em testes de assinatura Microsoft Azure para integração e teste dos sistemas, bem como UAT e controle de qualidade de teste, conforme mostrado na Figura 15.
Figura 15. Integração e teste de UAT
[
Práticas de promoção de código
O processo de promoção de código entre o desenvolvimento e ambientes de testes, bem como o ambiente de produção deve ser feito usando um processo de gerenciamento de versão bem definida. Na Figura 16, desenvolvedores realizam a implantação de seus componentes de solução para ambientes de desenvolvimento para testes de unidade.
Figura 16. Processo de gerenciamento de versão
[
Após o check-in para TFS, um procedimento de compilação automatizada irá compilar e implantar a solução para a integração de destino e o sistema onde os testes de verificação de compilação serão executados como parte da definição de compilação no TFS do ambiente de teste. Essa abordagem inclui a implantação de componentes da solução hospedado em provedor para o ambiente de destino (ambientes locais ouMicrosoft Azure ). Observe que para a infra-estrutura de Microsoft Azure, a assinatura de Microsoft Azure pode ser o mesmo usado para integração e teste do sistema, bem como UAT e controle de qualidade supondo que eles sejam implantados bancos de dados SQL separados e namespaces de diferentes.
Um gerente de lançamento ou uma definição de compilação TFS separada, chamado manualmente na maioria dos casos, poderá ser implantado para o ambiente UA ou TQA. Essa abordagem ajuda a controlar a versão de compilação que estará testando contra usuários. Gerentes de versão podem pegue as compilações de um compartilhamento de TFS e execute o processo de implantação sozinhos. Seja promovido para a produção, de gerenciamento de liberação será envolvido para implantar o aplicativo para o ambiente de produção e monitorar sua instalação e construir a verificação por meio de testes.
Atualizações e aplicação de patch
A Microsoft tem orientação específica sobre como os desenvolvedores de aplicativos podem atualizar aplicativos. A plataforma do SharePoint oferece suporte à notificação de novas versões de aplicativo aos usuários.
For considerations on establishing a strategy around SharePoint application upgrades and patching, see Suplementos de atualização para o SharePoint.
Para alterações aos aplicativos, siga o padrão recomendado é consistente com o desenvolvimento de código existente e os padrões de engenharia sustentadas. Isso inclui disciplinado ramificação e a mesclagem para correções de erros e desenvolvimento de recurso, bem como implantações incrementais aos catálogos de aplicativo de destino. As orientações anterior podem ser usada para concluir as alterações nos aplicativos para SharePoint e implante-los aos catálogos de aplicativo de destino ou o repositório.
The information in Processo de atualização de suplementos do SharePoint provides additional tactical guidance on the techniques for updating SharePoint applications. This includes accelerating deployment testing by shortening the cycle by which application updates are reflected in the farm in test environments. Additionally, this article has guidance on how to accommodate for state within various application deployment models.