Arquivo da tag: Deployment

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

SharePoint 2013 e seus modelos de desenvolvimento

Olá SharePointers,

Passando por alguns projetos recentes e após várias dúvidas comuns a profissionais do ramo, resolvi escrever um post sobre o assunto.

Com a introdução do SharePoint 2013, a Microsoft nos apresentou um recurso muito interessante: Apps for SharePoint. Durante todo o tempo em que esse conceito era apresentado para nós, era comum notarmos que a mensagem que era divulgada é “Apps é o futuro”.

Após esse período inicial, quando todos começaram a trabalhar com o produto, notamos uma grande resistência da comunidade em utilizá-lo. Para mais informações sobre como criar componentes reutilizáveis no SharePoint, veja: https://msdn.microsoft.com/en-us/library/office/jj163953(v=office.15).aspx.

Entretanto, nós profissionais, devemos filtrar a mensagem e entender o que está por trás disso tudo: Office 365. A Microsoft tem investido cada vez mais em sua plataforma de nuvem e é natural que ela concentre os seus esforços em sua “menina dos olhos”. Dessa forma, com os “famosos” apps, ela consegue resolver um problema crítico em um cenário de nuvem (com ambiente compartilhado entre os clientes): permitir que cada cliente possa customizar o seu espaço sem interferir nos demais e não ter um time para validar cada pacote, antes de ser colocado no ambiente SharePoint, para garantir que ele não contenha nenhuma operação potencialmente perigosa para o ambiente.

Com os apps não perdemos o nosso poder de customização e não dependemos de algum IT Pro para instalar, gerenciar os Change Requests no ambiente e potencialmente causar indisponibilidade no mesmo. Fantástico, não? 😀

Sendo assim, a Microsoft conseguiu criar um ambiente muito mais estável e gerenciável, permitindo entregar muita qualidade e evitando que um cliente degrade performance de outro. Combinação matadora para um ambiente de nuvem.

E quem não utiliza essa plataforma e ainda prefere/quer investir em sua plataforma on-premises?

Embora para alguns casos o modelo de Apps possa ser utilizado também, por exemplo em ambientes muito controlados onde customizações não são permitidas, esse modelo é super válido. Permite agregar valor para o usuário de forma rápida e, ainda em uma futura migração de versões do produto, é bem fácil migrar a solução.

Em um cenário onde você tem outras alternativas de desenvolvimento, como farm solutions, avaliá-las pode e deve fazer parte das atividades dos arquitetos de sistema. Escrevi um post uma vez comparando Farm Solutions com Apps (SharePoint 2013 : Farm Solution x Apps), ele aborda os detalhes técnicos com mais detalhes.

Mas, para um time que já investiu tempo (e dinheiro) criando uma série de framework e utilitários para farm solutions, não vale a pena investir esforço migrar para esse modelo novo (a não ser que tenha previsão de migrar para o Office 365 um dia). Além de termos muito mais controle com Farm Solutions, conseguimos evitar alguns comportamentos, na minha opinião, estranhos. Exemplo:

Utilizando REST APIs, ao referenciarmos um campo, devemos utilizar o Display Name do campo sem espaços; Se o campo tem o InternalName: NomePai e o Display Name: Nome do Pai, devo utilizar NomedoPai. Se o display name desse campo mudar, tem que alterar o código..

Não posso deixar de comentar que o investimento que a Microsoft está fazendo em APIs client é absurdo, buscando chegar no mesmo nível do Server Object Model. No mundo ideal, todas as APIs que temos disponíveis no lado do server estará disponível no Client. 🙂

A própria adição do “JSLink” (https://msdn.microsoft.com/en-us/magazine/dn745867.aspx) é sensacional.

Além disso, para uma farm on-prem suportar o modelo de Apps, é necessário realizar uma série de configurações adicionais no ambiente (inclusive no DNS – https://technet.microsoft.com/en-us/library/fp161236(v=office.15).aspx).

Autenticação não funcionará com Kerberos. É impossível lidar com tantas URLs diferentes que são geradas quando utilizamos Apps.

É muito rápido e fácil criar customizações server-side. Em pouco tempo estamos com uma solução pronta para utilização do usuário.

 

Para mim, sempre que possível, o modelo de desenvolvimento para ambientes on-prem é através de Farm Solutions.

 

Para ajudar na decisão de qual modelo escolher, recomendo a leitura desse link: https://msdn.microsoft.com/en-us/library/office/dn268593(v=office.15).aspx

Essa é uma discussão bem longa, gostaria de saber mais de vocês que utilizam o SharePoint no dia-a-dia. O que acham desse assunto? Qual modelo de desenvolvimento utilizam e porquê?