Comment diminuer le temps de configuration du projet?

Question

Dans notre projet, nous écrivons de nombreux journaux d'application (parfois très utiles) dans le dossier tmp .

Dans ce dossier, nous avons les répertoires des composants, tels que:

• api
• email2sms
• envoi planifié
• facturation
• etc. Moins de 10 dossiers, en résumé.

Le problème: le dossier du nouveau composant apparaît avec le temps - chacun de ces dossiers doit être accessible en écriture.

Il faut donc un certain temps pour que chaque développeur chmodise chacun de ces dossiers dans son environnement local. Il faut également du temps pour chmoder ces dossiers en production.

Comment résoudre ce problème? Comment ce processus peut-il être automatisé (tâche Apache Ant, propriétés SVN, script de l'application - responsable de la tâche)?

Environnement: Environnements de développement - Ubuntu, Windows; production - FreeBSD

Answer 1

La méthode rapide que j'ai utilisée dans la plupart des entreprises pour lesquelles je travaille ressemblait à ceci:

1. Mettez tout le code dans un système de gestion de versions (comme SVN ou quelque chose de ce genre) de sorte que tous les développeurs aient une source unique de fichiers. De toute évidence, vous le faites déjà. Hourra!
2. Mettez à la racine de ce code un fichier nommé setup_permissions.sh qui met à jour tous les éléments de l'environnement local. Cela peut inclure des autorisations, ou ce que vous avez besoin d'exécuter.
3. Tous les matins, tous les programmeurs font svn update , qui met à jour les fichiers, ainsi que le setup_permissions.sh .
4. Ils essaient de lancer leur code. Voir un problème. Ils exécutent setup_permissions.sh .
5. Tout va bien dans le monde!

En ce qui concerne le contenu de setup_permissions.sh , il pourrait s'agir de quelque chose comme:

#/bin/sh
TMP=/tmp

mkdir $TMP/api
mkdir $TMP/email2sms
mkdir $TMP/scheduled_sending
mkdir $TMP/billing
chmod 777 -r $TMP/api $TMP/email2sms $TMP/scheduled_sending $TMP/billing

Et ajoutez toutes les commandes dont vous estimez avoir besoin.
(Oh, et n'utilisez pas chmod 777 ... c'est une idée terrible. Voyez cela à titre d'exemple.)

La clé de cette approche est la discipline . Vous devez faire confiance à vos programmeurs pour qu'ils aient la discipline nécessaire pour exécuter setup_permissions.sh lorsqu'ils mettent à jour leurs environnements locaux. Il en va de même pour quiconque met à jour le système de production.

Vous devez également avoir la discipline nécessaire pour mettre à jour setup_permissions avec les modifications que vous apportez à la structure de répertoires et avec les modifications d'autorisations nécessaires, au lieu de les modifier manuellement sur votre ordinateur et de les laisser. à ce. (Il en va de même pour tous les autres développeurs qui apportent des modifications à la structure de répertoires.)

Answer 2

Celui (programme / composant) qui crée le journal devrait être responsable de rendre les fichiers de journal accessibles en écriture à tout le monde - pour utiliser mod = 777 (tout le monde en écriture) lors de la création des journaux.

si le processus de déploiement comporte un script d'installation, faites-le également dans le script.

Answer 3

mkdir et chmod dans un script shell simple devraient suffire.