ASP.NET - Liste de contrôle de base pour la mise en production d'un site

Question

Je crée un site ASP.NET statique (en utilisant des pages maîtres et quelques formulaires) et je suis sur le point de le publier sur mon serveur de production.

Je sais que changer <compilation debug="true"> à faux, mais je me demande quelles autres choses je peux faire pour obtenir la plus grande vitesse possible. Il n'y a pas d'accès aux données sur le site, tout le contenu est statique. Est-ce que quelqu'un a une liste de contrôle qu'il utilise ou connaît une bonne ressource pour configurer des sites dans un environnement de production, en mettant l'accent sur les performances?

Aide-mémoire jusqu'à (Ne hésitez pas à modifier vous-même avec des ajouts de valeur)

1. Assurez-vous <compilation debug="false" /> est effectivement mis à faux dans web.config
2. Assurez-vous <trace enabled="false" /> est effectivement mis en à false dans Web.Config
3. Définir les autorisations de lecture/écriture/modification de dossier nécessaires pour le site
4. Activer GZIP dans IIS (réduit considérablement la taille des pages/css/javascript)
5. Avez-vous considéré OutputCaching pour toutes les pages/commandes?
6. Envisagez de configurer des tests Web (par exemple WatiN pour .NET) pour vous assurer que les fonctionnalités de votre site fonctionnent toujours correctement.
7. Assurez-vous que ce n'est pas vendredi après-midi!

Answer 1

Vérifiez votre web.config

Vérifiez debug (web.config/* .svc), le traçage, ...

débogage de mise à jour des valeurs de production:

• adresses e-mail
• (web) adresses de service
• fichiers journaux de position

recherche rapide: link

Answer 2

En outre, ne pas oublier de vérifier les paramètres de gzip dans IIS. La compression de la sortie rendra les choses plus rapides.

Answer 3

si son contenu statique tout, vous aurez envie d'utiliser agressif Output Caching

Answer 4

Si vous écrivez des fichiers journaux ou de sortie, assurez-vous que les autorisations de dossier appropriés sont configurés dans l'environnement de production. En général, les environnements de débogage/test sont beaucoup plus laxistes sur les autorisations de lecture/écriture de fichiers que sur la production.

Answer 5

Si votre site utilise une base de données et seulement présentant des informations, rendez la base de données en lecture seule. Cela enlève toute manipulation de verrouillage et accélère l'accès à un grande affaire.Si vous avez un back-end qui met à jour les données, faites-en une base de données distincte et prévoyez des périodes qui mettent à jour la base de données en lecture seule une fois par jour ou ce qui est nécessaire pour cette application.

Si vous venez de présenter des nouvelles et d'autres petites choses sur une entreprise web site qui change pas si souvent alors cette solution est probablement pour vous. Même si c'est un site avec des gigaoctets de données .. Le mot clé est, à quelle fréquence met-on à jour les données?

D'après ce que je vois dans les affaires de tous les jours, Noone pense vraiment cette solution parce que tout doit être « en temps réel », mais il y a beaucoup de cas où cela serait une solution parfaite.

Answer 6

Ne pas déployer le vendredi après-midi! Ceci est garanti pour gâcher votre tête pour le week-end.

Answer 7

Vous devriez avoir une sorte de test pour vérifier les différentes fonctions de votre site, et les autorisations. Par exemple, une fois que vous publiez. Passer en revue une liste de contrôle, puis-je accéder à x si je n'ai pas la permission? Est-ce que x, y, z fonctionnent sur l'application? Je le fais après chaque publication parce que de petits changements peuvent avoir un grand impact.

Answer 8

Il est en fait une liste de contrôle très bon sur how to perform a security deployment review fourni sur MSDN.

Answer 9

Vous devriez lire ceci:
https://stackoverflow.com/questions/72394/what-should-a-developer-know-before-building-a-public-web-site

Il est actuellement le 9 question sur le plus voté SO et dans le top 3 plus Favorited. Le bémol est que c'est agnostique de la plate-forme, il manque donc certains éléments spécifiques à ASP.Net.

Answer 10

bien tester le site extérieur de votre pare-feu/proxy après avoir effacé le cache de votre navigateur. Cela aidera à s'assurer que toutes les ressources sont accessibles au public (et ne sont pas sur un serveur local ou en cache). Par exemple, vous pourriez constater que vous avez utilisé des URL absolues pour inclure, disons, des fichiers JavaScript ou CSS. Ceux-ci fonctionnent très bien dans votre environnement de développement, mais dès que le site devient opérationnel, ils sont inaccessibles. Ou vous avez un fichier CSS dans votre cache qui a ensuite été supprimé, mais vous ne remarquez pas.

Assurez-vous que tous les produits/applications que vous utilisez qui ont des clés qui sont liés à un domaine travailleront sur votre site en direct. Cela inclut des éléments tels que les clés Google Map ou les applications commerciales tierces. Il comprend également des liens hypertexte générés automatiquement dans, disons, des emails. Vous ne voulez pas que l'enregistrement d'un utilisateur ait un lien vers http://localhost/comfirm.aspx ou similaire, n'est-ce pas?