Contrôle de version d'un site Web: fichiers frontaux de développement / production

J'essaie de penser à une meilleure façon de contrôler la version de nos projets de site Web. Gardez à l'esprit que je ne suis qu'un développeur front-end, donc je n'ai pas une connaissance approfondie de VCS.

Les workflows changent et les anciennes habitudes de contrôle des versions deviennent obsolètes. Le principal problème est qu'il existe 2 tableaux de fichiers frontaux pour chaque site Web.

L'environnement de développement (moins de fichiers, js non compressés, images, etc.). L'environnement de construction, "gulpified" (tout compressé et non lisible par les humains).

Mais vous ne pouvez pas vendre un site Web avec ses fichiers source. Eh bien, cela ne semble pas tout à fait correct.

Il y a la solution d'avoir 2 dépôts: un build, un dev, avec gulp envoyant des fichiers dev au répertoire de build. Mais c'est un problème à entretenir, avec les petites entreprises, je ne pense pas que ce soit génial. Cela crée beaucoup de repos, et les gens doivent gérer avec plusieurs repos, parfois même avec un seul dépôt svn, des problèmes surviennent.

Il y a donc aussi la solution d'avoir 1 repo: les fichiers source et les fichiers prod dans le même svn. Mais ensuite, il est nécessaire de supprimer les fichiers source lorsque le site Web passe du serveur de développement local au serveur de production (il y a donc différents fichiers dans un même référentiel, en fonction de son emplacement, de son développement ou de sa production ..). D'après ce que j'ai entendu, ce n'est pas bon

Quelle est la bonne façon de gérer un flux de travail frontal Gulp en ce qui concerne le système de contrôle de version?

Une règle de base du contrôle des sources est que vous n'avez qu'à mettre des artefacts écrits manuellement dans le référentiel (les fichiers source d'origine), tout ce qui peut être "compilé" ou "généré" n'a pas besoin d'être stocké là, car cela produira une redondance . On peut (facultativement) stocker des sorties / parties intermédiaires d'un processus de construction dans un référentiel (parfois aussi appelé artefacts), lorsque les étapes pour les reproduire ne sont pas entièrement automatiques, ou à des fins de mise en cache, lorsque les étapes de construction pour reproduire la sortie sont lentes .

Donc, si vous avez un processus entièrement automatisé pour générer les fichiers de production à partir de vos fichiers source de développement, vous n'avez qu'à placer les fichiers de développement dans le contrôle de source (avec les scripts pour créer les fichiers de production). Sinon, établissez un tel processus. Assurez-vous que personne ne doit manipuler les fichiers de production manuellement après leur génération à partir de la source. Si vous souhaitez déployer "directement" à partir de votre VCS, assurez-vous que vous disposez d'un script de déploiement qui tire les fichiers source de développement hors du contrôle de source, effectue la "gulpification" et transfère les fichiers résultants vers la production en une seule étape.

Bien sûr, si vous souhaitez également utiliser le contrôle de code source comme une «sauvegarde médiocre» ou comme cache pour vos fichiers de production, vous pouvez configurer un deuxième référentiel à cet effet et y mettre une copie de la structure du fichier de production après la génération. Ce dépôt ne servira pas au développement, et après sa configuration, vous ne devriez pas avoir à le maintenir manuellement. Assurez- vous donc qu'aucune étape manuelle ne sera nécessaire pour effectuer des sauvegardes dans ce "repo prod" - incluez les étapes nécessaires dans le script de déploiement qui effectue la sauvegarde automatiquement. Pensez à ajouter un script de sauvegarde distinct si vous ne pouvez pas interdire les modifications manuelles de la production après le déploiement. De cette façon, vous pouvez maintenir le processus maintenable même si vous avez des ressources limitées.

Et oui, cela devrait être un deuxième repo strictement séparé, car il a un objectif complètement différent et un cycle de vie différent de celui du repo. Vous l'utilisez uniquement pour les sauvegardes, pas pour le contrôle de code source, qui est un processus différent.