Quelle est la bonne façon de gérer les scripts des développeurs?

Les développeurs créent des scripts pour les aider dans leur travail. Par exemple, pour exécuter Maven avec certains paramètres, pour supprimer les tâches d'arrière-plan inutiles qui surviennent en cours de développement ou pour se connecter à un certain serveur. Les scripts ne sont pas des scripts de build de base et ne sont pas utilisés dans notre serveur d'intégration continue.

Quelle est la meilleure façon de les gérer? Pour les mettre dans un répertoire (peut-être /scripts) et les archiver dans Git? Pour les maintenir séparément dans un serveur de fichiers?

L'argument pour les traiter comme du code source est qu'ils sont source et peuvent changer. L'argument pour ne pas le faire est qu'il ne s'agit que d'outils auxiliaires et que tous les développeurs n'ont pas besoin d'un script donné (par exemple, des scripts spécifiques à Linux où certains développeurs travaillent sous Windows).

Les scripts de développeur entrent également dans le contrôle de version, car généralement ces scripts dépendent également des éléments du contrôle de version, par exemple les chemins d'accès aux fichiers.

Si ces scripts sont versionnés, ils devraient également fonctionner pour tous les développeurs pour éviter que chaque développeur écrive son propre ensemble de scripts, ce qui devient un enfer de maintenance.

De plus, des corrections de bogues ou des améliorations de ces scripts sont automatiquement déployées pour chaque développeur via le contrôle de version.

En plus de la réponse de @ simon.

En génie logiciel, tout ne concerne pas la programmation, la conception ou la modélisation. Il y a une myriade de tâches que nous effectuons en continu pendant la journée de travail. Vous en avez déjà mentionné un - la construction du projet en dehors de l'IDE - mais il y en a bien d'autres.

Les développeurs expérimentés / proactifs ont tendance à automatiser ces tâches. Certains construisent même des outils lorsque ces tâches font partie du SDLC et qu'elles sont fastidieuses - et sujettes aux erreurs - à faire à la main. Les programmes sont bons pour effectuer des tâches répétitives, peu importe la difficulté. Nous - les humains - ne sommes pas si bons.

Ces outils / scripts ont d'autres effets secondaires positifs

1. Productivité
2. Transfert de connaissances
3. Autonomie (pour les nouveaux arrivants)

Donc, oui, les scripts devraient être dans le SCM et ils devraient être un outil de plus dans la boîte à outils du développeur.

En ce qui concerne le dossier, /scriptsje dirais que cela n'a pas d'importance. Par souci de simplicité, je les laisse dans le répertoire racine du projet afin que toutes les routes déclarées dans les scripts soient relatives au dossier du projet. Si j'ai besoin d'accéder à des dossiers ou fichiers externes, je crée des liens logiciels .

Éléments à considérer avant d'insérer les scripts dans le SCM.

• Pour des raisons de sécurité, assurez-vous que les scripts n'ont pas d'informations d'identification codées en dur - idéalement, les scripts doivent être bien paramétrés -

• Assurez-vous que les scripts ne font pas de choses étranges au système, comme par exemple pour exécuter des commandes qui ne peuvent pas être annulées (la plus courante rm -rf).

• Étant donné qu'ils font partie de la source du projet, la documentation est très appréciée.

• Les scripts ne sont pas sorciers. Rendez les scripts concis. Au lieu d' un seul pour les gouverner tous ... et dans l'obscurité les lier , faire plus, plus petits et concis. Comme si vous appliquiez SRP.

Je vais offrir une opinion un peu plus négative. D'une part, les scripts de développeur qui sont génériques, efficaces et utiles doivent bien sûr être partagés avec d'autres développeurs, et la meilleure façon de le faire est de les faire asseoir avec le code dans le même référentiel.

Cependant, je mettrais une barre haute à l'entrée pour que les scripts soient validés. Les scripts sont du code, tout comme le logiciel lui-même. Cela signifie qu'ils doivent être traités de la même manière que les autres éléments de code:

• Passer en revue le code
• Testé et automatisé si possible
• Considéré lors de la modification de la base de code (en particulier, si un script est utilisé par de nombreux développeurs, une modification qui rompt le script va causer beaucoup de conflits)
• Maintenu (avec tout ce qui implique - priorisation, temps, documentation, etc.).

Il existe un certain nombre d'autres considérations qui s'appliquent davantage aux scripts qu'au logiciel lui-même:

• D'abord et avant tout, il est beaucoup plus difficile de convaincre son organisation et ses parties prenantes d'investir dans la maintenance de scripts qui facilitent la vie des développeurs. Cela signifie qu'il est plus difficile d'obtenir le temps de répondre aux critères ci-dessus - il est facile d'écrire un script qui fonctionne pour vous sur votre environnement, mais le paramétrer, le rendre stable, le documenter prend beaucoup plus de temps. Cela signifie que les scripts peuvent devenir et deviendront du code mort sauf si un développeur peut justifier de maintenir le script à jour.
• Il est beaucoup moins probable que plusieurs développeurs connaissent suffisamment un script compliqué pour le maintenir, ou que plusieurs développeurs se sentent propriétaires du code. Lorsque le développeur d'origine part, il peut être difficile de trouver quelqu'un d'autre à qui s'approprier (et trouver et justifier le temps pour eux d'apprendre le fonctionnement du script peut être encore plus difficile).
• Il est beaucoup plus probable qu'un script interagisse avec la machine du développeur et l'environnement de construction d'une manière ou d'une autre. Il est également très probable que vous ayez plusieurs développeurs avec plusieurs environnements différents. Si un script perturbe un environnement parce qu'il n'a pas été correctement entretenu ou qu'un cas d'angle n'a pas été pris en compte, vous ne vous contentez pas de casser une version nocturne de votre logiciel, vous coûte potentiellement un développeur une journée ou plus de travail pour obtenir son environnement de retour à la normale. Cela peut provoquer du sang et une perte de confiance.
• Parce que les scripts sont souvent externes au logiciel lui-même, leur maintenance peut être un défi. Si les scripts ne sont pas exécutés par le biais d'automatisations, il est facile pour eux de devenir obsolètes ou d'être oubliés, à quel point ils sont devenus du code mort et ne sont que des dettes technologiques que quelqu'un devra prendre le temps de nettoyer.

Pour résumer, les scripts peuvent être très utiles pour un développeur individuel, mais le partage dans le cadre de la base de code elle-même peut être une tâche beaucoup plus difficile, et peut potentiellement causer plus de problèmes que ce qui est résolu.