Quel est le but d'une machine de construction dédiée?

En raison d'un certain nombre de circonstances ayant conduit à un déploiement médiocre lors du dernier cycle de génération, j'ai fait campagne dans notre bureau pour effectuer tous les déploiements futurs avec une machine de génération dédiée, et mon patron a accepté cette proposition.

Cependant, au lieu d’utiliser une machine réelle dans notre bureau, nous devons partager une machine unique avec plusieurs autres groupes - et le souci compliqué de devoir quitter mon bureau avec toutes les informations nécessaires, puis de descendre un escalier. dans un autre bureau juste pour effectuer une construction simple, je me demande pourquoi j'ai déjà proposé cela auparavant.

L'idée de disposer d'une machine de construction distincte était, à l'origine, de séparer mon propre code écrit localement de celui de plusieurs autres développeurs et de séparer du déploiement tous les fichiers détournés que j'avais sur ma machine. C'était aussi pour résoudre une préoccupation croissante que j'avais avec notre système de gestion de fichiers ClearCase, qui refuse souvent de me laisser déployer certaines activités de construction à moins que j'aie également inclus une autre activité pour laquelle il a des dépendances.

Maintenant que j'avance dans ce processus, je me demande si j'ai mal compris l'objectif de l'utilisation d'une machine de compilation. Etant donné que nous n'utilisons cette machine que pour le déploiement de code dans nos environnements de test, de stockage intermédiaire et de production, et pas pour nos déploiements de tests de développeur personnels, je ne suis pas sûr que cela serve à quelque chose.

Alors, quelle est la raison réelle pour utiliser une machine de compilation, et est-ce que je suis même près de l’utiliser correctement?

Normalement, vous n'avez pas seulement une machine de construction dédiée, mais vous exécutez également un serveur de construction sur cette machine dédiée. Une machine de construction dédiée offre simplement l’avantage de ne jamais bloquer le travail d’un développeur et de la déployer à partir d’une machine centralisée.

Un serveur de compilation offre beaucoup plus. Un serveur de compilation autorise l’intégration continue (CI), ce qui signifie qu’il construira automatiquement chaque poussée sur votre VCS (comme git), pourra même exécuter des tests unitaires si vous en avez et permet un "déploiement en un clic". Les serveurs de build peuvent vous avertir par mail si les builds ou les tests échouent. Ils offrent des données historiques et des tendances sur ce qui s'est passé.

Les serveurs de build sont généralement accessibles simultanément à plusieurs utilisateurs ou équipes, à l’aide d’une interface Web exécutée dans un navigateur.

Dans le monde Java, Jenkins est l’un des serveurs de build les plus utilisés. Jenkins fonctionne parfaitement bien avec les versions C ++ (car vous semblez utiliser ces deux langages). Jenkins s’appelle serveur d’automatisation, car il peut exécuter toutes sortes de tâches qui ne doivent pas nécessairement être liées à la programmation et à la construction.

En plus de la réponse de Traubenfuchs, vous avez fait allusion à une autre raison pour une machine de construction dans votre question.

Ce n'est pas parce que le logiciel repose sur votre machine que celui de quelqu'un d'autre le sera. Vous pouvez vous fier à certains fichiers aléatoires qui se trouvent sur votre ordinateur (et peuvent même ne pas être sous contrôle de version). Vous pouvez vous appuyer sur une application ou une bibliothèque oubliée appelée à partir d'un script de construction obscur.

Si vous avez une machine de construction dédiée, vous devez savoir ce qui est installé dessus. Cela devrait être bien documenté. S'il est nécessaire de reconstruire le logiciel, des années plus tard peut-être, il ne devrait être nécessaire que de créer une nouvelle machine de construction avec les éléments documentés installés dessus.

La principale raison d'avoir une machine de génération dédiée est d'obtenir des versions cohérentes, quel que soit le créateur. Les postes de travail de développeur sont rarement (lire: jamais) identiques. Il est difficile de savoir que chaque version utilise les mêmes versions exactes de dépendances et de compilateurs, etc. L'un des pires problèmes des versions de dev workstation est que les développeurs peuvent générer à partir de code qui n'est pas archivé dans le contrôle de version.

La plate-forme / le (s) langage (s) que vous utilisez ne sont pas clairs, mais vous devriez idéalement disposer d'un serveur de compilation directement issu du contrôle de source. En d’autres termes, lorsqu’une version est requise, elle récupère le source d’une version donnée du référentiel et le compile automatiquement. Cela nécessite l'utilisation d'outils de génération automatisés pour la génération de scripts. Si vous ne l'avez pas, cela devrait être l'étape n ° 1.

Gardez à l'esprit qu'il n'y a rien de mal à construire localement pour le développement. Vous devez absolument travailler en local sur les tests unitaires, l'analyse de la qualité du code et le perfectionnement des scripts de construction. Sinon, vous perdrez beaucoup de temps. La sortie du serveur de génération concerne tout ce que vous souhaitez potentiellement déplacer en production. Toutes les activités d'assurance qualité telles que les tests d'intégration et d'acceptation ne doivent être effectuées qu'avec des versions du serveur de génération.

Les autres réponses notaient assez correctement que vous devriez automatiser la construction, ce qui signifie qu'il n'est pas nécessaire de se rendre à un autre bureau. Cependant, permettez-moi de vous proposer un certain nombre d'étapes pour améliorer votre processus de construction:

• Premièrement, configurez un accès à distance au serveur de compilation! Si vous construisez manuellement en tapant la commande "make", cela signifie que vous n’êtes plus obligé de vous rendre dans un autre bureau pour taper "make", vous pouvez simplement SSH dans le serveur de compilation et taper "make". Si vous n'utilisez pas encore make ou un système de construction similaire, utilisez-le.
• Deuxièmement, installez un environnement d'intégration continue qui extrait automatiquement les dernières modifications du système de contrôle de version (vous avez un système de contrôle de version, n'est-ce pas? Sinon, ce serait une étape supplémentaire) et les construit. Je recommande Jenkins. Configurez Jenkins pour qu'il exécute également vos tests unitaires et vos tests d'intégration au niveau système (vous avez les deux, n'est-ce pas? Si non, créez-les en partant des tests unitaires pour aboutir aux tests d'intégration au niveau système).
• Troisièmement, si vous rencontrez des problèmes pour partager le même ordinateur avec d'autres équipes (par exemple, si vous avez des opinions divergentes sur le système d'exploitation, la version et la compatibilité à utiliser), envisagez d'utiliser la virtualisation. Un bon serveur peut aujourd'hui exécuter un grand nombre de machines virtuelles. Vous pourriez peut-être configurer vous-même une machine 32 bits et une machine 64 bits pour que vous sachiez que la construction fonctionne sur les deux architectures.
• Enfin, cela peut ne pas être nécessaire: si vous devez absolument disposer d’une machine dédiée, par exemple si les performances de votre application sont d’une grande importance et que d’autres versions / exécutions de tests exécutées simultanément nuisent trop à vos résultats, installez un serveur matériel dédié. seulement vous utilisez. Toutefois, sur des serveurs récents pouvant comporter jusqu'à 40 cœurs de processeur virtuels, voire davantage, il est relativement simple de créer quelques machines virtuelles qui ne partagent pas l'accès aux mêmes cœurs de processeur.

Je considérerais une machine partagée beaucoup mieux que des constructions manuelles. Mon projet actuel utilise maintenant une machine virtuelle, mais en raison du besoin de tests de performance d'intégration au niveau du système, nous passons à un serveur dédié doté de 40 cœurs de processeur virtuels dont les tests de performance nécessitent 17.

... au lieu d'utiliser une machine réelle dans notre bureau, nous devons partager une seule machine avec plusieurs autres groupes ...

Vous dites ça comme si c'était une mauvaise chose.

Vous avez maintenant un serveur de build commun sur lequel toutes vos builds - les vôtres et celles des autres équipes - sont construits. Cohérence de la construction? Vérifier.

[…] le problème de devoir quitter mon bureau avec toutes les informations nécessaires, puis descendre un escalier menant à un autre bureau juste pour effectuer une construction simple, me fait me demander pourquoi je l'ai déjà proposé.

Vous effectuez toujours la construction manuellement et ce n'est pas bon.

Vous avez besoin d'un processus serveur auquel vous soumettez / les demandes de file d'attente pour que des générations soient effectuées en votre nom et ce processus vous renvoie les résultats.

En plus d’autres réponses pertinentes, il semble que vous exécutiez vos versions directement sur la machine en question.

Pour un système de construction fiable, en particulier lors du partage de la machine de construction avec d'autres utilisateurs, il est normal d'exécuter vos générations au sein d'une machine virtuelle. Cela garantit que les autres utilisateurs ne peuvent pas modifier le comportement de vos générations en installant leurs propres versions d'applications ou de bibliothèques dont dépend votre code. Un grand avantage de cela est que la VM peut facilement être sauvegardée et peut également être facilement clonée sur n'importe quel autre PC (y compris votre propre machine de développement).

Il fournit un emplacement centralisé et neutre pour effectuer des constructions, indépendamment de la configuration de librairie de l'EDI, du système d'exploitation et des systèmes de développeurs individuels.

Avec une machine de construction dédiée, vous pouvez la reconstruire chaque fois qu’un code est envoyé au référentiel. Lorsque quelqu'un casse la construction, le processus peut immédiatement envoyer une alerte afin que le problème puisse être corrigé immédiatement.

En plus de rendre tout ce qui est reproductible et fiable et d’assurer que le référentiel ne soit pas rempli de déchets brouillons avec des problèmes de dépendance cachés, cela simplifie la vie des développeurs, car tout ce qu’ils ont à faire pour que la construction fonctionne sur leur machine est de copier ce que vous voulez. est fait sur la machine de construction.