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).
la source
Réponses:
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.
la source
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
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,
/scripts
je 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.
la source
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:
Il existe un certain nombre d'autres considérations qui s'appliquent davantage aux scripts qu'au logiciel lui-même:
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.
la source