Joel semble Un peu du projet que je demande -
Il existe 2 développeurs travaillant sur une application Web Django (Python). Nous avons 1 référentiel SVN. Chaque développeur conserve une checkout et une copie propre de MySQL fonctionnant localement (si vous n'êtes pas familier avec Django, il est fourni avec son propre serveur de test, mais la manière dont les applications ASP peuvent courir à l'intérieur de Visual Studio). Le développement et les tests sont effectués localement, puis revenus au référentiel. La copie de travail réelle du site Web est une caisse SVN (je sais sur SVN Exporter et il faut trop de temps). Le plus proche que nous ayons à un "Build" est un fichier de commandes qui exécute une mise à jour SVN sur la copie de travail, est-ce que les bits Django ("Manage.py Syncdb"), met à jour le cache du moteur de recherche (SOLR), puis redémarrent Apache. < / p>
Je suppose que ce que je ne vois pas est le parallèle aux applications Web.
Faites-vous une application Web contrôlée par la source avec 'Constructions nocturnes' - si oui, à quoi ressemble-t-il?
6 Réponses :
L'intégration continue est utile si vous avez les processus appropriés autour de lui. TeamCity de Jetbrains est un excellent point de départ si vous souhaitez créer une familiarité:
http://www.jetbrains.com/teamcity/index.html
Il y a un excellent article qui concerne directement Django ici:
http://www.ajaxline.com/continue-Itilisation-in -django-projet
J'espère que cela vous obtient.
Les applications Web intégrées dans des langues dynamiques peuvent ne pas nécessiter une étape de "compilation", mais il peut toujours y avoir un certain nombre de étapes "Build" impliquées dans l'exécution de l'application. Vos scripts de construction peuvent installer ou mettre à niveau des dépendances, effectuer des migrations de base de données, puis exécuter la suite de tests pour assurer que le code est "propre" W.R.T. la version vérifiée réelle dans le référentiel. Ou, vous pouvez déployer une copie du code sur un serveur de test, puis exécutez un ensemble d'essais d'intégration de sélénium par rapport à la nouvelle version pour assurer que la fonctionnalité du site corporel fonctionne toujours.
Cela peut aider à faire une certaine lecture sur le sujet de l'intégration continue, qui est un Pratique utile très pour les équipes WebApp Dev. Plus votre processus de développement est rapide et agile, plus vous avez besoin d'une entrée régulière à partir de métriques automatisés de test et de qualité afin de vous assurer que vous échouez rapidement et fort sur une version cassée du code.
+1 Pour être la première réponse que j'ai vue qui combine les idées des aspects de non compilation du processus de construction avec une suggestion d'intégration continue. FWIW, j'ai eu bonne chance avec Cruisecontrol pour une webApp.
Vous pouvez facilement exécuter tous vos tests de l'unité Django via le cadre de test Django comme votre construction nocturne.
C'est ce que nous faisons.
Nous avons également des tests unitaires ordinaires qui ne profitent pas des fonctionnalités de Django, et nous y sommes également.
Même si Python (et Django) n'exige pas le type de test de compilation / lien / unitaire nocturne que les langues compilées font, vous bénéficiez toujours de la discipline quotidienne de "Ne casse pas la construction". Et un cycle quotidien de tester 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 en exécutant nos tests de l'unité 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é Python 3 ne brise pas la construction. Et les exécuter nocturne signifie que nous devons être certains nous refactons correctement.
+1 Les applications Web dans des langues dynamiques ne nécessitent souvent pas de "construction" du tout, mais le test d'intégration continue est fortement recommandé.
J'ai eu un grand succès en utilisant Hudson pour une intégration continue. Détails sur l'utilisation d'Hudson avec Python par Redsolo .
Il y a quelques mois, plusieurs articles espèrent Déploiement continu < / a> a causé une certaine distance en ligne. IMVU a des détails sur la manière dont ils Déployer jusqu'à 5 fois un jour .
L'idée entière derrière des constructions fréquentes (nuit ou plus fréquente comme une intégration continue) consiste à obtenir des commentaires immédiats afin de réduire le temps écoulé entre l'introduction d'un problème et sa détection. Donc, le bâtiment est souvent utile uniquement si vous êtes capable de générer des commentaires via la compilation, des tests (de manière idéalement automatisée), des contrôles de qualité, etc. sans retour, il n'y a pas de point réel.
Si c'est vraiment juste vous et un autre développeur travaillant dessus, les constructions nocturnes ne vont probablement pas vous donner beaucoup.
Je dirais que l'application Web équivalente des constructions nocturnes serait en train de mettre en place des sites (qui peuvent être construits soi-même).
Où construit nuit à une zone de mise en scène, commencer à payer de vrais dividendes est lorsque vous avez des clients, des chefs de projet et des personnes QA qui doivent être capables de voir une version à jour, mais relativement stable de l'application. Vos sandboxes de développeurs (si vous êtes comme moi, au moins) Passez probablement beaucoup de temps dans un état inutilisable, car vous rompez les choses en essayant d'obtenir la prochaine fonctionnalité mise en œuvre. Donc, le problème typique est que une personne QA souhaite vérifier qu'un bogue est corrigé ou qu'un PM souhaite vérifier que certaines fonctionnalités planifiées ont été mises en œuvre correctement, ou un client souhaite voir que vous avez progressé sur la question qu'ils se soucient À propos. S'ils n'ont accès qu'à des bacs à sable du développeur, il y a de bonnes chances que lorsqu'elles se déplacent pour le regarder, la version sandbox ne fonctionne pas (car cela signifie que cela signifie ./MANAGE.PY RUNSERVER est en place dans un terminal quelque part) ou dans un état brisé à cause de quelque chose d'autre. Cela ralentit vraiment toute l'équipe et gaspille beaucoup de temps.
On dirait que vous n'avez pas de configuration de mise en scène car vous venez de mettre à jour automatiquement la version de production. Cela pourrait être bien si vous êtes messages plus prudent et discipliné que moi (et je pense que la plupart des développeurs) suis et ne commettez jamais rien qui ne soit pas totalement pare-balles. Personnellement, je préfère m'assurer que mon travail l'a fait au moins un peu de QA sinueuse par quelqu'un d'autre que moi avant de frapper la production.
Donc, en conclusion, la configuration où je travaille:
Je dirais que je dirais que le seul inconvénient (en plus de un peu de frais généraux supplémentaires dans les bâtiments de la plantation nocturne) est qu'il fabrique une journée de retournement sur la vérification de l'insecte. IE, QA signale un bogue dans le logiciel (basé sur la construction de ce jour-là), le développeur corrige des bugs et les engagements, alors Qa doit attendre que la construction du lendemain soit vérifiée pour vérifier que le bogue est réellement corrigé. Ce n'est généralement pas si un problème car tout le monde a suffisamment de choses que cela n'affecte pas le calendrier. Lorsqu'un jalon est approché et nous sommes dans un mode de fonctionnement congelé, de bugFix uniquement, nous ferons des mises à jour manuelles plus fréquentes du site de stadification.