Arquivo da tag: Deploy

Modelo de Provisionamento de Objetos no SharePoint

Olá SharePointers,

Hoje vou abordar um assunto que tem mexido com a comunidade de SharePoint ao redor do mundo: Modelo de provisionamento de objetos no SharePoint.

Até agora, versão 2013 do SharePoint, tínhamos, basicamente, uma maneira de fazer isso: utilizando o Feature Framework.

Para quem não sabe, Feature Framework é o método que utilizamos para criarmos definições (em formato XML, conhecido como CAML – Collaborative Application Markup Language (https://msdn.microsoft.com/en-us/library/office/ms462365%28v=office.15%29.aspx)) e disponibilizarmos no SharePoint, através de Features. Sendo assim, quando uma feature é ativada você pode fazer com que objetos “apareçam” no SharePoint quase como mágica, entre eles podemos citar: Listas, Content Types, Arquivos…

Essas features, podem ficar disponíveis para qualquer usuário (que tenha permissões adequadas) ativar e disponibilizar um certo recurso para aquele site.

image

Para muitos, esse comportamento é bem parecido com aquele brinquedo Lego, ou seja, você pode plugar várias peças para montar um “brinquedo” novo.

Por exemplo, se quisermos criar uma lista com alguns campos, podemos utilizar o Wizard que o Visual Studio disponibiliza para nós e visualmente criar o que precisamos facilmente. Veja abaixo:

image

Dessa forma, o Visual Studio faz todo o “trabalho sujo” para nós, gerando o XML que o SharePoint entende:

<?xml version=”1.0″ encoding=”utf-8″?> <List xmlns:ows=”Microsoft SharePoint” Title=”MinhaLista” FolderCreation=”FALSE” Direction=”$Resources:Direction;” Url=”Lists/MinhaLista” BaseType=”0″ xmlns=”http://schemas.microsoft.com/sharepoint/”> <MetaData> <ContentTypes> <ContentTypeRef ID=”0x01″> <Folder TargetName=”Item” /> </ContentTypeRef> <ContentTypeRef ID=”0x0120″ /> </ContentTypes> <Fields> <Field ID=”{fa564e0f-0c70-4ab9-b863-0177e6ddd247}” Type=”Text” Name=”Title” DisplayName=”$Resources:core,Title;” Required=”TRUE” SourceID=”http://schemas.microsoft.com/sharepoint/v3″ StaticName=”Title” MaxLength=”255″ /> </Fields> <Views> <View BaseViewID=”0″ Type=”HTML” MobileView=”TRUE” TabularView=”FALSE”> <Toolbar Type=”Standard” /> <XslLink Default=”TRUE”>main.xsl</XslLink> <RowLimit Paged=”TRUE”>30</RowLimit> <ViewFields> <FieldRef Name=”LinkTitleNoMenu”></FieldRef> </ViewFields> <Query> <OrderBy> <FieldRef Name=”Modified” Ascending=”FALSE”></FieldRef> </OrderBy> </Query> <ParameterBindings> <ParameterBinding Name=”AddNewAnnouncement” Location=”Resource(wss,addnewitem)” /> <ParameterBinding Name=”NoAnnouncements” Location=”Resource(wss,noXinviewofY_LIST)” /> <ParameterBinding Name=”NoAnnouncementsHowTo” Location=”Resource(wss,noXinviewofY_ONET_HOME)” /> </ParameterBindings> </View> <View BaseViewID=”1″ Type=”HTML” WebPartZoneID=”Main” DisplayName=”$Resources:core,objectiv_schema_mwsidcamlidC24;” DefaultView=”TRUE” MobileView=”TRUE” MobileDefaultView=”TRUE” SetupPath=”pages\viewpage.aspx” ImageUrl=”/_layouts/15/images/generic.png?rev=23″ Url=”AllItems.aspx”> <Toolbar Type=”Standard” /> <XslLink Default=”TRUE”>main.xsl</XslLink> <JSLink>clienttemplates.js</JSLink> <RowLimit Paged=”TRUE”>30</RowLimit> <ViewFields> <FieldRef Name=”LinkTitle”></FieldRef> </ViewFields> <Query> <OrderBy> <FieldRef Name=”ID”></FieldRef> </OrderBy> </Query> <ParameterBindings> <ParameterBinding Name=”NoAnnouncements” Location=”Resource(wss,noXinviewofY_LIST)” /> <ParameterBinding Name=”NoAnnouncementsHowTo” Location=”Resource(wss,noXinviewofY_DEFAULT)” /> </ParameterBindings> </View> </Views> <Forms> <Form Type=”DisplayForm” Url=”DispForm.aspx” SetupPath=”pages\form.aspx” WebPartZoneID=”Main” /> <Form Type=”EditForm” Url=”EditForm.aspx” SetupPath=”pages\form.aspx” WebPartZoneID=”Main” /> <Form Type=”NewForm” Url=”NewForm.aspx” SetupPath=”pages\form.aspx” WebPartZoneID=”Main” /> </Forms> </MetaData> </List>

Desvantagens

Entretanto, nem tudo são flores nesse modelo. Embora a Microsoft tenha evoluído bastante os wizards no Visual Studio, hoje é possível criar uma lista, colocar os campos, configurar as suas views e várias outras atividades utilizando esses assistentes, quem conheceu a versão 2007 do SharePoint lembra do trabalho que era para editar esses arquivos manualmente.

Mas, voltando ao mundo de hoje, existem vários problemas com esse modelo:

· Updates e versionamento – Como lidar com isso? Por exemplo, você tem uma lista que já foi instalada no servidor e precisa criar um campo novo… Como proceder? Muito provavelmente a abordagem seria criar uma feature nova que quando fosse ativada provisionasse um novo campo via código. Dessa forma, o seu modelo de provisionamento ficaria uma bagunça e complexo.

· Objetos órfãos – É muito comum você ativar uma custom feature em vários sites e, quando não vai mais utilizar aquele WSP, simplesmente o desinstala. Nem lembra de desativar as features antes.. Isso pode até funcionar naquele momento, mas dará muitas dores de cabeça quando for fazer um upgrade do site.

· Desinstalação – Além disso, quando desativamos uma feature, é muito comum que os objetos criados por aquela feature continuem no servidor ou, ainda pior, fiquem em um estado “fantasma”.

· Curva de aprendizado – Outro problema que esse modelo causava é na curva de aprendizado para dominarmos/sabermos como criar objetos no SharePoint de forma eficiente e correta. E, mesmo os mais experientes, quantas vezes tentamos entender o porquê de alguma funcionalidade não estar funcionando de acordo com o esperado.

· Debug (?) – Debug, ou a falta de debug é mais um problema desse modelo. Quando você precisa entender o motivo de um erro o único local que você pode recorrer é o ULS. E todos sabemos o quanto isso pode ser chato e demorado….

A Microsoft veio, até aqui, evoluindo esse modelo. Mas ele chegou ao fim. Não estou dizendo que a Microsoft vai torna-lo deprecado tão rapidamente, mas isso vai acontecer eventualmente. Basta avaliarmos o esforço que a Microsoft está fazendo no GitHub (OfficePNP) em um novo modelo conhecido como Remote Provisioning, no link Site provisioning techniques and remote provisioning in SharePoint 2013 as principais formas de provisionamento são explicadas: (http://blogs.msdn.com/b/vesku/archive/2013/08/23/site-provisioning-techniques-and-remote-provisioning-in-sharepoint-2013.aspx).

Remote Provisioning

Como solução, ou alternativa, ao Feature Framework, a Microsoft recomenda a utilização do que eles estão chamando de Remote Provisioning.

De maneira bem simples, é você criar todos os objetos utilizando alguma biblioteca client (CSOM, por exemplo) e não ter nenhuma dependência de arquivos que precisam ser armazenados no servidor de SharePoint.

Dessa forma, embora tenhamos que criar mais códigos para atingir o mesmo resultado do que teríamos com o Feature Framework, esse trabalho se dará apenas uma vez. Quando tivermos construído um framework para provisionamento de objetos esse trabalho será bem mais rápido.

Como estamos escrevendo nosso próprio código, conseguimos debugar e ter controle sobre todos os aspectos dos objetos que serão criados.

Uma GRANDE VANTAGEM é que podemos fazer tudo isso sem ter acesso ao servidor. Podemos fazer de qualquer lugar, a única coisa que precisamos é uma credencial com permissões adequadas.

A curva de aprendizado é baixa ou quase nenhuma, pois já estamos em contatos com esses objetos o tempo todo. Interagimos com o List, por exemplo, para acessar uma lista e suas propriedades. De uma maneira superficial, o único conhecimento que você precisará é saber desenvolver utilizando o Client-Object Model.

Quem quiser saber como utilizar esse “pattern” de Remote Provisioning, pode utilizar a documentação já existente no PNP https://github.com/OfficeDev/PnP/tree/master/Scenarios, tem vários cenários que poderão ajudar a entender como utilizar e aplicar o modelo e, inclusive, dar ideias para criarmos os nosso próprios mecanismos de deploy.

Alguns cenários interessantes:

· Criar sites: https://github.com/OfficeDev/PnP/tree/master/Scenarios/Provisioning.CreateSite

· Permissões: https://github.com/OfficeDev/PnP/tree/master/Scenarios/Core.SitePermissions

· Usuários e Grupos: https://github.com/OfficeDev/PnP/tree/master/Scenarios/Core.GroupManagement

· Campos e Content Types: https://github.com/OfficeDev/PnP/tree/master/Scenarios/Core.ContentTypesAndFields

Pensando no cenário de nuvem, Office 365 (SharePoint Online) por exemplo, esse é o único modelo aplicável. Você até poderia utilizar Sandbox solutions para fazer deploy desse tipo de artefato (por enquanto), mas isso pode ser descontinuado a qualquer momento. Além disso, acredito que as vantagens apresentadas nesse modelo já justificam a sua utilização em detrimento à outras formas existentes atualmente.

Comparando com o mesmo cenário apresentado no modelo de Feature Framework, você poderia utilizar o Client Object Model (CSOM) para conectar no site que deseja criar alguma coisa e rodar o código que você já está acostumado para realizar essa tarefa, veja na imagem abaixo como criar uma Lista:

image

Você precisou escrever um pouco de código, sim. Mas, uma vez que esse código tenha sido criado, você irá reaproveitá-lo sempre que precisar.

 

 

Desvantagens

Sobre esse modelo, o que falta é uma maneira mais fácil de utilizar. Depois de tanta evolução no Feature Framework com seus templates de Visual Studio, a vida de um desenvolvedor SharePoint ficou mais fácil.

Acredito que para o modelo de “Remote Provisioning” ser adotado em larga escala e rapidamente, será necessário a criação de templates (Wizards) integrados ao Visual Studio para automatizar as tarefas mais comuns, de maneira simples.

Lembro de como a comunidade gostou de quando a Microsoft anunciou que agora era simples criar uma lista, content type e outros objetos de maneira visual pelo Visual Studio.

Entretanto, pelo quantidade de esforço que está sendo investido nesse modelo, acredito que logo teremos novidades nesse sentido 😀

 

 

 

Conclusão

Nesse post abordei as principais diferenças entre o modelo de deploy de artefatos existente no SharePoint (Feature Framework) e o Remote Provisioning.

Como esse modelo novo, o “Remote Provisioning”, está começando a ser divulgado agora ainda existe uma certa resistência dos profissionais em utilizá-lo. Entretanto, com todas as vantagens abordadas nesse artigo logo você estará utilizando esse modelo e esquecerá de todos os problemas gerados pelo modelo anterior.

Além disso, estou vendo uma grande “onda” a favor do Remote Provisioning. A Microsoft tem feito um grande esforço para que ele seja o modelo de deploy de artefatos. Acredito que, com isso, em algum momento próximo o Feature Framework seja considerado Deprecado.

Acredito que uma grande ressalva é que, para esse modelo de Remote Provisioning funcionar, a Microsoft tem que disponibilizar API Client para tudo que é possível fazer com o SharePoint via UI ou Server OM.

 

 

Agradecimentos

Quero agradecer especialmente ao PFE Fabian Gehrke por dar a ideia de escrever sobre esse assunto, me ajudar na revisão e contribuições para que a informação seja transmitida de forma eficiente.

Conversamos frequentemente sobre esse e vários assuntos pertinentes à plataforma.

Obrigado 😀

 

 

Referências

http://blogs.msdn.com/b/vesku/archive/2013/08/23/site-provisioning-techniques-and-remote-provisioning-in-sharepoint-2013.aspx

http://blogs.msdn.com/b/bobgerman/archive/2015/01/31/new-guidance-from-microsoft-for-packaging-and-deploying-sharepoint-solutions.aspx

https://github.com/OfficeDev/PnP/wiki

http://www.microsoftvirtualacademy.com/training-courses/transform-sharepoint-customizations-to-sharepoint-app-model

QuickTip: Visual Studio e Resolução de Conflitos para List Instances

Olá SharePointers,

Essa é uma QuickTip para ajudar a salvar algumas horas no desenvolvimento de soluções para o SharePoint.

Para as pessoas, como eu, que trabalham criando customizações para o SharePoint, o Visual Studio é considerado quase nossa ferramenta diária de trabalho.

Quando começamos uma solução, geralmente planejamos as listas e bibliotecas e criamos os List Definition/Instance para cada uma que utilizaremos na solução(Walkthrough: Create a Custom Field, Content Type, List Definition, and List Instance).

Entretanto, toda vez que vamos fazer um deploy, o Visual Studio apaga todas as listas e as criam novamente, certo?! ERRADO!

Existe uma configuração no List Istance do Visual Studio que permite que você controle esse comportamento: Deployment Conflict Resolution.

imageimage

 

Por padrão, essa opção está como Automatic. Se você alterá-la para None a lista não será mais apagada e criada novamente durante deploys Smiley de boca aberta!!!

 

Aproveitando a oportunidade, aproveitem para dar uma lida no guia da Microsoft que fala sobre como extender os recursos de Package e Deploy do Visual Studio: http://msdn.microsoft.com/en-us/library/ee471434.aspx.

 

Abraços!