Comme pour tous les projets web, lorsque le site est en ligne, vous aurez besoin d'un support et d'un développement continu. Nous mettons généralement en place un site BETA pour montrer à nos clients à quoi il ressemblerait afin qu'ils puissent l'approuver. Pour les sites très grands ou très programmés, quelqu'un a-t-il une bonne méthode pour gérer le développement et le déploiement en ligne du site ?
Réponses
Trop de publicités?
Traveling Tech Guy
Points
6975
En supposant que votre site utilise une base de données et d'autres services côté serveur (files d'attente, services web, autres couches de données, etc.), je recommande d'avoir un environnement de staging pour héberger la version beta/pré-prod - complète avec des données fabriquées et des scénarios de démonstration préparés à l'avance.
Le site de production doit pointer vers une version de production de la base de données et des services web, et le flux de données doit rester pur de données de démonstration.
En bref, ma recommandation est de reproduire l'environnement de production (dans la mesure du possible) et d'héberger le site beta dans un environnement séparé.
Jan Jongboom
Points
15148
Un environnement OTAP (abrégé en néerlandais) (Développement Test Acceptation Production) devrait faire l'affaire. Le développement et les tests sont réalisés en interne, l'acceptation et la production sont deux environnements distincts gérés par les administrateurs serveur. Chaque version doit d'abord être publiée en Acceptation, où le client et le service de développement peuvent accepter ou rejeter la version. Après une acceptation, la même version sera publiée en production.
-edit: Essayez de synchroniser les données de production en acceptation avant chaque publication, afin d'assurer une compatibilité maximale-
Dryadwoods
Points
861
Dans les versions BETA en ligne/publiques, je pense que les services de google sont un bon exemple.
Si vous avez un bon moyen financier, vous pouvez héberger vos environnements BETA et finaux sur des machines/serveurs/services différents. Plus tard, il vous suffit de rediriger les demandes vers les serveurs que vous souhaitez sur l'état actuel de l'application.
Si vous n'avez qu'une seule machine ou peu de ressources, je pense que le meilleur moyen est toujours de découpler l'application autant que possible, de manière à pouvoir mettre à jour un module sans planter l'application (sans perdre les sessions, les flux de transaction/action).
.
Autre chose à garder à l'esprit est de savoir si ce site web sera utilisé par des clients du monde entier (nécessite une inscription) et une certaine production de données, dans ce cas je pense que le meilleur moyen est toujours de partager le même stockage de données (base de données) dans la version BETA et la version finale.
Simon Scarfe
Points
2831
Écrivez autant de scripts que possible. Il y aura inévitablement des différences de configuration, etc., et il est vital de faire de votre mieux pour réduire les chances d'erreur humaine. De bons outils incluent Capistrano, Fabric et Ant (si vous êtes sur Windows, vous pourriez également envisager NAnt ou MSBuild).
J'aime avoir un environnement de pré-mise en scène (développement partagé), qui est actualisé par un script similaire activé à chaque fois qu'il y a un accroche-post-commit dans le système de contrôle de versions.
