Boas Práticas

1.      Desenvolvimento

1.1        As webpartes devem disponibilizar parametros de configuração.

1.2        As customizações devem ser acompanhadas por uma lista de todas as suas dependências (contas/passwords, Web services, bases de dados, solutions ou features, patches, ferramentas ou libraries, etc.)

1.3        As assemblies devem estar assinadas (strong name).

1.4        A configuração das customizações devem estar num ficheiro de configuração próprio e não no Web.config. No entanto uma opção pode ser usar uma configuration section própria.

1.5        Usar apenas uma versão da Framework .NET.

1.6        Evitar usar strings hardcoded, usar ficheiros de resources/languages.

1.7        Quando se usar objectos SPWeb/ SPSite, usar using ou usar o método Dispose. Usar SPDisposeCheck.

1.8        Em termos de logging usar como destino os logs do sharepoint (SharePoint Unified Logging Service logs) quer directamente via Portal Log class, quer via um custom trace listener.

1.9        Usar uma aproximação estruturada de gestão de erros e excepções. Uma opção é usar uma framework de logging  como o elmah.

1.10     Aquando de um erro, a aplicação falha graciosamente - uma mensagem genérica é retornada para o utilizador – a mensagem segue para o log, ou então ter esse controlo via configuração tipo custom erros RemoteOnly|On|Off .

1.11     Validar todos os inputs dos utilizadores quer para evitar a falha, quer para evitar tampering ou injection.

1.12     Reduzir as chamadas à BD – não mais de 2 a 3 chamadas por página.

1.13     Não se usar código inline em aspx/ascx

2.      Instalação

2.1        Utilização de Features e Solution Packages para a instalação de customizações

2.2        As customizações devem ser acompanhadas por instruções de instalação/desinstalação.

2.3        A WSP deve incluir a policy CAS se esta for necessária assim como a inclusão da assembly na Safe Control list.

2.4        O logging específico do processo de instalação/desinstalação deve ser redirecionado para o event log para fácil troubleshooting.

3.      Configurações

3.1        Recycling Application Pool Settings

3.1.1  Worker process recycle a uma hora específica  - Uma vez por noite.

3.1.2  Max Physical e Virtual memory - 1000MB a  1700 MB

3.2        Performance Application Pool Settings

3.2.1  Idle timeout – off

3.2.2  Request queue – unchecked

3.2.3  CPU limits - unchecked.

3.3        Health Application Pool Settings

3.3.1   Pinging – activo, 600 a 900 segundos

3.3.2   Startup/Shutdown - 300-900

3.4        Identity Application Pool Settings – Uma única conta por cada AppPool.

Configuração de anti-virus se não houver controlo de todos utilizadores que podem inserir documentos.

4.      Topologia

4.1   Se possível deverá haver Web Front-Ends (WFE) dedicados.

4.2   Servidores que são application server roles ou database server não devem ter acesso directos de utilizadores.

4.3   O site da Central Administration, se possível, não deverá estar nos WFE.

4.4   Os servidores da Farm devem estar no mesmo data center e na mesma vLAN.

4.5   Se for necessário um ambiente mais seguro a farm deverá estar separada em 3 camadas (WFEs, servidores aplicacionais e base de dados) através de routers ou firewalls cada um na sua vLAN.

4.6   Pelo menos uma zona em cada Web application deve usar autenticação  NTLM para poder ser usada pela conta de pesquisa para o crawl.

4.7   Os relógios de todos os servidores da farm devem estar sincronizados.

4.8   Utilização de alguma das topologias aconselhadas pela Microsoft.

4.9   Se possível proteger os servidores aplicacionais/base de dados com uma firewall entre estes e os WFE.

5.       Arquitectura Lógica

5.1        Nomes dos sites estarem replicados no nome do site IIS, AppPool e Content Database

5.2        Acesso seguro à Central Administration via SSL

5.3        Se se está a usar Content Deployment, ter a opção “Deploy user names” desactivada para proteger a identidade dos autores

5.4        Se não se está a usar Content Deployment, este deve estar desactivado (Reject incoming content deployment jobs)

5.5        Apenas ter o acesso anónimo activado nas zonas que têm site collections com esse requisito

5.6        Se se está a usar content Deployment, separar o ambiente de staging do ambiente de authoring.

6.      Segurança

6.1   Bloquear o acesso externo ao porto usado pelo site da Central Administration

6.2   Modo Lockdown activado.

6.3   Usar a autenticação Anonymous no IIS.

6.4   SMTP e Incoming Mail desactivado nos WFEs

6.5   Contas de serviço a usar – uma para o Crawl (não local admin), uma para a Central Admin service/SSP service/SSP Admin (app pool)/Timer e uma para cada web application pool

6.6    Se se tiver um WFE dedicado para indexing, configurar o IIS para restringir o acesso ao SiteData.asmx para apenas o Index server.

7.      Optimizações

7.1        Output caching

7.2        HTTP/IIS compression

7.3        Object caching

7.4        Configurações de Rede:

7.4.1     Usar equipamentos de Rede (placas de rede, switches, routers) que suportem 1 gigabit – forçar a placa de rede a 1 Gb

7.4.2     Latencia entre os  servidores Web e o servidor de BD deve ser inferior a 1ms

7.5        Garantir que o CPU usado médio do servidor de Base de Dados não passe os 60% - se sim, usar chaching, mover o indexing/crawler para outro servidor

7.6        As recomendações a partir do teste de performance com a ferramenta YSlow

7.7        Atrasar o download do core.js para permitir um carregamente mais rápido da página

7.8        Imagens optimizadas para a web, testado com Smush.it

7.9        As imagens têm especificada a dimensão (W3C Recommendation: 13.7.1 Width and height)

7.10     Compressão das custom CSS - CSSTidy , YUI Compressor

7.11     Garantir que as listas respeitam as limitações da plataforma

8.      Funcional

8.1   Cross Browser

8.2   Acessível nível A (WCAG)

9.      Governance

9.1   Definir onde são guardadas as versões antigas das configurações, codigo, assemblies, etc.

9.2   Ter um processo definido para gestão de alterações (como é que estas são registadas, catalogadas e aprovadas/rejeitadas)

9.3   Utilização de um repositório central para versionamento do código.

9.4   Criar planos de testes.

9.5   Diponibilizar aos site owners uma forma conveniente de darem feedback dos resultados dos testes.

9.6   Definir mecanismos de recuperação de ficheiros (versionamento ou recycle bin)

9.7   Definir mecanismo para recuperação de sites ou site collections.

9.8   Definir mecanismo para recuperação de servidores.

9.9   Definir quotas por defeito para as Web aplications.

9.10     Existência de material de formação para gestores de conteúdo.

9.11     Existência de material de formação para administradores.