Quel est l'intérêt d'un "Build Server"?
Je n'ai pas travaillé pour de très grandes organisations et je n'ai jamais travaillé pour une entreprise qui avait un "Build Server".
Quel est leur but? Pourquoi les développeurs ne construisent-ils pas le projet sur leurs machines locales, ou le sont-ils? Certains projets sont-ils si importants que des machines plus puissantes sont nécessaires pour le construire dans un délai raisonnable?
Le seul endroit où je vois un serveur de build utile est pour une intégration continue avec le serveur de build en construisant constamment ce qui est engagé dans le référentiel. Est-ce que je n'ai tout simplement pas travaillé sur des projets suffisamment importants?
Quelqu'un, veuillez m'éclairer: à quoi sert un serveur de build?
La raison invoquée est en fait un énorme avantage. Les builds qui vont à QA ne devraient provenir que d'un système qui ne construit qu'à partir du référentiel. De cette façon, les packages de génération sont reproductibles et traçables. Les développeurs qui créent manuellement du code pour autre chose que leurs propres tests sont dangereux. Trop de risques que les choses ne soient pas enregistrées, qu'elles soient obsolètes avec les changements des autres, etc. etc.
Les serveurs de build sont importants pour plusieurs raisons.
Ils isolent l'environnement Le local développeur Code Monkey dit "Il compile sur ma machine" quand il ne compile pas sur le vôtre . Cela peut signifier des enregistrements désynchronisés ou une bibliothèque dépendante manquante. L'enfer en pot n'est pas aussi mauvais que l'enfer .dll; Quoi qu'il en soit, l'utilisation d'un serveur de build est une assurance bon marché que vos builds n'échoueront pas mystérieusement ou n'empaqueteront pas les mauvaises bibliothèques par erreur.
Ils concentrent les tâches associées aux builds. Cela inclut la mise à jour de la balise de build, la création de tout package de distribution, l'exécution de tests automatisés, la création et la distribution de rapports de build. L'automatisation est la clé.
Ils coordonnent le développement (distribué). Le cas standard est celui où plusieurs développeurs travaillent sur la même base de code. Le système de contrôle de version est au cœur de ce type de développement distribué, mais selon l'outil, les développeurs peuvent ne pas interagir beaucoup avec le code les uns des autres. Au lieu de forcer les développeurs à risquer de mauvaises builds ou à vous soucier de fusionner le code de manière trop agressive, concevez le processus de build où la build automatisée peut voir le code approprié et traite les artefacts de build de manière prévisible. De cette façon, lorsqu'un développeur commet quelque chose avec un problème, comme ne pas archiver une nouvelle dépendance de fichier, il peut être averti rapidement. Faire cela dans une zone intermédiaire vous permet de signaler le code qui a été construit afin que les développeurs ne tirent pas de code qui casserait leur build local. PVCS a très bien fait cela en utilisant l'idée de groupes de promotion. Clearcase pourrait également le faire à l'aide d'étiquettes, mais nécessiterait plus d'administration des processus que de nombreux magasins ne souhaitent en fournir.
Quel est leur but?
Prenez en charge les machines de développement, fournissez un environnement stable et reproductible pour les builds.
Pourquoi les développeurs ne construisent-ils pas le projet sur leurs machines locales, ou le sont-ils?
Parce qu'avec un logiciel complexe, de nombreuses choses peuvent mal tourner lors de la "simple compilation". problèmes que j'ai rencontrés:
- vérifications de dépendance incomplètes de différents types, entraînant la non-mise à jour des binaires.
- Les commandes de publication échouent silencieusement, le message d'erreur dans le journal est ignoré.
- Build incluant des sources locales non encore engagées dans le contrôle des sources (heureusement, pas de boîtes de message "foutus clients" pour le moment ..).
- Lorsque vous essayez d'éviter le problème ci-dessus en créant à partir d'un autre dossier, certains fichiers ont été sélectionnés dans le mauvais dossier.
- Le dossier cible où les binaires sont agrégés contient des fichiers de développeur périmés supplémentaires qui ne devraient pas être inclus dans la version
Nous avons une augmentation de stabilité incroyable puisque toutes les versions publiques commencent par un contrôle de source sur un dossier vide. Avant, il y avait beaucoup de "problèmes drôles" qui "avaient disparu quand Joe m'a donné une nouvelle DLL".
Certains projets sont-ils si importants que des machines plus puissantes sont nécessaires pour le construire dans un délai raisonnable?
Qu'est-ce qui est "raisonnable"? Si j'exécute une génération par lots sur ma machine locale, il y a beaucoup de choses que je ne peux pas faire. Plutôt que de payer les développeurs pour que les builds soient terminées, payez le service informatique pour acheter déjà une vraie machine de build.
Est-ce que je n'ai tout simplement pas travaillé sur des projets assez grands?
La taille est certainement un facteur, mais pas le seul.
Un serveur de génération est un concept distinct d'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 génération existe pour construire le projet (généralement une version, par rapport à une révision balisée) sur un environnement propre. Il garantit qu'aucun développeur ne hacks, tweaks, versions de configuration/artefact non approuvés ou code non engagé ne parviennent dans le code publié.
Le serveur de génération est utilisé pour générer le code de tout le monde lorsqu'il est archivé. Votre code peut être compilé localement, mais vous n'aurez probablement pas toutes les modifications apportées par tout le monde tout le temps.
Je suis d'accord avec les réponses jusqu'à présent en ce qui concerne la stabilité, la traçabilité et la reproductibilité. (Beaucoup de 'ity, non?). N'ayant jamais travaillé que pour de grandes entreprises (santé, finance) avec de nombreux serveurs de build, j'ajouterais que c'est aussi une question de sécurité. Avez-vous déjà vu le film Office Space? Si un développeur mécontent construit une application bancaire sur sa machine locale et que personne d'autre ne la regarde ou ne la teste ... BOOM. Superman III.
Pour ajouter ce qui a déjà été dit:
Un ancien collègue a travaillé dans l'équipe Microsoft Office et m'a dit qu'une version complète prenait parfois 9 heures. Ce serait nul de le faire sur VOTRE machine, n'est-ce pas?
Il est nécessaire d'avoir un environnement "propre" exempt d'artefacts des versions précédentes (et de modifications de configuration) afin de garantir que les builds et les tests fonctionnent et ne dépendent pas des artefacts. Un moyen efficace d'isoler consiste à créer un serveur de génération distinct.
Ces machines sont utilisées pour plusieurs raisons, toutes essayant de vous aider à fournir un produit supérieur.
Une utilisation consiste à simuler une configuration typique d'utilisateur final. Le produit peut fonctionner sur votre ordinateur, avec tous vos outils de développement et bibliothèques configurés, mais l'utilisateur final n'aura probablement pas la même configuration que vous. D'ailleurs, les autres développeurs n'auront pas la même configuration exacte que vous non plus. Si vous avez un chemin codé en dur quelque part dans votre code, cela fonctionnera probablement sur votre machine, mais lorsque Dev El O'per essaie de construire le même code, cela ne fonctionnera pas.
Ils peuvent également être utilisés pour surveiller qui a cassé le produit en dernier, avec quelle mise à jour et où le produit a régressé. Chaque fois qu'un nouveau code est archivé, le serveur de génération le construit et s'il échoue, il est clair que quelque chose ne va pas et que l'utilisateur qui a commis le dernier est fautif.
Pour une qualité constante et pour que la construction soit "hors de votre machine" afin de repérer les erreurs d'environnement et pour que tous les fichiers que vous oubliez de vous connecter au contrôle de code source apparaissent également comme des erreurs de construction.
Je l'utilise également pour créer des installateurs car ceux-ci prennent beaucoup de temps à faire sur le bureau avec la signature de code, etc.
Nous en utilisons un pour savoir que les boîtes de production/test ont les mêmes bibliothèques et versions de ces bibliothèques installées que celles disponibles sur le serveur de génération.
Il s'agit de gestion et de test pour nous. Avec un serveur de build, nous savons toujours que nous pouvons construire notre ligne principale "trunk" à partir du contrôle de version. Nous pouvons créer une installation principale en un seul clic et la publier sur le Web. Nous pouvons exécuter tous nos tests unitaires chaque fois que le code est archivé pour nous assurer qu'il fonctionne. En rassemblant toutes ces tâches sur une seule machine, il est plus facile de bien faire les choses à plusieurs reprises.
Vous avez raison de dire que les développeurs pourraient s'appuyer sur leurs propres machines.
Mais ce sont certaines des choses que notre serveur de build nous achète, et nous ne sommes pas des créateurs de build sophistiqués:
- Problèmes de contrôle de version (certains ont été mentionnés dans les réponses précédentes)
- Efficacité. Les développeurs n'ont pas à s'arrêter pour créer des builds localement. Ils peuvent le lancer sur le serveur et passer à la tâche suivante. Si les builds sont volumineux, c'est encore plus de temps que la machine du développeur n'est pas occupée. Pour ceux qui font une intégration continue et des tests automatisés, c'est encore mieux.
- Centralisation. Notre machine de build possède des scripts qui font la build, la distribuent aux environnements UAT, et même aux stades de production. Les garder au même endroit réduit les tracas de les garder synchronisés.
- Sécurité. Nous ne faisons pas grand-chose ici, mais je suis sûr qu'un administrateur système peut faire en sorte que les outils de migration de production ne soient accessibles sur un serveur de build que par certaines entités autorisées.
Peut-être que je suis le seul ...
Je pense que tout le monde convient que l'on devrait
- utiliser un référentiel de fichiers
- faire des builds à partir du référentiel (et dans un environnement propre)
- utilisez un serveur de test continu (par exemple, régulateur de vitesse) pour voir si quelque chose est cassé après vos "corrections"
Mais personne ne se soucie des versions construites automatiquement. Quand quelque chose a été cassé dans une construction automatique, mais ce n'est plus le cas - qui s'en soucie? C'est un travail en cours. Quelqu'un l'a réparé.
Lorsque vous souhaitez créer une version finale, vous exécutez une génération à partir du référentiel. Et je suis sûr que vous voulez marquer la version dans le référentiel à que heure et non toutes les six heures lorsque le serveur fait son travail.
Donc, peut-être qu'un "serveur de build" est juste un terme impropre et c'est en fait un "serveur de test continu". Sinon, cela semble à peu près inutile.
Un serveur de build vous donne également une base pour le séquestre, étant en mesure de capturer toutes les pièces nécessaires pour reproduire une build dans le cas où d'autres pourraient avoir le droit de devenir propriétaire.
Un serveur de build est utilisé pour planifier des tâches de compilation (par exemple, des builds nocturnes) de projets généralement volumineux situés dans un référentiel qui peuvent parfois prendre plus de quelques heures.
Un serveur de build vous donne une sorte de deuxième avis sur votre code. Lorsque vous l'enregistrez, le code est vérifié. Si cela fonctionne, le code a une qualité minimale.
De plus, n'oubliez pas que les langages de bas niveau prennent beaucoup plus de temps à compiler que les langages de haut niveau. Il est facile de penser "Eh bien, mon projet .Net se compile en quelques secondes! Quel est le problème?" Il y a quelque temps, j'ai dû jouer avec du code C et j'avais oublié combien de temps il fallait pour compiler.