J'irais jusqu'à envisager d'utiliser git pour le déploiement très bonne pratique .

Les deux problèmes que vous avez énumérés ont très peu à voir avec l'utilisation de git pour le déploiement lui-même. Remplacez .git / par le fichier de configuration contenant les mots de passe de la base de données et vous rencontrez le même problème. Si j'ai un accès en lecture à votre racine Web, j'ai un accès en lecture à tout ce qui y est contenu. Il s'agit d'un problème de renforcement du serveur dont vous devez discuter avec l'administration de votre système.

git offre des avantages très intéressants en matière de sécurité.

1. Vous pouvez appliquer un système pour le déploiement en production. Je configurerais même un hook post-receive pour se déployer automatiquement en production chaque fois qu'un commit vers master est effectué. Je suppose bien sûr un workflow similaire à git flow.

2. git rend extrêmement facile la restauration du code déployé en production vers une version précédente si un problème de sécurité est soulevé. Cela peut être utile pour bloquer l'accès aux failles de sécurité critiques que vous avez besoin de temps pour corriger correctement.

3. Vous pouvez appliquer un système dans lequel vos développeurs doivent signer les commits qu'ils font. Cela peut aider à localiser qui a déployé quoi en production si une faille de sécurité délibérée est détectée.

Il n'y a rien de mal à déployer à partir d'un dépôt git, en fait c'est une pratique assez courante et, comme vous le dites, beaucoup moins sujette aux erreurs que de copier des fichiers via ftp ou rsync.

Compte tenu des informations que vous avez fournies, je noterais les points suivants:

• Ne vous contentez pas d'extraire le dernier master. La production doit être déployée à partir d'une étiquette de version. Utilisez git flow ou similaire pour obtenir un peu plus de processus autour du déploiement du code et de la création des balises. Parce que les balises sont une référence immuable à votre code à un moment donné, c'est plus stable que de pointer vers une branche maître qui pourrait être mise à jour par un commit errant.

• Quant au service du. git, cela ne devrait pas être un gros problème. Redirigez simplement tout ce qui a pour préfixe .git vers un 404 en .htaccess.

• Votre authentification git doit être basée sur une clé ssh, donc aucun mot de passe de dépôt ne doit être stocké sur le serveur.

Hourra pour les workflows de déploiement git!

Je ne suis pas d'accord avec l'opinion populaire ici. Git est pour le contrôle de version, ce n'est pas pour le déploiement / CI.

Les méthodes que les gens préconisent ici sont bien pour les petits projets, mais en général, ne s'adaptent pas très bien.

... ce qui ne veut pas dire que vous ne devriez pas continuer à faire ce que vous faites. Gardez simplement à l'esprit, au fur et à mesure que votre carrière progresse, que les projets sur lesquels vous travaillez dépasseront probablement un flux de travail de déploiement purement basé sur git.

Le principal changement de paradigme est d'arrêter de penser au déploiement de branches, et Commencez à penser au déploiement des résultats de compilation et à l'injection de dépendances d'environnement pour découpler votre infrastructure de votre stratégie de branchement.

Par exemple, pour utiliser le paradigme ci-dessus concernant le «déploiement de fichiers» et la restauration. Si vous étiez déployer des fichiers, vous pourriez conserver plusieurs versions de l'application sur le serveur de production, et si vous avez besoin de revenir en arrière, vous pouvez faire pointer votre serveur Web vers une version plus ancienne en recentrant la racine Web. Deux commandes shell, des microsecondes de temps d'arrêt, moins de marge d'erreur que l'utilisation de git.

Un autre exemple - vous avez le workflow maître standard dev branch> staging branch> master, avec un serveur pour chacun. Vous avez des éléments prêts à être utilisés en développement, mais d'autres éléments sur la préparation ont échoué au contrôle qualité. Vous devez donc effectuer des opérations horribles - supprimer les mauvais commits de la scène, redéployer l'étape, et également supprimer ou corriger les mauvais commits en développement, et espérer que le développement et la mise en scène ne se désynchroniseront pas.

Au lieu de cela, que se passe-t-il si vous coupez une branche de version hors maître, fusionnez les éléments qui sont prêts à entrer dans cette branche de publication et générez le résultat, créez un serveur de test sur AWS et y déployez le résultat, exécutez votre contrôle qualité et tests par rapport à ce serveur intermédiaire temporaire, puis a poussé ce même résultat vers le cluster de production et l'a déployé? Ensuite, désactivez la boîte de transfert temporaire que vous avez créée, fusionnez la version dans le maître et balisez le maître avec un numéro de version.

Ce sont évidemment des exemples extrêmes. Habituellement, ce n'est pas si propre, même si nous voulons que ce soit le cas - vous devez probablement exécuter certains processus de construction dans l'environnement cible, car vous devez apporter des modifications à la base de données. Et si vous avez des mods de base de données non idempotents entre les versions, eh bien, la restauration ne sera pas aussi simple quelle que soit la méthode que vous utilisez, car vous devrez restaurer la base de données (en général, essayez de déployer une base de données idempotente modifications, puis supprimez les bits de base de données obsolètes dans une version ultérieure, une fois que vous êtes sûr qu'ils ne sont plus dans le flux de l'application.

Quoi qu'il en soit, je suppose que je veux en venir, c'est ma réponse à 'Est-ce que l'utilisation de git pour le déploiement est une mauvaise pratique?' est, d'une manière générale, «Oui», de la même manière que l'utilisation de roues d'entraînement est mauvaise pour le vélo. C'est une amélioration par rapport au fait de se casser le cul sur le béton à plusieurs reprises, mais j'espère que vous le dépasserez éventuellement.

Vous pouvez utiliser l'argument --separate-git-dir = <git dir> lors de l'appel de git clone. Cela placera un lien symbolique dans le répertoire .git (symbolique pour Git, je ne pense pas que ce soit un lien symbolique vers votre système d'exploitation), et vous pouvez spécifier le <git dir> quelque part en dehors de la racine du document.

Une autre approche que j'ai adoptée auparavant est quelque chose de similaire au commentaire de Terry Chia concernant les hooks post-receive.

Git a un certain nombre de hooks qui peuvent être utilisés pour effectuer toutes sortes de tâches avant / pendant / après plusieurs actions différentes.

Créez un référentiel nu ailleurs que dans votre dossier Web. Le dépôt nu peut ensuite être utilisé comme à distance pour pousser vers, et un hook post-réception peut être déclenché pour extraire le nouveau code dans un répertoire spécifié.

Cette approche a quelques avantages: L'emplacement de déploiement agit comme une rue «à sens unique» où le code doit passer par le contrôle de code source pour se retrouver en production. Vous pouvez déployer différentes branches / versions vers différents emplacements (tous à partir du même dépôt nu). Il fournit également un moyen simple et agréable de revenir en arrière à l'aide de git checkout standard.Cependant, une mise en garde / conséquence est que les changements de code sur le serveur ne seront pas reflétés dans git (les dépôts nus n'ont pas de répertoires de travail) donc vous auriez pour exécuter manuellement git --work-tree = / path / to / code status pour voir les changements (mais vous ne devriez pas changer le code de production de toute façon, non?)

Je suis d'accord avec Terry Chia pour dire que c'est une très bonne pratique. Il garantit:

• que la révision en place est la bonne,
• avec tous les fichiers nécessaires et vérifie l'exhaustivité de la version,
• rendre la procédure de déploiement rapide et facile

Mais, je dois ajouter qu'il y a des mises en garde que j'ai envie de partager.

Habituellement, dans un dépôt git, vous mettez:

• code,
• docs,
• tests unitaires,
• scripts de déploiement,
• outils d'intégration,
• .deb archives,
• patchs sql
• ou des trucs comme ça, et peut-être un tas d'autres trucs

Eh bien, en production, vous voulez juste le code!

Parce que les documents, les tests unitaires, les outils ou les archives .deb peuvent prendre beaucoup d'espace disque et n'ont rien à voir en production .

Avec Subversion (avant la version 1.7), vous pouviez extraire uniquement le répertoire src / et vous avez tous les avantages, mais avec Subversion> 1.7 et avec Git, vous ne pouvez pas faire cela.

Une alternative serait d'utiliser des sous-modules git pour créer ce type d'archiecture: project repo | - doc | - src -> sous-module vers le repo project-src. \ tests Mais alors votre projet / tests et le code de projet-src ne seraient pas synchronisés et cela serait vraiment nul.

La solution serait alors d'utiliser "sparse checkout", voir: https://stackoverflow.com/questions/600079/how-do-i-clone-a-subdirectory-only-of-a-git-repository

Vous pouvez donc utiliser git , mais faites attention à ces inconvénients.

Voici le script que j'utilise pour créer git to push to prod.

https://gist.github.com/Zamicol/f160d05dd22c9eb25031

Cela suppose que tout ce qui est poussé vers la branche master est prêt pour la production. Toutes les autres branches poussées sont ignorées. Vous pouvez modifier ce script de hook en fonction de vos besoins.

En ce qui vous concerne, je place mon répertoire git sous / var / git et mes fichiers de production ailleurs (comme / var / www) et restreint l'accès à ces répertoires.

Vous pouvez également avoir votre dépôt git sur un serveur distinct de votre serveur de production, puis utiliser quelque chose comme scp et ssh dans le script ci-dessus pour déplacer vos fichiers du serveur git vers le serveur de production. Cela vous permettrait de continuer à utiliser git pour pousser à produire tout en gardant votre code séparé de votre production.