Quels sont les avantages des scripts de construction?

Automatisation.

Lorsque vous développez, uniquement dans les projets les plus simples, le bouton « build » par défaut fera tout ce dont vous avez besoin; vous devrez peut-être créer des WS à partir des API, générer des documents, établir des liens avec des ressources externes, déployer les modifications sur un serveur, etc. Certains IDE vous permettent de personnaliser le processus de construction en ajoutant des étapes ou des générateurs supplémentaires, mais cela signifie seulement que vous êtes générer votre script de construction via les produits de lEDI.

Mais développer un système ne consiste pas seulement à écrire du code. Il y a plusieurs étapes impliquées. Un script indépendant de lEDI peut être exécuté automatiquement, ce qui signifie que:

• Lorsque vous validez une modification du contrôle de version, une nouvelle construction peut être lancée automatiquement par le serveur. Cela garantira que vous navez pas oublié de valider quoi que ce soit nécessaire pour la construction.

• De même, une fois la construction terminée, des tests peuvent être exécutés automatiquement pour voir si vous avez cassé quelque chose.

• Maintenant, le reste de lorganisation (QA, administrateurs système) a un produit construit qui

  a) est parfaitement reproductible uniquement à partir de la version de contrôle.

  b) est commun à tous.

Même lorsque jai travaillé en équipe dun seul homme, jai utilisé des scripts à cette fin; lorsque javais développé le correctif, je mengagerais dans SVN, exporter le SVN dans un autre répertoire et utiliser le script de construction pour générer la solution, qui irait ensuite aux systèmes de pré-production et plus tard à la production. Si quelques semaines plus tard (avec ma base de code locale déjà modifiée) quelquun se plaignait dun bogue, je saurais exactement quelle révision SVN je devrais vérifier pour déboguer correctement le système.

Commentaires

• Cest la meilleure réponse à mon humble avis. Tout le monde a raison avec son idée, mais celle-ci montre vraiment pourquoi vous voulez créer des scripts. Parce quils prennent en charge lautomatisation qui progresse au fur et à mesure que votre projet se développe vous fera gagner beaucoup de temps.
• @Alexus Pas seulement du temps, mais aussi des erreurs stupides. 😉  » La répétition mène à lennui. Lennui mène à des erreurs horribles. Des erreurs horribles mènent à, ‘ Jaurais aimé encore mennuyer.’  » (Vous pouvez également mesurer des erreurs stupides dans le temps, mais ‘ Il est important de réaliser que cela ‘ vous fait gagner du temps pour plusieurs raisons.)
• Même pour les projets individuels, exécuter un serveur Jenkins local pour automatiser le  » construire dans un répertoire séparé  » peut vous aider. Je ‘ travaille sur quelque chose sous Windows dont je dois également confirmer les compilations croisées, donc avoir Jenkins construire et exécuter des tests, puis construire la version compilée croisée me rend beaucoup plus confiant ( et efficace, bien sûr!) quand jai besoin de publier des corrections de bogues.
• Je ne suis ‘ pas daccord avec largument des constructions reproductibles. Il y a tellement de variables incontrôlées dans les systèmes de construction daujourdhui quil est assez difficile dobtenir des versions reproductibles. Votre argument semble que vous obtiendrez cette solution prête à lemploi, ce qui est totalement faux.
• @JonasGr ö ger Automation supprime lun des les plus grandes variables: les humains.

Comme le code, un script de construction est exécuté par lordinateur. Les ordinateurs sont exceptionnellement bons pour suivre un ensemble dinstructions. En fait, (en dehors du code auto-modifiable), les ordinateurs exécuteront la même séquence dinstructions exactement de la même manière, avec la même entrée. Cela offre un niveau de cohérence que, eh bien, seul un ordinateur peut égaler.

En revanche, nous, les sacs de chair remplis deau, sommes tout simplement méprisables quand il sagit de suivre les étapes. Ce cerveau analytique embêtant a tendance à remettre en question tout ce quil rencontre. « Oh … je nai pas besoin de ça » ou « Dois-je vraiment utiliser ce drapeau? Eh … Je « vais simplement lignorer. » De plus, nous avons tendance à devenir complaisants. Une fois que nous « avons fait quelque chose plusieurs fois, nous commençons à croire que nous connaissons les instructions et que nous navons pas à regarder la feuille dinstructions.

De » Le programmeur pragmatique « :

De plus, nous voulons assurer la cohérence et la répétabilité sur le projet. Les procédures manuelles laissent la cohérence au changement; la répétabilité nest pas garantie, surtout si certains aspects de la procédure sont ouverts à linterprétation par différentes personnes.

De plus, nous sommes HILARIEUSEMENT lents dans lexécution des instructions ( sur un gros projet, avec des centaines de fichiers et de configurations, il faudrait des années pour exécuter manuellement toutes les étapes dun processus de construction.

Je vais vous donner un exemple concret. Je travaillais sur des logiciels embarqués, où la plupart du code était partagé sur plusieurs plates-formes matérielles différentes. Chaque plate-forme avait un matériel différent, mais la plupart des logiciels étaient les mêmes. Mais il y avait de petites pièces spécifiques à chaque matériel. Idéalement, les pièces communes seraient placées dans une bibliothèque et liées dans chaque version. Cependant, les pièces communes ne pouvaient pas être compilées dans une bibliothèque partagée. Elle devait être compilée avec chaque configuration différente.

Au début, jai compilé manuellement chaque configuration. Cela ne prenait que quelques secondes pour basculer entre configurations, et nétait pas si pénible. Vers la fin du projet, un défaut critique a été découvert dans la partie partagée du code, où un appareil prendrait essentiellement en charge le bus de communication. Cétait MAUVAIS! Vraiment mauvais. Jai trouvé le bogue dans le code, je lai corrigé et recompilé chaque version. Sauf un. Pendant le processus de construction, jai été distrait et jen ai oublié un. Les binaires ont été libérés, la machine a été construite et un jour plus tard, je reçois un appel téléphonique disant que la machine a cessé de répondre. Je lai vérifié et jai découvert quun appareil avait verrouillé le bus. « Mais jai corrigé ce bug! ».

Je lai peut-être corrigé, mais il na jamais trouvé son chemin sur ce tableau. Pourquoi? Parce que je navais pas de processus de construction automatisé qui construisait chaque version en un seul clic.

Commentaires

• Et vous pouvez aller prendre un café pendant que le le script de construction est en cours dexécution!

Si tout ce que vous voulez faire, cest <compiler> **/*.<extension>, les scripts de construction ne servent pas à grand chose (bien que lon puisse affirmer que si vous voyez un Makefile dans le projet, vous savez que vous pouvez le créer avec make). Le fait est que – les projets non triviaux nécessitent généralement plus que cela – à tout le moins, vous devrez généralement ajouter des bibliothèques et (à mesure que le projet mûrit) configurer les paramètres de construction.

Les IDE sont généralement au moins aussi configurables – mais maintenant, le processus de construction repose sur des options spécifiques à lEDI.Si vous utilisez Eclipse , Alice préfère NetBeans , et Bob souhaite utiliser IntelliJ IDEA , vous ne pouvez « t partager la configuration, et lorsque lun de vous pousse une modification au contrôle de code source, il doit soit modifier manuellement les fichiers de configuration créés par lIDE de les autres développeurs, ou avertir les autres développeurs afin quils « le fassent eux-mêmes (ce qui signifie quil y aura des commits lorsque la configuration de lEDI est incorrecte pour certains IDE …).

Vous devez également trouver comment faire ce changement dans chacun des IDE utilisés par léquipe, et si lun deux ne prend pas en charge ce paramètre particulier …

Maintenant, ce problème dépend de la culture – vos développeurs trouveront peut-être acceptable de ne pas avoir le choix des IDE. Mais les développeurs qui ont de lexpérience avec un IDE sont généralement à la fois plus heureux et plus efficaces lorsquils lutilisent, et les utilisateurs déditeurs de texte ont tendance à être religieusement fanatiques de leur favori. ols, cest donc lun des endroits où vous voulez donner la liberté aux développeurs – et les systèmes de construction vous permettent de faire exactement cela. Certaines personnes peuvent avoir une préférence pour le système de construction, mais ce nest pas aussi fanatique que les préférences de lEDI / éditeur …

Même si vous faites en sorte que tous les développeurs utilisent le même IDE – bonne chance pour convaincre la construction serveur pour lutiliser …

Maintenant, cest pour les personnalisations simples du processus de construction, pour lesquelles les IDE ont tendance à fournir une interface graphique agréable. Si vous voulez des choses plus complexes – comme le prétraitement / la génération automatique de fichiers source avant la compilation – vous devrez généralement écrire un script de pré-construction dans une zone de texte de base dans la configuration de lEDI. Quels systèmes de construction vous auriez encore à coder cette partie, mais vous pouvez le faire dans léditeur réel dans lequel vous écrivez le code, et plus important encore: le cadre du système de construction lui-même fournit généralement un support pour organiser ces scripts.

Enfin – les systèmes de construction sont bons pour plus que la simple construction du projet – vous pouvez les programmer pour faire dautres tâches que tout le monde dans léquipe pourrait avoir besoin deffectuer. Dans Ruby on Rails , par exemple, il existe des tâches système de build pour exécuter des migrations de bases de données, pour nettoyer les fichiers temporaires, etc. Le fait de placer ces tâches dans le système de build garantit que tous les membres de léquipe peuvent les faire de manière cohérente.

Commentaires

• Ce ‘ nest pas seulement une question de différents IDE. Certains développeurs détestent et détestent les IDE de tous types.
• @DavidHammen Je ‘ m lun de ces développeurs (bien que ‘ ai configuré mon Vim si dur est ‘ est possible que jaie pu le transformer en un IDE …), et en écrivant ce paragraphe, jécrivais automatiquement  » éditeurs  » et jai dû le fixer sur IDE, car je pense que le montage sur les IDE est une partie importante de ma réponse. Le demandeur vient clairement du monde des IDE, et la question parle du développement sans IDE comme quelque chose que vous êtes obligé de faire quand il ny a pas dIDE approprié disponible. Le but de cette réponse est de montrer comment les systèmes de build sont bénéfiques, même pour les équipes composées uniquement dutilisateurs IDE.
• Je suis moi aussi lun de ces développeurs. Je ‘ ne veux pas que mes doigts quittent le clavier. Cela interrompt mes processus de pensée.
• Je ne suis pas d’accord. Je préfère les IDE. Ils me permettent de ne pas me soucier des noms, des recherches faciles, du refactoring, de la belle interface utilisateur. Je veux dire, si un IDE peut faire quelque chose pour moi que je ferais autrement avec sed ack, etc., je lutilise.
• Le fait est quavec les scripts de construction, chaque développeur de léquipe peut utiliser ce quil préfère, tandis quavec la fonctionnalité de construction de lEDI ‘, vous obligez tout le monde non seulement à utiliser un IDE, mais aussi à utiliser lIDE très spécifique pour lequel le projet est configuré (sauf si vous lavez configuré pour plusieurs IDE, et bonne chance pour la synchronisation …)

De nombreux IDE regroupent simplement les commandes utilisées pour construire quelque chose, puis générer un script et lappeler!

Par exemple, dans Visual Studio, vous pouvez voir les paramètres de ligne de commande pour une compilation C ++ dans la zone « ligne de commande ». Si vous regardez attentivement la sortie de la compilation, vous verrez le fichier temporaire contenant le script de compilation qui a été utilisé pour exécuter la compilation.

De nos jours, tout est MSBuild , mais qui est toujours exécuté directement par lEDI.

Donc, la raison pour laquelle vous utilisez la ligne de commande est que vous allez directement à la source et que vous sautez lintermédiaire, un intermédiaire qui pourrait avoir été mis à jour ou nécessiter un tas de dépendances dont vous navez simplement pas besoin sur un serveur headless qui agit comme votre intégration continue (CI)

De plus, vos scripts font plus que les étapes habituelles orientées développeur pour lesquelles ils sont conçus.Par exemple, après une compilation, vous souhaiterez peut-être que vos fichiers binaires soient emballés et copiés dans un emplacement spécial, ou quun package dinstallation soit créé ou quun outil de documentation sexécute sur eux. De nombreuses tâches différentes sont effectuées par un serveur CI qui sont inutiles sur une machine de développement, donc si vous pouvez créer un projet IDE qui effectue toutes ces étapes, vous devez ensuite en maintenir deux – un projet pour les développeurs et un autre pour les builds. Certaines tâches de construction (analyse statique par exemple) peuvent prendre beaucoup de temps que vous ne voudriez pas pour les projets de développement.

En bref, cest juste plus facile – créez un script pour faire tout ce que vous voulez et cest rapide et simple de lancer cela sur la ligne de commande ou une configuration de serveur de compilation.

make 

est beaucoup plus facile à retenir et à taper que

gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h 

Et les projets peuvent avoir des commandes de compilation très complexes. Un script de construction a également la capacité de ne recompiler que les choses qui ont changé. Si vous voulez faire une compilation propre,

make clean 

est plus facile et plus fiable une fois configuré correctement que dessayer de se souvenir de chaque endroit où un fichier intermédiaire peut avoir été produit.

Bien sûr, si vous utilisez un IDE, il est également facile de cliquer sur un bouton de construction ou de nettoyage. Cependant, il est beaucoup plus difficile dautomatiser le déplacement du curseur vers un endroit spécifique de lécran, en particulier lorsque cet endroit peut bouger si la fenêtre bouge, que dautomatiser une simple commande de texte.

Comment feriez-vous autrement? La seule autre façon est de spécifier une longue commande de ligne de commande.

Une autre raison est que Les makefiles permettent une compilation incrémentielle, ce qui accélère beaucoup le temps de compilation.

Makefiles peut également créer un processus de construction multiplateforme. CMake génère différents scripts de construction basés sur la plate-forme.

Modifier:

Avec un IDE, vous êtes lié à une façon particulière de faire les choses. Beaucoup de gens utilisent vim ou emacs même sils nont pas beaucoup de fonctionnalités de type IDE. Ils le font parce quils veulent la puissance les éditeurs fournissent. Les scripts de construction sont nécessaires pour ceux qui nutilisent pas dEDI.

Même pour ceux qui utilisent un IDE, vous voudrez peut-être vraiment savoir ce qui se passe, donc le script de construction vous offre les détails les plus bas de la mise en œuvre quune approche GUI na pas.

Les IDE eux-mêmes utilisent souvent des scripts de construction en interne aussi; le bouton Exécuter est juste une autre façon dexécuter la commande make.

Les réponses ci-dessus couvrent beaucoup de bonnes raisons, mais un exemple concret que jaimerais ajouter (que je ne peux pas ajouter en tant que commentaire faute de karma), provient de la programmation Android.

Je suis un professionnel Android / iOS / Windows Développeur de téléphone, et jutilise les API de services Google (principalement Google Maps) a lot .

Sous Android , ces services nécessitent que jajoute un keystore , ou un type de fichier didentification de développeur qui indique à Google que je suis qui je dis que je suis, dans une console de développeur. Si mon application est compilée avec un fichier de clés différent, la section Google Maps de lapplication ne fonctionnera pas.

Au lieu dajouter et de gérer une douzaine de keystores à la console développeur, dont un seul peut effectivement être utilisé pour mettre à jour lapplication de toute façon, jinclus ce keystore dans notre référentiel sécurisé et utilisez Gradle pour indiquer exactement à Android Studio le keystore à utiliser lors de la construction pour « déboguer » ou « publier ». Maintenant, je nai plus quà ajouter deux keystores à ma console de développement Google, un pour « déboguer » et un pour « release », et tous les membres de mon équipe peuvent cloner le dépôt et commencer à développer sans avoir à accéder au développement. console et ajoutez le hachage SHA de leur keystore particulier, ou pire, me faisant les gérer . Cela a lavantage supplémentaire de donner à chaque membre de léquipe une copie du keystore de signature, ce qui signifie que si je suis absent du bureau et quune mise à jour est prévue, un membre de léquipe na quà suivre une très courte liste dinstructions afin de pousser un mise à jour.

Lautomatisation de la construction comme celle-ci maintient la cohérence des versions et réduit la dette technique en réduisant considérablement le temps de configuration lorsque nous avons un nouveau développeur, une nouvelle machine ou lorsque nous devons ré-image dun machine.

Avantages du script de création:

• les modifications ressemblent à du code (pour exemple, dans une commande git diff), pas comme différentes options cochées dans une boîte de dialogue

• créant plus de sortie quune simple construction

Dans certains de mes projets précédents, jai utilisé les scripts de construction pour:

• générer la documentation du projet (basée sur doxygen)
• build
• exécuter des tests unitaires
• générer des rapports de couverture de test unitaire
• regrouper des binaires dans une archive de version
• générer des notes de version internes (basées sur des messages « git log » )
• tests automatisés

Vous pouvez souvent appeler le bouton « build » de manière automatisée (Visual Studio accepte les arguments de ligne de commande, par exemple). Les gens écrivent des scripts de construction dès quils ont besoin de quelque chose que le bouton de construction ne peut pas fournir.

Par exemple, la plupart des IDE vous permettent uniquement de créer une plate-forme à la fois. Ou une seule langue à la fois. Ensuite, il y a ce que vous faites avec les sorties construites: votre IDE peut-il tous les regrouper dans un package dinstallation?