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 disposant d’un “Build Server”.

Quel est leur but? Pourquoi les développeurs ne construisent-ils pas le projet sur leurs machines locales? Certains projets sont-ils si volumineux que des machines plus puissantes sont nécessaires pour le construire dans un délai raisonnable?

Le seul endroit où un serveur de construction est utile est l’continuous integration avec le serveur de génération qui construit en permanence ce qui est engagé dans le référentiel. Est-ce que je viens de ne pas travailler sur des projets suffisamment importants?

Quelqu’un, s’il vous plaît, éclairez-moi: à quoi sert un serveur de compilation?

La raison donnée est en fait un énorme avantage. Les builds qui vont au QA ne doivent provenir que d’un système qui ne se construit qu’à partir du référentiel. De cette façon, les paquets de construction sont reproductibles et traçables. Les développeurs qui construisent manuellement du code pour tout, sauf leurs propres tests, sont dangereux. Trop de risques que des éléments ne soient pas archivés, qu’ils soient obsolètes par rapport aux changements d’autres personnes, etc., etc.

Joel Spolsky à ce sujet.

Les serveurs de construction sont importants pour plusieurs raisons.

  • Ils isolent l’environnement Le développeur local de Code Monkey dit “Il comstack sur ma machine” quand il ne sera pas compilé sur le vôtre. Cela peut signifier des archivages non synchronisés ou une bibliothèque dépendante est manquante. Jar hell n’est pas aussi mauvais que l’enfer; Dans un cas comme dans l’autre, l’utilisation d’un serveur de compilation est une assurance peu coûteuse que vos builds n’échoueront pas mystérieusement ou ne regrouperont 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 génération, la création de tout emballage de dissortingbution, l’exécution de tests automatisés, la création et la dissortingbution de rapports de génération. L’automatisation est la clé.

  • Ils coordonnent le développement (dissortingbué). 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 dissortingbué mais, selon l’outil, les développeurs peuvent ne pas interagir beaucoup avec le code de chacun. Au lieu de forcer les développeurs à risquer de générer de mauvaises versions ou de fusionner le code de manière trop agressive, concevez le processus de génération où la génération automatisée peut voir le code approprié et traite les artefacts de génération de manière prévisible. De cette manière, lorsqu’un développeur commet un problème avec un problème, par exemple ne pas archiver une nouvelle dépendance de fichier, il peut en être informé rapidement. Faire cela dans une zone intermédiaire permet de marquer le code qui a été créé pour que les développeurs ne tirent pas le code qui briserait leur version locale. PVCS l’a très bien fait en utilisant l’idée de groupes de promotion. Clearcase pourrait aussi le faire en utilisant des étiquettes, mais cela nécessiterait davantage d’administration de processus que beaucoup de magasins ne le souhaitent.

Quel est leur but?
Prenez la charge des 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?
Parce que, avec un logiciel complexe, beaucoup de choses peuvent mal se passer quand on «comstack». problèmes que j’ai effectivement rencontrés:

  • vérifications de dépendances incomplètes de différents types, entraînant la non mise à jour des binarys.
  • Les commandes de publication échouent silencieusement, le message d’erreur dans le journal est ignoré.
  • Construire, y compris les sources locales qui ne sont pas encore engagées dans le contrôle de la source (heureusement, pas encore de boîtes de message “clients”).
  • Lorsque vous essayez d’éviter le problème ci-dessus en construisant à partir d’un autre dossier, certains fichiers choisis dans le mauvais dossier.
  • Le dossier cible où les fichiers binarys sont agrégés contient des fichiers de développement obsolètes qui ne doivent pas être inclus dans la version

Nous avons une augmentation incroyable de la stabilité puisque toutes les versions publiques commencent par un contrôle depuis le source vers un dossier vide. Avant, il y avait beaucoup de “problèmes amusants” qui “sont partis quand Joe m’a donné une nouvelle DLL”.

Certains projets sont-ils si volumineux que des machines plus puissantes sont nécessaires pour le construire dans un délai raisonnable?

Qu’est ce qui est “raisonnable”? Si je lance un lot 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 se terminent, payez-le pour acheter une machine réelle.

Est-ce que je viens de ne pas travailler sur des projets suffisamment importants?

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

Un serveur de génération est un concept distinct d’un serveur d’continuous integration. Le serveur CI existe pour créer vos projets lorsque des modifications sont apscopes. En revanche, un serveur de génération existe pour créer le projet (généralement une version, contre une révision balisée) sur un environnement propre. Cela garantit qu’aucun pirate de développement, réglages, versions de configuration / artefact non approuvés ou code non validé ne figure dans le code publié.

Le serveur de génération est utilisé pour générer le code de tout le monde quand il est archivé. Votre code peut être compilé localement, mais vous n’aurez probablement pas toutes les modifications apscopes par tout le monde tout le temps.

Je suis d’accord avec les réponses concernant la stabilité, la traçabilité et la reproductibilité. (Beaucoup de choses, non?). Ayant UNIQUEMENT travaillé pour de grandes entresockets (Health Care, Finance) avec BEAUCOUP de serveurs de construction, j’appendais que cela concerne aussi la 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 l’examine ou ne la teste … BOOM. Superman III.

Il est nécessaire d’avoir un environnement “propre” exempt d’artefacts des versions précédentes (et des modifications de configuration) afin de garantir que les versions 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 de qualité supérieure.

Une utilisation consiste à simuler une configuration d’utilisateur final type. Le produit peut fonctionner sur votre ordinateur, avec tous vos outils de développement et toutes vos 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 exactement la même configuration que vous. Si vous avez un chemin d’access codé quelque part dans votre code, cela fonctionnera probablement sur votre ordinateur, mais lorsque Dev El O’per essaiera de créer le même code, cela ne fonctionnera pas.

En outre, ils peuvent être utilisés pour contrôler 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 en faute.

Pour append à ce qui a déjà été dit:

Un ex-collègue a travaillé sur l’équipe Microsoft Office et m’a dit qu’une version complète prenait parfois 9 heures. Ça serait nul de le faire sur VOTRE machine, n’est-ce pas?

Pour une qualité constante et pour obtenir la version «hors service» de votre ordinateur afin de détecter les erreurs d’environnement et pour que tous les fichiers que vous oubliez d’archiver dans le contrôle de code source apparaissent également comme des erreurs de génération.

Je l’utilise également pour créer des installateurs car cela prend beaucoup de temps sur le bureau avec la signature de code, etc.

Nous en utilisons un pour que nous sachions 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 la gestion et des tests pour nous. Avec un serveur de compilation, nous soaps toujours que nous pouvons construire notre ligne principale “trunk” à partir du contrôle de version. Nous pouvons créer une installation principale en un clic et la publier sur le Web. Nous pouvons exécuter tous nos tests unitaires chaque fois que le code temporel est archivé pour nous assurer qu’il fonctionne. En rassemblant toutes ces tâches sur une seule machine, il est plus facile de faire en sorte qu’elles soient répétées.

Vous avez raison de dire que les développeurs peuvent construire sur leurs propres machines.

Mais ce sont certaines des choses que notre serveur de construction nous achète, et nous ne sums guère des constructeurs 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 lancer sur le serveur et passer à la tâche suivante. Si les builds sont volumineux, cela signifie que la machine du dev n’est plus occupée. Pour ceux qui font une continuous integration et des tests automatisés, encore mieux.
  • Centralisation. Notre machine de génération comporte des scripts qui génèrent la génération, la dissortingbuent aux environnements UAT et même au staging de production. En les maintenant au même endroit, vous évitez de les synchroniser.
  • Sécurité. Nous ne faisons pas beaucoup de choses spéciales 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 que sur un serveur de génération par certaines entités autorisées.

Peut-être que je suis le seul …

Je pense que tout le monde est d’accord pour dire

  • utiliser un référentiel de fichiers
  • faire des compilations à partir du référentiel (et dans un environnement propre)
  • utiliser un serveur de test continu (par ex. régulateur de vitesse) pour voir si quelque chose est cassé après vos “correctifs”

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 effectuer une version finale, vous exécutez une version à partir du référentiel. Et je suis sûr que vous voulez marquer la version dans le référentiel à ce moment là et non toutes les six heures lorsque le serveur fonctionne.

Donc, peut-être qu’un “serveur de compilation” n’est qu’un abus de langage et qu’il s’agit en fait d’un “serveur de test continu”. Sinon, ça sonne plutôt inutile.

Un serveur de compilation vous donne une sorte de deuxième avis sur votre code. Lorsque vous le cochez, le code est vérifié. Si cela fonctionne, le code a une qualité minimale.

De plus, rappelez-vous que les langages de bas niveau sont beaucoup plus longs à comstackr que les langages de haut niveau. Il est facile de penser “Eh bien, mon projet .Net se comstack en quelques secondes! Quel est le problème?” Auparavant, je devais bricoler avec du code C et j’avais oublié combien de temps cela prenait pour comstackr.

Un serveur de génération 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 et qui peuvent parfois durer plus de deux heures.

Un serveur de génération vous fournit également une base pour un repository fiduciaire, en étant capable de capturer toutes les pièces nécessaires pour reproduire une version dans le cas où d’autres pourraient avoir des droits de propriété.