Comment le code dans le contrôle de version doit-il être stocké?

19

Comment le code dans le contrôle de version doit-il être stocké?

Adapté aux développeurs ? afin que le programmeur puisse rapidement prendre la dernière version et pouvoir s'exécuter à partir de son éditeur sans faire beaucoup de changements? (comme les fichiers de configuration pointant vers dev DB..etc)

ou

Doit-il être convivial pour la production ? la source doit être d'une manière facile à déployer sur l'environnement de production et lorsque le développeur prend la dernière version, il doit effectuer les changements selon ses besoins de développement.

version-control Pavan GR
la source

Réponses:

56

Pourquoi choisir ? Ce devrait être les deux.

Votre environnement de développement doit être configuré de manière à ce qu'il soit aussi simple que de faire une extraction, ouvrir, construire, exécuter, déboguer (par exemple: pas de chemin absolu!). Vous pouvez le faire facilement avec des directives de compilation, une classe de configuration + une injection de dépendance, ou même des astuces comme perso.config dans ASP.NET

Votre script de construction automatisé doit être suffisamment personnalisé pour prendre en charge la configuration de production spécifique, le nettoyage, l'emballage, etc.


la source
Qu'est-ce que perso.config? Un rapide google ne m'a pas aidé.
Tim Murphy
1
Dans le fichier de configuration d'application .NET, vous pouvez référencer un autre fichier de configuration d'application qui, lorsqu'il sera trouvé, remplacera les paramètres spécifiés. Vous pouvez donc créer un fichier dev.config qui remplace des éléments tels que les chaînes de connexion et d'autres éléments, et l'exclure des dépôts.
5
+1 - les développeurs ne devraient pas penser à obtenir la bonne source. Le déploiement en production ne doit pas non plus se produire directement à partir du contrôle des sources, mais avec des pièces correctement construites, testées et traçables . Ce processus devrait être entièrement automatisé.
9

Quand c'est un projet open source où les gens sont censés contribuer, j'opterais certainement pour les développeurs.

Ma plus grande aversion pour les projets open source est que très rarement le référentiel contient toutes les dépendances nécessaires pour construire le code (parfois pour des raisons pratiques ou légales), mais quand elles ne le font pas - certains ne prennent même pas la peine de vous dire quelles dépendances vous avez besoin, ou plus important encore, de la version dont vous avez besoin. (et de préférence d'où les obtenir)

Parfois, vous pouvez passer plus d'une demi-journée à chercher et à compiler plusieurs autres projets afin de construire le projet que vous recherchez.

Bien sûr, cela n'est vraiment pertinent que pour le développement sous Windows.

Mark H
la source
1
Ça me dérange vraiment. Vous le trouvez même sur des OSS très connus.
Tim Murphy
1
Il existe des systèmes qui atténuent ce problème en récupérant automatiquement les dépendances. Par exemple Apache Maven, Ivy ou scons.
sleske
4

Les deux, mais cela dépend de la fréquence à laquelle vous faites votre production. Pour de nombreuses applications personnalisées, les déploiements sont effectués manuellement et localement. D'un autre côté, le développeur valide constamment le code, peu importe la taille du projet. À mon avis, je pense qu'il est plus important de s'assurer que le développeur peut utiliser correctement le contrôle de version, ce qui facilite leur vie afin qu'ils aient le temps de se concentrer sur le code plutôt que de trouver le chemin à travers le contrôle de version.

tia
la source
Les déploiements de production ne devraient pas poser de problème si vous utilisez un moteur de déploiement continu pour créer.
1

Il doit être convivial pour la production, sinon il est problématique de maintenir des versions automatisées.

acéré
la source
8
Pourquoi? Un script de construction automatisé peut effectuer toutes les traductions nécessaires pour restructurer la source en un formulaire déployable. Ne dérangez jamais les gens avec quelque chose que l'automatisation peut résoudre.
Joeri Sebrechts
1

Je suis tout à fait d'accord pour réduire les frictions afin qu'il soit plus facile de faire le travail, mais vous devez également prendre en compte les modes de défaillance.

Si la version du référentiel source est toujours configurée pour une utilisation en production, quel est le résultat d'un développeur qui ne reconfigure pas avant d'exécuter le système? Un développeur exécutant du code contre la production.

Indépendamment de la présence d'autres obstacles dans la manière dont le développeur apporte des modifications aléatoires à la production, la création d'un mode de défaillance qui l'encourage à se produire semble dangereuse.

Je suggère que les valeurs par défaut incluses dans le code validé soient toujours sûres . Vérifiez également les fichiers de configuration de production dans le contrôle de code source, si vous le souhaitez - je le fais presque toujours - mais gardez-les quelque part "pas en direct".

Bevan
la source
0

J'ai tendance à viser une production conviviale. Il garde vos versions propres et empêche les paramètres étrangers de passer en production.

Mike Clark
la source
0

Certainement convivial pour les développeurs, avec des scripts pour automatiser les changements pour le contrôle qualité et la production.

William Payne
la source
-1

Pourquoi ne pas avoir une branche (selon le contrôle de version que vous utilisez - j'utilise Git) pour le code déployable et autre pour la version prête à l'emploi? Cela semble beaucoup mieux et n'est pas si difficile à configurer.

Vous pouvez travailler et valider vos modifications, puis les fusionner sur la version déployable.

Ricardo Souza
la source
Parce que les succursales à longue durée de vie sont coûteuses à gérer et ont tendance à être difficiles à fusionner. Vous devez vous rappeler d'effectuer toutes les modifications sur les deux branches. Il est préférable de rendre les deux versions identiques et / ou d'avoir un script pour générer l'artefact déployable à partir du code prêt à l'emploi.
bdsl