Les constructions quotidiennes sont-elles la voie à suivre pour une application Web?

Question

Joel semble accorde une grande importance aux versions quotidiennes . Pour une application compilée traditionnelle, je peux certes voir sa justification, mais en quoi cela est-il parallèle au développement Web - ou pas?

Quelques mots sur le projet que je demande - Deux développeurs travaillent sur une application Web Django (Python). Nous avons 1 référentiel svn. Chaque développeur maintient une commande et une copie propre de MySQL s’exécutant localement (si vous ne connaissez pas bien Django, il est livré avec son propre serveur de test, de la même manière que les applications ASP peuvent être exécutées dans Visual Studio). Le développement et les tests sont effectués localement, puis validés dans le référentiel. La copie de travail réelle du site Web est une commande SVN (je connais l’exportation SVN et cela prend trop de temps). Le fichier le plus proche de 'build' est un fichier batch qui exécute une mise à jour SVN sur la copie de travail, effectue les bits django ('manage.py syncdb'), met à jour le cache du moteur de recherche (solr), puis redémarre apache.

Je suppose que ce que je ne vois pas, c'est le parallèle avec les applications Web.

Faites-vous une application Web contrôlée par le code source avec des "versions nocturnes"? Si oui, à quoi cela ressemble-t-il?

Answer 1

Vous pouvez facilement exécuter tous vos tests unitaires Django via le framework de test Django en tant que construction nocturne.

C'est ce que nous faisons.

Nous avons également des tests unitaires ordinaires qui n'utilisent pas les fonctionnalités de Django, et nous les exécutons également.

Même si Python (et Django) ne nécessite pas le type de test de compilation / lien / unité nocturne que les langages compilés font, vous bénéficiez toujours de la discipline quotidienne de "Ne cassez pas la construction". Et un cycle quotidien de tests unitaires de tout ce que vous possédez est une bonne chose.

Nous sommes en train de regarder Python 2.6 (qui fonctionne parfaitement pour nous) et d'exécuter nos tests unitaires avec l'option -3 pour voir les fonctionnalités obsolètes que nous utilisons. Avoir une suite complète de tests unitaires nous assure qu'une modification de la compatibilité avec Python 3 ne cassera pas la construction. Et les exécuter tous les soirs signifie que nous devons être sûrs que nous procédons correctement au refactoring.

Answer 2

L'intégration continue est utile si vous disposez des processus appropriés. TeamCity de JetBrains est un excellent point de départ si vous souhaitez vous familiariser avec:

http://www.jetbrains.com/teamcity/index.html

Voici un excellent article qui concerne directement Django:

http://www.ajaxline.com/continuous-integration-in -django-project

J'espère que cela vous aide à démarrer.

Answer 3

Les applications Web construites dans des langages dynamiques peuvent ne pas nécessiter de "compilation". étape, mais il peut toujours y avoir un certain nombre de " build " étapes nécessaires à l'exécution de l'application. Vos scripts de génération peuvent installer ou mettre à niveau des dépendances, effectuer des migrations de base de données, puis exécuter la suite de tests pour vous assurer que le code est "propre". w.r.t. la version archivée réelle dans le référentiel. Vous pouvez également déployer une copie du code sur un serveur de test, puis exécuter un ensemble de tests d'intégration Selenium par rapport à la nouvelle version pour vous assurer que la fonctionnalité de site principale fonctionne toujours.

Il peut être utile de lire un certain nombre d'informations sur le sujet de l'intégration continue, qui est une pratique très utile pour les équipes de développement webapp. Plus votre processus de développement est rapide et agile, plus vous avez besoin d'informations régulières à partir de tests automatisés et de métriques qualité afin de vous assurer d'échouer rapidement et avec force sur toute version endommagée du code.

Answer 4

S'il ne s'agit que de vous et d'un autre développeur, les constructions nocturnes ne vous apporteront probablement pas grand-chose.

Je dirais que l'équivalent dans l'application Web des constructions nocturnes serait des sites de transfert (pouvant être créés toutes les nuits).

Là où les constructions nocturnes dans une zone de transit commencent à porter leurs fruits, c’est lorsque vous avez des clients, des gestionnaires de projet et des agents d’assurance qualité qui doivent être en mesure de voir une version à jour mais relativement stable de l’application. Vos sandbox de développeur (si vous êtes comme moi au moins) passent probablement beaucoup de temps dans un état inutilisable au moment où vous tentez de mettre en place la fonctionnalité suivante. Donc, le problème typique est qu'une personne de l'assurance qualité veut vérifier qu'un bogue est corrigé, ou qu'un PM veut vérifier que certaines fonctionnalités planifiées ont été correctement implémentées, ou qu'un client veut voir que vous avez progressé sur le problème qui les intéresse. sur. S'ils n'ont accès qu'aux bacs à sable des développeurs, il y a de fortes chances que la version bac à sable ne fonctionne pas (car cela signifie que ./manage.py serveur d'exécution est installé dans un terminal quelque part) ou dans un état brisé à cause de quelque chose d'autre. Cela ralentit vraiment l’ensemble de l’équipe et fait perdre beaucoup de temps.

On dirait que vous n’avez pas de configuration intermédiaire, car vous venez de mettre à jour automatiquement la version de production. Cela pourrait aller si vous êtes beaucoup beaucoup plus prudent et discipliné que moi (et je pense que la plupart des développeurs) le suis et ne commettez jamais quoi que ce soit qui n'est pas totalement à l'épreuve des balles. Personnellement, je préfère m'assurer que mon travail a réussi au moins une rapide assurance qualité par quelqu'un d'autre que moi avant de commencer la production.

Donc, en conclusion, la configuration sur laquelle je travaille:

• chaque développeur exécute son propre sandbox localement (comme vous le faites)
• il y a un " commun " mettre en place le bac à sable sur un serveur de dev qui est mis à jour tous les soirs à partir d’un cronjob. Les chefs de projet, les clients et le contrôle qualité y vont. Ils ne bénéficient jamais d'un accès direct aux sandbox des développeurs.
• Il existe un déploiement automatisé (bien que manuellement) en production. Un développeur ou le premier ministre peut "pousser" à la production lorsque nous estimons que les choses ont été suffisamment contrôlées et sont stables et sûres.

Je dirais que le seul inconvénient (à part un peu de temps système supplémentaire pour configurer les versions de mise en veille de nuit), c’est que la vérification des bogues est un jour complet. Ainsi, le contrôle qualité signale un bogue dans le logiciel (en se basant sur la construction nocturne du jour), le développeur corrige le bogue et la validation, puis le contrôle qualité doit attendre la génération du lendemain pour vérifier que le bogue est réellement corrigé. Ce n’est généralement pas un problème car tout le monde a suffisamment de choses à faire pour que cela n’affecte pas le calendrier. Cependant, lorsqu'un jalon approche et que nous sommes en mode gelé de fonctionnalités, avec corrections de bugs uniquement, nous effectuons des mises à jour manuelles plus fréquentes du site de transit.

Answer 5

J'ai eu beaucoup de succès avec Hudson pour une intégration continue. Informations détaillées sur l'utilisation de Hudson avec Python par Redsolo .

Il y a quelques mois, plusieurs articles consacrés au déploiement continu <> / a> fait beaucoup de bruit en ligne. IMVU contient des informations détaillées sur la manière dont déployer jusqu'à 5 fois par an jour .

Answer 6

L’idée de base des builds fréquents (tous les soirs ou plus souvent, comme dans l’intégration continue) est d’obtenir un retour immédiat afin de réduire le temps écoulé entre l’introduction d’un problème et sa détection. Donc, construire fréquemment n’est utile que si vous êtes en mesure de générer des retours d’expérience grâce à la compilation, aux tests (idéalement automatisés), aux contrôles de qualité, etc. Sans feedback, il n’ya pas de réel intérêt.