Desenvolvimento em equipe na Estrutura do SharePoint

O SharePoint Framework é um novo modelo de desenvolvimento para a criação de personalizações do SharePoint. Ao contrário de outros modelos de desenvolvimento do SharePoint disponíveis até o momento, o Estrutura do SharePoint se concentra no desenvolvimento do lado do cliente e é criado em cima de ferramentas populares de código aberto, como Gulp e Webpack. Um grande benefício dessa alteração é que os desenvolvedores em qualquer plataforma podem criar personalizações do SharePoint.

A Estrutura do SharePoint é um modelo de desenvolvimento e, apesar das diferenças na tecnologia subjacente, os mesmos conceitos se aplicam ao usá-la na criação de soluções, como ocorre em outros modelos de desenvolvimento que os desenvolvedores do SharePoint usavam no passado. Os desenvolvedores usam a cadeia de ferramentas da Estrutura do SharePoint para criar e testar soluções e, quando elas estão prontas, eles fornecem o pacote de soluções a ser implantado no locatário do SharePoint para mais testes e o lançamento.

A Estrutura do SharePoint consiste em alguns pacotes diferentes. Esses pacotes, cada um em sua própria versão específica, compõem uma versão da Estrutura do SharePoint. Por exemplo, a versão de Disponibilidade Geral da Estrutura do SharePoint em fevereiro de 2017 consiste nas seguintes versões de pacote v1.0.0:

• @microsoft/sp-client-base
• @microsoft/sp-core-library
• @microsoft/sp-webpart-base
• @microsoft/sp-build-web
• @microsoft/sp-module-interfaces
• @microsoft/sp-webpart-workbench

Para que um projeto direcione uma versão específica da Estrutura do SharePoint, precisa fazer referência a todos os diferentes pacotes nas versões corretas. Ao incluir estruturação nos novos projetos, o gerador do Yeoman da Estrutura do SharePoint adiciona automaticamente as referências necessárias ao pacote da versão correspondente da Estrutura do SharePoint. Porém, após a atualização do projeto para uma versão mais recente da Estrutura do SharePoint, os desenvolvedores precisam prestar atenção especial para atualizar corretamente os números de versão dos pacotes da Estrutura do SharePoint.

Preparação do ambiente de desenvolvimento

Para criar desenvolvedores de soluções Estrutura do SharePoint, precisa de ferramentas específicas nos computadores de desenvolvimento. Em comparação a outros modelos de desenvolvimento do SharePoint, o SharePoint Framework é menos restritivo e permite que os desenvolvedores usem as ferramentas que os tornam mais produtivos, podendo até escolher o sistema operacional.

Existem algumas maneiras diferentes para que os desenvolvedores configurem o ambiente de desenvolvimento. Cada uma delas tem diferentes vantagens, e é importante que as equipes de desenvolvedores tenham um bom entendimento das diferentes opções.

Cadeia de ferramentas da Estrutura do SharePoint

A criação de soluções do SharePoint Framework requer que os desenvolvedores usem determinado conjunto de ferramentas. A lista a seguir explica o conjunto de ferramentas básico necessário em cada ambiente de desenvolvimento do SharePoint Framework.

Node.js

O SharePoint Framework requer que o Node.js seja instalado na máquina do desenvolvedor. O Node.js é usado como o tempo de execução para ferramentas de tempo de design usadas para compilar e empacotar o projeto. Node.js é instalado globalmente no computador do desenvolvedor e há soluções disponíveis para dar suporte à execução de várias versões de Node.js lado a lado, se necessário.

Para mais informações, confira Configurar o ambiente de desenvolvimento da Estrutura do SharePoint

NPM

O npm é o equivalente ao NuGet em projetos do .NET: ele permite que os desenvolvedores adquiram e instalem pacotes para uso em projetos da Estrutura do SharePoint. O Npm também é usado para instalar a cadeia de ferramentas da Estrutura do SharePoint. Normalmente, os desenvolvedores usarão a última versão do npm e a instalarão lo globalmente em sua máquina. O npm em si é um pacote do Node.js. Portanto, se você estiver executando várias versões do Node.js lado a lado, cada uma delas terá sua própria versão do npm instalada.

Gulp

O Gulp é o equivalente ao MSBuild no projeto .NET e é responsável por executar tarefas como criar ou empacotar um projeto Estrutura do SharePoint. O Gulp é distribuído como um pacote Node.js e normalmente é instalado globalmente usando npm.

Yeoman e gerador do Yeoman da Estrutura do SharePoint

Usando o Yeoman e o gerador do Yeoman do SharePoint Framework, os desenvolvedores criam novos projetos do SharePoint Framework. O Yeoman e seus geradores são distribuídos como pacotes do Node.js e, geralmente, são instalados usando o npm como pacotes globais. O benefício de uma instalação global é que os desenvolvedores podem instalar o Yeoman e os geradores uma vez e usá-los para criar facilmente novos projetos.

O gerador do Yeoman do SharePoint Framework está vinculado a uma versão específica do SharePoint Framework. Os projetos com scaffolding usando o gerador fazem referência às versões específicas dos pacotes do SharePoint Framework, e as Web parts geradas fazem referência às partes específicas da estrutura. O gerador do Yeoman do SharePoint Framework é usado para criar novos projetos, mas também para adicionar Web parts a projetos existentes. Se você instalá-lo globalmente e tiver que adicionar uma nova Web Part a um projeto existente criado no passado, a Web Part recém-criada pode ser inconsistente com o restante do projeto que pode até levar a erros de build. Há várias maneiras pelas quais você pode contornar essa limitação, que este artigo discute posteriormente.

TypeScript

O SharePoint Framework usa o TypeScript para ajudar os desenvolvedores a serem mais produtivos escrevendo código melhor e detectando os erros durante o desenvolvimento. Estrutura do SharePoint projetos são enviados com sua própria versão do TypeScript, que é usada no processo de build e que não exige que os desenvolvedores o instalem separadamente.

Criação de um ambiente de desenvolvimento da Estrutura do SharePoint

No passado, normalmente os desenvolvedores do SharePoint usavam máquinas virtuais como seus ambientes de desenvolvimento. As máquinas virtuais permitiam que eles garantissem que a solução que estavam criando funcionasse no ambiente usado pela organização específica. Nas máquinas virtuais, os desenvolvedores instalavam o SharePoint e instalavam patches do mesmo nível que o ambiente de produção usado pela organização específica. Em alguns casos, eles instalariam software adicional para corresponder ao ambiente de destino em que a solução seria executada o mais próximo possível. Essa abordagem permitia que os desenvolvedores detectassem antecipadamente erros causados pela diferença de ambiente, acarretando porém maior complexidade e exigindo o gerenciamento dos ambientes diferentes.

A mudança do desenvolvimento de soluções para a nuvem resolveu apenas parcialmente esses problemas. Embora os desenvolvedores não precisassem mais executar um Farm do SharePoint nos computadores de desenvolvimento, tinham que levar em conta como a solução seria hospedada e como se comunicaria com o SharePoint Online.

Como Estrutura do SharePoint se concentra no desenvolvimento do lado do cliente, ele não exige mais que o SharePoint seja instalado nos computadores de desenvolvimento. Com poucas exceções, todas as dependências para a estrutura e outros pacotes são especificadas no projeto e contidas na pasta do projeto. Como o Estrutura do SharePoint tem suas origens na nuvem e evolui com frequência, os desenvolvedores devem garantir que estejam usando a versão correta do conjunto de ferramentas correspondente ao seu projeto de Estrutura do SharePoint.

Ambiente de desenvolvimento compartilhado ou pessoal

As personalizações do SharePoint variam desde scripts simples adicionados diretamente à página até soluções sofisticadas implantadas como pacotes de soluções. O SharePoint Framework é um modelo de desenvolvimento direcionado para o modelo de implantação estruturado e repetível de personalizações do SharePoint. Ao criar soluções do SharePoint Framework, cada desenvolvedor da equipe usa seu próprio ambiente de desenvolvimento e compartilha o código-fonte do projeto com outros desenvolvedores da equipe por meio de um sistema de controle de código-fonte. Dessa forma, os desenvolvedores podem trabalhar no mesmo projeto simultaneamente e testar sua solução sem afetar a produtividade uns dos outros.

No passado, era desafiador para muitas organizações justificar o fornecimento de desenvolvedores do SharePoint com máquinas de desenvolvimento poderosas e, em alguns casos, vários desenvolvedores tiveram que compartilhar o mesmo computador ao custo de produtividade. Com o Estrutura do SharePoint, os desenvolvedores podem usar computadores desenvolvedores padrão do mercado para criar personalizações do SharePoint.

Desenvolvimento no host

Provavelmente, a opção mais fácil de configurar um ambiente de desenvolvimento para projetos Estrutura do SharePoint é instalar todas as ferramentas diretamente no computador host. Se sua equipe está trabalhando somente em projetos do SharePoint Framework, pode instalar o Node.js nos computadores. Se eles trabalharem em outros projetos Node.js, eles poderão usar soluções de terceiros, como o nvm , para executar várias versões de Node.js lado a lado.

Seguindo as ferramentas necessárias para a cadeia de ferramentas da Estrutura do SharePoint, os desenvolvedores instalariam o Yeoman e o gerador do Yeoman da Estrutura do SharePoint. Normalmente, essas duas ferramentas são instaladas globalmente. No entanto, como o gerador Yeoman da Estrutura do SharePoint está vinculado a uma versão específica da Estrutura do SharePoint, e os desenvolvedores podem precisar trabalhar com projetos criados usando uma versão diferente, eles teriam que desinstalar e instalar a versão de gerador específica para o projeto específico em que estão trabalhando no momento. Uma abordagem mais viável seria instalar o Yeoman e o gerador Yeoman da Estrutura do SharePoint localmente no projeto específico. Embora isso cause alguma sobrecarga, ajuda os desenvolvedores a garantir que, se precisarem adicionar novos elementos ao projeto no futuro, eles sejam compatíveis com o restante do projeto.

Um benefício do desenvolvimento no host é que os desenvolvedores podem configurar seu computador para suas preferências uma vez e usá-lo em todos os projetos. Além disso, à medida que o software é executado no host, ele tem acesso direto à CPU, memória e E/S de disco sem uma camada de virtualização entre as quais leva a um desempenho melhor do que ao executar o mesmo software virtualizado.

Desenvolvimento em uma máquina virtual

No passado, a abordagem mais comum entre os desenvolvedores do SharePoint era usar máquinas virtuais como seu ambiente de desenvolvimento primário para criar soluções do SharePoint. Usando máquinas virtuais, os desenvolvedores podem acomodar os diferentes requisitos dos vários projetos.

Ao criar soluções no SharePoint Framework, as organizações podem aproveitar os mesmos benefícios que usavam na criação de soluções do SharePoint no passado. Usando máquinas virtuais, eles podem isolar o software de desenvolvimento do sistema operacional host, que é um requisito comum especialmente em grandes organizações. Ao criar uma máquina virtual separada para cada desenvolvedor de projeto pode garantir que o conjunto de ferramentas, eles usem seja compatível com o projeto, mesmo que precisem pegar o projeto específico no futuro.

O uso de máquinas virtuais não é sem desvantagens. As máquinas virtuais são grandes e exigem que os desenvolvedores usem computadores poderosos o suficiente para executá-los com desempenho aceitável para serem produtivos. Além disso, especialmente em períodos mais longos de tempo, os desenvolvedores precisam manter o sistema operacional atualizado e garantir que eles executem todas as atualizações de segurança necessárias. Como os desenvolvedores trabalham em uma máquina virtual, eles precisam passar algum tempo no início de um novo projeto para configurar a máquina virtual padrão em suas preferências ou ter que ceder à configuração padrão ao custo de sua produtividade. Como as máquinas virtuais executam um sistema operacional completo com todos os seus componentes, é muito mais difícil garantir que todas as máquinas virtuais usadas por todos os desenvolvedores da equipe sejam consistentes. Comparando a outros tipos de ambientes de desenvolvimento, o uso de máquinas virtuais para a criação de soluções do SharePoint Framework é dispendioso em termos de tempo e custo.

Desenvolvimento usando Docker

Um meio termo interessante entre o desenvolvimento no host e em uma máquina virtual é o uso do Docker. O Docker é uma tecnologia de virtualização de software semelhante a máquinas virtuais com algumas diferenças. Os benefícios mais importantes do uso de imagens do Docker em máquinas virtuais são que as imagens do Docker são mais fáceis de criar, manter e distribuir, elas são mais leves (algumas centenas de MBs em comparação com dezenas de espaço em disco de GBs necessário para máquinas virtuais) e permitem que os desenvolvedores usem as ferramentas e preferências que já instalaram e configuraram em sua máquina host.

Da mesma forma que as máquinas virtuais, os contêineres do Docker executam uma instância virtualizada de um sistema operacional (mais comumente baseado no Linux). Todo o software instalado na imagem usada para criar o contêiner é executado de forma isolada dentro do contêiner e tem acesso somente à parte do sistema de arquivos host explicitamente compartilhado com o contêiner. Como todas as alterações no sistema de arquivos dentro de um contêiner do Docker são descartadas quando o contêiner é fechado, os desenvolvedores compartilham pastas do host para armazenar o código-fonte.

Para saber mais, confira Uso do Docker para a criação de soluções da Estrutura do SharePoint.

Fluxo de trabalho de desenvolvimento em projetos da Estrutura do SharePoint

Estrutura do SharePoint se baseia no conjunto de ferramentas de código aberto e segue o fluxo de trabalho de desenvolvimento geral presente em outros projetos criados na mesma pilha. A seguir, uma descrição da aparência desse fluxo de trabalho em um projeto típico do SharePoint Framework.

Criar um novo projeto da Estrutura do SharePoint

Durante a criação de personalizações do SharePoint usando a Estrutura do SharePoint, a primeira etapa é incluir scaffolding para o novo projeto da Estrutura do SharePoint. Isso é feito usando o gerador do Yeoman da Estrutura do SharePoint. O gerador indagará se você deseja responder a algumas perguntas sobre o nome do projeto ou sua localização. Ele também permitirá que você crie a primeira Web Part ou extensão. Embora você possa escolher uma estrutura JavaScript diferente para cada um dos componentes, a recomendação geral é usar uma única estrutura por projeto da Estrutura do SharePoint.

Bloquear a versão de dependências

Um novo Estrutura do SharePoint projeto criado pelo gerador yeoman Estrutura do SharePoint tem dependências dos pacotes de Estrutura do SharePoint e outros pacotes necessários para que ele seja executado corretamente. À medida que você cria suas Web Parts, talvez você queira incluir dependências adicionais, como Angular ou jQuery. Em projetos de SharePoint Framework, as dependências são instaladas usando o npm. Cada dependência é um pacote do Node.js com uma versão específica. Por padrão, as dependências são referenciadas usando um intervalo de versões, que se destina a ajudar os desenvolvedores a manter suas dependências atualizadas com mais facilidade. Uma consequência dessa abordagem é que restaurar dependências para o mesmo projeto em dois pontos no tempo pode dar resultados diferentes, o que pode até levar à interrupção do projeto.

Uma solução comum para evitar o risco de que as dependências sejam alteradas durante o projeto, em projetos compilados na cadeia de ferramentas de software livre, é bloquear a versão de todas as dependências. Ao adicionar uma dependência ao projeto, os desenvolvedores podem optar por instalá-la com uma versão específica, em vez de um intervalo de versões, chamando o comando npm install com o argumento --save-exact.

No entanto, isso não afeta as dependências filho do pacote específico. Para bloquear efetivamente a versão de todas as dependências e seus filhos no projeto, os desenvolvedores podem usar o recurso de bloqueio nativo do arquivo suportado pelo NPM. Para obter mais informações, confira NPM-Package-Locks: uma explicação do bloqueio de arquivos do NPM.

Adicionar o projeto ao controle de código-fonte

Para permitir que o restante da equipe trabalhe no mesmo projeto, adicione-o ao sistema de controle de código-fonte que sua equipe está usando. As etapas exatas serão diferentes dependendo do sistema usado pela equipe.

O scaffolding é incluído nos projetos da Estrutura do SharePoint com o arquivo .gitignore, que descreve quais arquivos devem ser excluídos do controle de código-fonte. Se a equipe está usando um sistema de controle de código-fonte diferente do Git (como o Visual Studio Team System com repositórios Team Foundation System), convém garantir que você inclua os arquivos corretos do projeto no controle de código-fonte. Além disso, exclua as dependências e os arquivos gerados automaticamente durante o processo de criação para garantir que a equipe trabalhe com eficiência.

Um local no qual os desenvolvedores devem prestar atenção especial para não o incluírem no controle de código-fonte é a pasta node_modules. Essa pasta contém pacotes dos quais o projeto depende e que são instalados automaticamente ao restaurar dependências usando o comando npm install. Alguns pacotes são compilados como binários quando o processo de compilação depende do sistema operacional. Se a equipe estiver trabalhando em diferentes sistemas operacionais, incluindo a pasta node_modules no controle de origem provavelmente interromperá o build para alguns membros da equipe.

Obter o projeto do controle de código-fonte

Ao obter o projeto do controle de código-fonte pela primeira vez, você obterá o código-fonte do projeto, mas nenhuma das bibliotecas da Estrutura do SharePoint necessárias para criar o projeto. Como ocorre ao se trabalhar com projetos .NET e ao usar pacotes do NuGet, você precisa restaurar as dependências primeiro. Em projetos na Estrutura do SharePoint, da mesma forma como ocorre com todos os outros projetos baseados no Node.js, você faz isso executando npm install na linha de comando. O npm usará as informações do arquivo package.json combinadas às informações do arquivo npm-shrinkwrap.json e instalará todos os pacotes.

Alguns dos pacotes são compilados como binários durante o processo de instalação. Esse processo de compilação é específico para a arquitetura e o sistema operacional. Se você restaurar dependências em um contêiner do Docker executando Linux e tentar compilar o projeto no host do Windows, obterá um erro de incompatibilidade no tipo de ambiente usado para compilar e executar os binários.

À medida que a equipe desenvolver a solução, dependências novas ou atualizadas poderão ser adicionadas ao projeto. Se o arquivo package.json tiver sido alterado desde a última vez que você obteve o projeto do controle de código-fonte, você terá que executar npm install na linha de comando para instalar as dependências ausentes. Se você não tiver certeza se o arquivo package.json foi alterado, poderá executar npm install na linha de comando apenas para garantir que tenha as dependências mais recentes, sem danificar o projeto.

Adicionar pacotes ao projeto

Usar pacotes existentes para realizar tarefas específicas permite que você seja mais produtivo. https://www.npmjs.com é um registro público dos pacotes que você pode usar no projeto.

Para adicionar um pacote ao seu projeto Estrutura do SharePoint execute o npm install {package} --save or npm install {package} --save-dev command in the command line, por exemplo: npm install angular --save. Usar os argumentos --save ou--save-dev garante que o pacote seja adicionado ao arquivo package.json, e outros desenvolvedores da equipe também o obterão ao restaurar dependências. Sem ele, a compilação do projeto em um computador que não seja o seu próprio falhará. Ao adicionar pacotes exigidos pela solução em tempo de execução, como Angular ou jQuery, você deve usar o argumento --save. Os pacotes que são necessários no processo de compilação, como tarefas adicionais do Gulp, devem ser instalados com o argumento --save-dev.

Ao instalar um pacote, se você não especificar uma versão, o npm instalará a versão mais recente disponível no registro do pacote (https://www.npmjs.com por padrão), que geralmente é a versão que você deseja usar. Um caso específico em que você precisa especificar a versão do pacote é se usar npm-shrinkwrap.json e desejar atualizar um pacote existente para uma versão mais recente. Por padrão, npm instalará a versão listada no arquivo npm-shrinkwrap.json. Especificar o número da versão no comando npm install, como npm install angular@1.5.9 --save, instalará o pacote e atualizará o número da versão no arquivo npm-shrinkwrap.json.

Trabalho com pacotes internos

À medida que a equipe for desenvolvendo soluções do lado do cliente, muito provavelmente você criará bibliotecas de código comuns que desejará reutilizar em todo o projeto. Em muitos casos, essas bibliotecas contêm código proprietário não compartilhado publicamente fora da organização, além dos pacotes implantados em produção. Ao se trabalhar com projetos do SharePoint Framework, há várias maneiras para que sua equipe utilize as bibliotecas internas nos projetos.

Hospedagem do registro de pacote privado

No passado, muitas organizações que criavam soluções .NET hospedavam repositórios NuGet privados para tirar proveito do sistema de gerenciamento de pacotes NuGet para os pacotes internos. Como o SharePoint Framework usa npm para gerenciamento de pacotes, da mesma forma, as organizações podem usar um registro privado para seus pacotes internos. Os pacotes desenvolvidos internamente seriam publicados no registro privado e usados em todos os projetos na organização.

Ao usar registros de pacotes privados, as organizações podem escolher entre diferentes ofertas hospedadas na nuvem ou podem hospedar seu próprio registro em sua própria infraestrutura.

Usar um registro de pacotes privado permite que as organizações gerenciem centralmente o código comum usado entre diferentes projetos. Através da definição de um plano de governança separado com a contribuição de alterações na base de código compartilhado, as organizações podem garantir que a biblioteca de código seja de alta qualidade e ofereça benefícios a todos os desenvolvedores, conforme pretendido, em vez de tornar os projetos mais lentos.

As organizações que usam o Visual Studio Team Services ou o Team Foundation Server podem convenientemente criar um registro npm particular diretamente no VSTS/TFS. As organizações que usam outros sistemas de controle de origem pode usar outras soluções para hospedar seus pacotes. Um registro privado popular hospedado na nuvem é o npm Enterprise. As organizações que estão interessadas em hospedar seu próprio registro podem escolher entre várias implementações de software livre, como Sinopia ou sua bifurcação Verdaccio ou Nexus.

Para simplificar a instalação e o gerenciamento de um registro de pacotes privado, a maioria dos mecanismos oferece imagens do Docker prontas para uso.

Vinculação de pacotes usando o link npm

Uma alternativa ao uso de um registro privado é vincular pacotes. Embora isso não envolva a configuração de um registro, requer coordenação cuidadosa em todas as máquinas de desenvolvedor e no servidor de compilação.

Primeiro, todos os desenvolvedores da equipe devem obter uma cópia do pacote compartilhado nas máquinas de desenvolvimento. Na linha de comando, eles precisam alterar o diretório de trabalho para aquele dos pacotes compartilhados e devem executar o comando npm link. Esse comando registra o pacote específico como um pacote global nessa máquina de desenvolvimento específica. Em seguida, os desenvolvedores têm que alterar o diretório de trabalho para o diretório do projeto no desejam usar o pacote compartilhado. Em seguida, eles instalam o pacote da mesma forma que instalam qualquer outro pacote executando a instalação do npm {shared_package} --salve o comando na linha de comando. Conforme o pacote compartilhado for instalado globalmente, npm usará essa versão como origem para instalar o pacote. Então, do ponto de vista do projeto, o pacote é instalado como qualquer outro pacote público, e os desenvolvedores podem escolher como desejam combinar o pacote ao projeto.

A vinculação do pacote deve ser executada em todos os computadores de desenvolvimento e no servidor de compilação. Se o pacote compartilhado não for vinculado usando o comando npm link, a restauração de dependências do projeto falhará e danificará a compilação.

Referenciar pacotes vinculados é útil no início do projeto, quando você está desenvolvendo o pacote compartilhado e o projeto ao mesmo tempo. Graças à vinculação, não é necessário publicar a nova versão do pacote no registro para usar o código mais recente no projeto. Um risco a ser lembrado é que, se os desenvolvedores referenciassem uma versão da biblioteca compartilhada que eles alteraram localmente e que ainda não confirmaram com o controle de código-fonte, ela danificaria a compilação para o restante da equipe.

Combinando um registro de pacotes privado e vinculando pacotes

A vinculação de pacotes pode ser combinado a um registro privado. Você pode, por exemplo, trabalhar de uma maneira em que os desenvolvedores referenciam um pacote vinculado e o servidor de build retira a biblioteca compartilhada de um registro privado. Da perspectiva do projeto, nada muda: a referência de pacote no arquivo package.json pode ser resolvida por meio de um pacote vinculado ou de um registro privado. A equipe só precisa se lembrar de publicar as alterações mais recentes na biblioteca compartilhada para o registro privado antes de executar a compilação.

À medida que o código da biblioteca compartilhada se estabilizar ao longo do tempo e menos alterações forem necessárias para acomodar as necessidades dos projetos específicos, os desenvolvedores provavelmente referenciarão apenas o pacote publicado do registro privado, em vez de alterá-lo.

Garantia da consistência e da qualidade do código

As equipes de desenvolvimento de software geralmente lidam com a manutenção de consistência e alta qualidade de seus projetos. Diferentes desenvolvedores têm diferentes estilos de codificação e preferências. Em cada equipe, há indivíduos mais qualificados e desenvolvedores menos experientes em determinado domínio. Além disso, muitas organizações ou segmentos verticais têm normas específicas com as quais o software deve estar em conformidade. Todos esses desafios dificultam o percurso dos desenvolvedores. Particularmente quando o prazo está próximo, os desenvolvedores tendem a realizar as tarefas em detrimento da qualidade, que, a longo prazo, é mais prejudicial do que não cumprir a data limite.

Escolher a biblioteca JavaScript para sua equipe e usar padrões de código

Se a equipe criou personalizações do SharePoint no passado, você provavelmente tem padrões de codificação que descrevem como criar as personalizações e quais ferramentas e bibliotecas são usadas no projetos. O uso de padrões de codificação permite que você elimine as preferências pessoais dos desenvolvedores individuais do código, o que facilita o trabalho para outros membros da equipe. Além disso, os padrões de codificação refletem a experiência da equipe coletada ao longo dos anos, permitindo que você crie personalizações de melhor qualidade e com mais eficiência.

Diferentemente de outros modelos de personalização do SharePoint disponíveis atualmente, o SharePoint Framework se concentra no desenvolvimento do lado do cliente. Embora não seja estritamente necessário, o SharePoint Framework recomenda o uso do TypeScript para ajudar os desenvolvedores a escrever código melhor e detectar qualquer inconsistência durante o processo de compilação. Também há centenas de bibliotecas do lado do cliente disponíveis para realizar a mesma tarefa. Se a equipe tiver realizado desenvolvimento do lado do cliente no passado, talvez você já tenha uma preferência por uma biblioteca específica. Caso contrário, seria altamente vantajoso pesquisar algumas das bibliotecas mais populares e escolher uma opção para a equipe ou, preferencialmente, para toda a organização.

Usando a mesma biblioteca em todos os projetos, você facilita a integração de novos membros à equipe e a troca de membros da equipe entre projetos. Ao adquirir mais experiência com o desenvolvimento do lado do cliente, sua organização poderá se beneficiar disso em todos os projetos. Padronizar os projetos em toda a organização também reduz o tempo de entrega e os custos de manutenção dos projetos. Novas bibliotecas são publicadas na Internet todos os dias. Se você alternar constantemente entre as bibliotecas mais recentes, o trabalho será ineficaz e as soluções fornecidas serão de baixa qualidade.

Padronizar as bibliotecas usadas em toda a organização também ajuda a otimizar o desempenho das soluções. Como a mesma biblioteca é usada em toda a organização, os usuários precisam baixá-la apenas uma vez, o que aumenta significativamente o tempo de carregamento das soluções e, como resultado, melhora a experiência do usuário.

Escolher uma das bibliotecas mais populares permite reutilizar o conhecimento e a experiência de outros desenvolvedores que já usam essa biblioteca há mais tempo e já resolveram muitos dos problemas que você provavelmente encontrará. Também para as bibliotecas mais populares, há padrões de codificação disponíveis que a equipe pode adotar. Usando os padrões de mercado existentes para a biblioteca específica, é mais fácil para a organização aumentar a equipe contratando desenvolvedores e ajudando-os a se tornar produtivos mais depressa.

Por exemplo, para criar soluções de terceiros no SharePoint Framework, a Microsoft escolheu o React. Além disso, muitas outras equipes da Microsoft, como o OneDrive ou o Delve, usam o React em seus projetos. Isso não significa que você também deva usar o React em todos os seus projetos do SharePoint Framework, mas comprova a importância da escolha de uma biblioteca do lado do cliente que funcione para a organização. Por exemplo, se a equipe tem experiência com o Angular ou o Knockout, não há motivo para não se beneficiar dessa experiência e ser produtivo durante a criação de soluções da Estrutura do SharePoint.

Impor políticas e padrões de codificação em todo o ciclo de vida da solução

Usar padrões de codificação oferece vantagens claras, mas apenas ter padrões de codificação não significa que eles sejam usados ativamente durante todo o processo desenvolvimento e teste de uma personalização do SharePoint. Quanto mais tempo os desenvolvedores aguardarem, mais difícil será para a equipe verificar se a solução cumpre as políticas organizacionais e os padrões de codificação da equipe e mais caro será corrigir os defeitos encontrados no projeto. A seguir estão alguns meios que a equipe deve usar como parte do processo de desenvolvimento para impor o plano de governança para a solução do SharePoint.

Linting

O linting é o processo que verifica se o código atende a regras específicas. Por padrão, projetos do SharePoint Framework são criados usando o TypeScript. Em cada compilação, o TSLint, linter para o TypeScript, analisa o projeto em relação ao conjunto predefinido de regras e relata qualquer inconsistência. Os desenvolvedores podem escolher quais regras desejam habilitar e, se necessário, podem criar suas próprias regras, que reflitam diretrizes da equipe ou da organização.

Os desenvolvedores podem usar o linting para verificar não apenas o conteúdo dos arquivos TypeScript. Há linters disponíveis para linguagens mais populares, como CSS, JavaScript ou Markdown, e se sua equipe tiver diretrizes específicas para esses idiomas, seria benéfico implementá-los em um linter para que eles possam ser validados automaticamente sempre que um desenvolvedor compilar o projeto.

Testes automatizados

Usando testes automatizados, os desenvolvedores podem facilmente verificar se, depois de aplicar as alterações mais recentes ao projeto, todos os elementos continuam funcionando conforme o esperado. À medida que o projeto cresce, aumenta a importância dos testes automatizados: com o código base se expandindo, cada mudança tem maior impacto e maior risco de afetar outras partes do código. Os testes automatizados permitem que os desenvolvedores verifiquem se a solução funciona corretamente e detectem possíveis problemas logo no início.

A Estrutura do SharePoint dá suporte padrão para o executor de teste Karma e a estrutura Mocha, que os desenvolvedores podem usar para escrever testes. Se necessário, os desenvolvedores podem usar blocos de construção adicionais fornecidos com a Estrutura do SharePoint, como Jest e PhantomJS para ampliar ainda mais a cobertura dos testes. Todos os testes nos projetos da Estrutura do SharePoint podem ser executados utilizando a tarefa padrão gulp test.

Análise de código

Embora linting seja útil para validar a sintaxe de arquivo específico, frequentemente os desenvolvedores precisam de mais suporte para confirmar que o projeto como um todo atende às diretrizes. Geralmente, os linters se concentram no código em si, mas não examinam o contexto do que o arquivo de código específico representa. Em soluções do SharePoint Framework, os artefatos têm requisitos específicos; por exemplo, uma Web part deve ter uma ID exclusiva no projeto. Além disso, as organizações podem ter outros requisitos, como não referenciar scripts na CDN ou só usar uma versão específica de determinada biblioteca. Essa é uma limitação dos linters, e os desenvolvedores precisam de outras ferramentas.

O SPCAF (SharePoint Code Analysis Framework) é uma solução de terceiros frequentemente usada por administradores, desenvolvedores e funcionários do SharePoint em funções de segurança e garantia de qualidade para verificar se as personalizações do SharePoint atendem às diretrizes de qualidade organizacional. O SPCAF integra-se ao processo de ciclo de vida do aplicativo inteiro para ajudar organizações a reduzir o custo total de propriedade de personalizações do SharePoint. O SPCAF oferece um conjunto de regras direcionadas especificamente para soluções da Estrutura do SharePoint.

Atualização de projetos da Estrutura do SharePoint

Implantar uma personalização do SharePoint na produção normalmente não significa o fim do ciclo de vida. Frequentemente, os requisitos são alterados ou novos requisitos são adicionados em ambos os casos, levando a alterações na solução. Para atualizar corretamente uma personalização implantada anteriormente para desenvolvedores de produção, é necessário levar em conta várias coisas.

Controle de versão semântico (SemVer)

Com poucas exceções, o SharePoint Framework usa o controle de versão semântico (SemVer) para acompanhar os números de versão. O controle de versão semântico é um padrão de controle de versão adotado por desenvolvedores de software em todo o mundo. Um número SemVer consiste em três números MAJOR.MINOR.PATCH e rótulos opcionais; por exemplo, 1.0.1.

Diferentes partes de um número SemVer são aumentadas dependendo do tipo de alteração aplicada à solução:

• MAJOR, se as alterações não são compatíveis com versões anteriores
• MINOR, se as alterações introduzem nova funcionalidade é compatível com versões anteriores
• PATCH, se as alterações são correções compatíveis com versões anteriores

É importante ter em mente que SemVer é simplesmente um contrato. Cabe à sua equipe fazer o acompanhamento para esclarecer as alterações na versão mais recente.

Você pode ler mais sobre controle de versão semântico em http://semver.org.

Aumentar o número de versão

Ao atualizar uma parte de uma solução da Estrutura do SharePoint, os desenvolvedores devem aumentar os números de versão das partes afetadas para indicar claramente quais elementos foram alterados e qual é o impacto das alterações.

Aumentar a versão do pacote em package.json

Pacote da Estrutura do SharePoint estruturado como um pacote Node.js. Suas dependências e metadados são armazenados no arquivo package.json na pasta do projeto. Uma das propriedades no arquivo package.json é a propriedade de versão que indica a versão de todo o projeto. Por padrão, todos os componentes na solução atual herdam esse número de versão como sua versão. Os desenvolvedores deverão aumentar o número da versão no arquivo package.json sempre que uma nova versão do projeto for planejada, seguindo a convenção SemVer.

Aumentar a versão do pacote de solução em package-solution.json

Estrutura do SharePoint soluções são implantadas usando um arquivo *.sppkg instalado no catálogo de aplicativos em um locatário do SharePoint. Um arquivo *.sppkg é semelhante a um pacote de suplemento do SharePoint e segue as mesmas convenções de versão. A versão atual do pacote *.sppkg é definida usando um MAJOR (quatro partes). MENOR. REVISÃO. NÚMERO BUILD) armazenado no arquivo config/package-solution.json . Para proporcionar clareza, os desenvolvedores devem manter esse número em sincronia com o número de versão do arquivo package.json, pois ambos os números se referem à versão do projeto como um todo.

Atualizar dependências

Um dos motivos para uma atualização de um projeto do SharePoint Framework pode ser uma alteração em uma das dependências subjacentes; por exemplo, uma nova versão do Angular com correções e melhorias de desempenho. Se sua equipe seguir a abordagem recomendada de usar o npm shrinkwrap para bloquear versões de dependência, você usará o comando npm install {package}@{version} --save para atualizar sua dependência para a versão específica e testar seu projeto para verificar se ele funciona conforme o esperado com as atualizações mais recentes. Dependendo de como as alterações nas dependências subjacentes afetam o projeto, a atualização geral do projeto pode variar desde um patch até um lançamento principal completo.

Leve em consideração as alterações da estrutura do projeto

Atualizar seu projeto para uma versão mais recente da Estrutura do SharePoint, pode exigir alterações na estrutura do projeto e arquivos de configuração do projeto. Antes de atualizar as versões da Estrutura do SharePoint nas dependências do projeto, você crie sempre um novo projeto usando a versão da Estrutura do SharePoint para a qual você deseja atualizar e comparar cuidadosamente sua estrutura e o conteúdo com o projeto existente. Isso permitirá determinar o impacto da atualização em seu projeto e ajudará a evitar a aplicação de alterações significativas ao seu projeto.

Lembre-se de usar npm desatualizado

Uma das maneiras de descobrir quais dependências no projeto precisam de ser atualizadas é através da execução do comando npm desatualizada. Esse comando verificará sua árvore de dependência e mostrará a você quais pacotes podem ser atualizados. Tenha cuidado ao usar esse valioso comando.

A partir do SPFx v1.3, o gerador Yeoman da Estrutura do SharePoint permite que você escolha se deseja estruturar um projeto para trabalhar apenas no SharePoint Online ou em ambos locais, no SharePoint 2016 Feature Pack 2 e superior e no SharePoint Online. O SharePoint hospedado no local usa uma versão da Estrutura do SharePoint anterior à versão mais recente disponível no SharePoint Online. Se você preferir executar o comando npm outdated em um projeto compatível com o SharePoint local, deveria ser sugerido que todos os pacotes principais da Estrutura do SharePoint fossem atualizados para as versões mais recentes publicadas no npm. Infelizmente, ao atualizar esses pacotes para suas versões mais recentes, seu projeto já não funcionará com o SharePoint local. Antes de atualizar as versões dos pacotes da Estrutura do SharePoint, verifique sempre se o projeto deverá trabalhar com o SharePoint hospedado no local. Em caso afirmativo, qual versão da Estrutura do SharePoint terá suporte.

Compilar e empacotar o projeto no modo de lançamento

Depois de verificar se a solução está funcionando conforme o esperado, crie o projeto no modo de lançamento usando o comando gulp bundle --ship. Em seguida, crie um novo pacote usando o comando gulp package-solution --ship. Sem executar o comandogulp bundle --ship pela primeira vez, o pacote incluirá uma versão anterior do projeto.

Implantar a nova versão da solução

Após a compilação e o empacotamento do projeto, a próxima etapa é implantá-lo. Primeiro implante os pacotes de Web part atualizados, localizados na pasta ./temp/deploy no projeto. Publique os arquivos ao lado dos pacotes de Web parts da versão anterior da solução.

Em seguida, implante o novo pacote de solução no catálogo de aplicativos do SharePoint. Isso é necessário para notificar o SharePoint da nova versão da solução que ele deve aplicar.