Quel est le point d’un « serveur de Build » ?

Question

Je n'ai pas travaillé pour les très grandes organisations, et je n'ai jamais travaillé pour une entreprise qui avait un "Serveur de Build".

Quel est leur but? Pourquoi ne sont pas les développeurs de construire le projet dans leur local de machines, ou sont-ils? Sont quelques-uns des projets de si grands que les machines plus puissantes sont nécessaires pour le construire dans un temps raisonnable?

Le seul endroit où je vois un Serveur de Build être utile pour l'intégration continue avec le serveur de build constamment à la construction de ce qui est engagé dans le référentiel. Est-ce que je viens pas travaillé sur des projets assez grand?

Quelqu'un, merci de m'éclairer: Quel est le but d'un serveur de build?

Answer 1

La raison donnée est en fait un énorme avantage. Construit que go d'assurance de la qualité ne doit jamais venir à partir d'un système qui s'appuie uniquement à partir du référentiel. Cette façon de construire les paquets sont reproductibles et traçable. Les développeurs manuellement le code du bâtiment pour tout, sauf à leurs propres tests est dangereux. Trop de risque de trucs pas se faire contrôler, être à jour avec les changements d'autres personnes, etc. etc.

Joel Spolsky sur cette question.

Answer 2

Les serveurs de Build sont importants pour plusieurs raisons.

• Ils isolent l'environnement local Code Monkey développeur dit "Il compile sur ma machine" quand il ne compile pas sur le vôtre. Cela peut signifier out-of-sync check-ins ou elle pourrait signifier une bibliothèque dépendante est manquant. Pot de l'enfer n'est pas loin d'être aussi mauvaise que .l'enfer des dll; de toute façon, à l'aide d'un serveur de build est bon marché d'assurance que vos constructions ne mystérieusement échouer ou forfait le mauvais bibliothèques par erreur.

• Ils se concentrent sur les tâches associées avec les constructions. Cela inclut la mise à jour de la balise de construction, la création de toute distribution de l'emballage, de l'exécution de tests automatisés, la création et la distribution de créer des rapports. L'automatisation est la clé.

• Ils coordonnent (distribué) de développement. Le cas standard est où plusieurs développeurs travaillent sur la même base de code. Le système de contrôle de version est le cœur de ce type de développement distribué, mais en fonction de l'outil, les développeurs ne peuvent pas interagir les uns avec les autres code beaucoup. Au lieu de forcer les développeurs à risque de mal à construire ou à vous inquiéter au sujet de la fusion de code trop agressive, la conception du processus de construction où la version automatique peut voir le code approprié et les processus de la construction des artefacts d'une manière prévisible. De cette façon, lorsqu'un développeur s'engage à quelque chose avec un problème, n'aime pas l'enregistrement d'un nouveau fichier de dépendance, ils peuvent être informés rapidement. Faire cela dans une mise en scène de la zone vous permet de drapeau le code qui a construit de telle sorte que les développeurs ne tirez pas de code qui permettrait de briser leur construction locale. PVCS fait tout à fait bien à l'aide de l'idée de groupes de promotion. Clearcase pourrait le faire aussi à l'aide d'étiquettes, mais aurait besoin de plus de processus de l'administration d'un grand nombre de magasins de soins à fournir.

Answer 3

Quel est leur but?
Prendre la charge de développeur de machines, de fournir une base stable, reproductible à l'environnement construit.

Pourquoi ne sont pas les développeurs de construire le projet dans leur local de machines, ou sont-ils?
Parce qu'avec un logiciel complexe, étonnamment, beaucoup de choses peuvent mal se passer lors du juste "compilation". les problèmes que j'ai réellement rencontré:

• les différentes versions incomplètes vérification des Dépendances, résultant dans des fichiers binaires non mis à jour
• Publier les commandes ne fonctionne pas, le message d'erreur dans le journal ignoré, ancien Dll livré
• Construire, y compris des sources locales ont pas encore été envoyés au contrôle de code source (heureusement, pas de "merde clients" boîtes de message encore..)
• lorsque vous essayez d'éviter le problème ci-dessus par la construction d'un autre dossier, certains fichiers cueillis dans le mauvais dossier
• Dossier de destination où les binaires sont agrégées contient d'autres vicié des fichiers de développeurs de ne pas être publié

Nous avons une stabilité étonnante augmentation depuis tous les communiqués de commencer avec un get à partir de la source de contrôle sur un dossier vide. Avant, il y avait beaucoup de "drôle de problèmes" qui "s'en alla quand Joe m'a donné une nouvelle DLL".

Sont quelques-uns des projets de si grands que les machines plus puissantes sont nécessaires pour le construire dans un temps raisonnable?

Ce qui est "raisonnable"? Si je exécutez un lot de construire sur ma machine locale, il y a beaucoup de choses que je ne peut pas le faire. Plutôt que de payer des développeurs pour les versions pour terminer, payer pour acheter une vraie machine de compilation déjà.

Est-ce que je viens pas travaillé sur des projets assez grand?

La taille est certainement un facteur, mais pas le seul.

Answer 4

Un serveur de build est un concept distinct à un serveur d’intégration continue. Le serveur CI existe pour construire vos projets lorsque des modifications sont apportées. En revanche, un serveur de builds existe pour générer le projet (en général un communiqué, contre une révision étiqueté) sur un environnement sain. Il s’assure qu’aucun développeur hacks, tweaks, les versions non homologués config/artefact ou du code non validée ne rend dans le code publié.

Answer 5

Le serveur de build est utilisé pour générer du code de chacun lorsqu’il est activé. Votre code peut compiler localement, mais très probablement vous n’aurez pas tous les changements faits par tout le monde tout le temps.