web-dev-qa-db-fra.com

Comment puis-je déployer / pousser uniquement un sous-répertoire de mon dépôt git vers Heroku?

J'ai un projet qui utilise Serve et dont la version est contrôlée à l'aide de Git. Serve crée un dossier output avec des fichiers statiques que je souhaite déployer sur Heroku.

Je ne veux pas déployer le projet Serve lui-même car la pile Heroku Cedar ne semble pas trop l'apprécier, mais surtout je veux profiter de l'excellent support de Heroku pour les sites Web statiques.

Existe-t-il un moyen de déployer un sous-dossier sur une télécommande git? Dois-je créer un dépôt Git dans le dossier output (qui sonne mal) et le pousser vers Heroku?

108
Olivier Lacan

Il existe un moyen encore plus simple via git-subtree . En supposant que vous vouliez pousser votre sortie de dossier comme racine vers Heroku, vous pouvez faire:

git subtree Push --prefix output heroku master

Il semble actuellement que git-subtree soit inclus dans git-core, mais je ne sais pas si cette version de git-core a encore été publiée.

197
anshumans

J'ai eu un problème similaire. Dans mon cas, cela n'a jamais été un problème de tout emporter dans le référentiel heroku et de le remplacer par tout ce qui se trouve dans mon sous-répertoire. Si tel est votre cas, vous pouvez utiliser le script bash suivant. Mettez-le simplement dans votre répertoire d'application Rails.

#!/bin/bash

#change to whichever directory this lives in
cd "$( dirname "$0" )"

#create new git repository and add everything
git init
git add .
git commit -m"init"
git remote add heroku [email protected]:young-rain-5086.git

#pull heroku but then checkback out our current local master and mark everything as merged
git pull heroku master
git checkout --ours .
git add -u
git commit -m"merged"

#Push back to heroku, open web browser, and remove git repository
git Push heroku master
heroku open
rm -fr .git

#go back to wherever we started.
cd -

Je suis sûr qu'il existe de nombreuses façons d'améliorer cela - alors n'hésitez pas à me dire comment!

8
JnBrymn

J'ai commencé avec ce que John Berryman a dit, mais en fait, cela peut être plus simple si vous ne vous souciez pas du tout de l'histoire de Heroku Git.

cd bin
git init
git add .
git commit -m"deploy"
git Push [email protected]:your-project-name.git -f
rm -fr .git

Je suppose que git subtree Officiel est la meilleure réponse, mais j'ai eu du mal à faire fonctionner Subtree sur mon Mac.

7
LessQuesar

Après un long et difficile mois d'essayer différentes choses et de me faire mordre à chaque fois que je réalisais,

simplement parce que Heroku utilise un référentiel git comme mécanisme de déploiement, vous ne devez pas le traiter comme un référentiel git

ça aurait pu être aussi bien rsync, ils sont allés pour git, ne vous laissez pas distraire à cause de cela

si vous le faites, vous vous ouvrez à toutes sortes de blessures. Toutes les solutions susmentionnées échouent lamentablement quelque part:

  1. cela nécessite que quelque chose soit fait à chaque fois, ou périodiquement, ou des choses inattendues se produisent (pousser des sous-modules, synchroniser des sous-arbres, ...)
  2. si vous utilisez un moteur par exemple pour modulariser votre code, Bundler vous mangera vivant, il est impossible de décrire la quantité de frustration que j'ai eu avec ce projet pendant la quête pour trouver une bonne solution pour cela
    • vous essayez d'ajouter le moteur comme lien git repo + bundle deploy - échec, vous devez regrouper la mise à jour à chaque fois
    • vous essayez d'ajouter le moteur en tant que :path + bundle deploy - échec, l'équipe de développement considère :path option comme "vous n'utilisez pas Bundler avec cette option gem" donc il ne sera pas groupé pour la production
    • aussi, chaque rafraîchissement du moteur veut mettre à jour votre Rails stack -_-
  3. la seule solution que j'ai trouvée est d'utiliser le moteur comme /vendor lien symbolique en cours de développement, et copie en fait les fichiers pour la production

La solution

L'application en question a 4 projets en git root:

  1. api - selon le profil fonctionnera sur 2 hôtes heroku différents - upload et api
  2. web - le site web
  3. web-old - l'ancien site Web, toujours en migration
  4. common - les composants communs extraits dans un moteur

Tous les projets ont un vendor/common lien symbolique regardant la racine du moteur common. Lors de la compilation du code source pour le déploiement sur heroku, nous devons supprimer le lien symbolique et rsync son code pour être physiquement dans le dossier du fournisseur de chaque hôte distinct.

  1. accepte une liste de noms d'hôtes comme arguments
  2. exécute un push git dans votre référentiel de développement, puis exécute un pull git propre dans un dossier séparé, en s'assurant qu'aucune modification sale (non engagée) n'est envoyée automatiquement aux hôtes
  3. déploie les hôtes en parallèle - chaque dépôt Heroku Git est extrait, le nouveau code est synchronisé aux bons endroits, avec les informations de base Push dans le commentaire de validation Git,
  4. à la fin, nous envoyons un ping avec curl pour dire aux hôtes amateurs de se réveiller et de suivre les journaux pour voir si tout s'est bien passé
  5. joue Nice avec jenkins aussi: D (code automatique Push pour tester les serveurs après des tests réussis)

Fonctionne très très bien à l'état sauvage avec des problèmes minimes (non?) 6 mois maintenant

Voici le script https://Gist.github.com/bbozo/fafa2bbbf8c7b12d923f

Mise à jour 1

@AdamBuczynski, ce n'est jamais aussi simple.

Tout d'abord, vous aurez toujours un environnement de production et de test au moins - et un tas de clusters spécifiques aux fonctions au pire - tout à coup, 1 dossier doit être mappé sur n projets Heroku comme une exigence assez basique et tout doit être organisé d'une manière ou d'une autre pour que le script "sait" quelle source vous souhaitez déployer où,

2ème, vous voudrez partager du code entre les projets - vient maintenant le sync_common partie, les shennanigans avec des liens symboliques en cours de développement sont remplacés par du code rsynced réel sur Heroku parce que Heroku nécessite une certaine structure de dossiers et un bundler et rubygems vraiment vraiment vraiment mal les choses si vous voulez extraire les fils communs dans une gemme

3ème, vous voudrez brancher CI et cela changera un peu la façon dont les sous-dossiers et le dépôt git doivent être organisés, à la fin dans le cas d'utilisation le plus simple possible, vous vous retrouvez avec le Gist susmentionné.

Dans d'autres projets, je dois brancher Java builds, lors de la vente de logiciels à plusieurs clients, vous devrez filtrer les modules qui seront installés en fonction des exigences d'installation et ainsi de suite,

Je devrais vraiment envisager d'explorer les choses dans un rakefile ou quelque chose et faire tout de cette façon ...

3
bbozo