Comment faire de sshfs + VPN + git un environnement de travail tolérable?


9

Actuellement, la base de code du projet sur lequel je travaille se trouve à distance sur un serveur d'entreprise. et ça doit rester comme ça. le gitréférentiel distant ne peut pas non plus être rendu public.

Ma configuration actuelle est la suivante:

  • Connectez-vous au VPN
  • exécuter sshfspour monter une copie du code
  • commencer à travailler sur le code
  • quand j'ai fini: sshvers le serveur distant et y exécuter des gitcommandes

Le problème avec cela, c'est que le VPN tombe de temps en temps, donc mon sshfsmois se brise et mon IDE se bloque. ce que je fais est de reconnecter manuellement le VPN, puis de réexécuter sshfset de retourner au travail.

Mais cela devient agaçant car les VPNchutes se produisent plus souvent.

Je me demande donc s'il existe des paramètres pour sshfsune sorte de cache, qui me permettraient de travailler et de synchroniser les modifications uniquement lorsque le VPN reviendrait.

Cela peut ne pas avoir de sens, car si le pilote distant n'est pas disponible, il n'y a rien à écrire. Alors qu'en est-il d'une configuration différente qui utilise une watchsorte de chose et utilise rsyncpour déplacer les modifications de manière bidirectionnelle (soit lorsque j'enregistre un fichier, soit quand je le fais git pull)

Je ne peux pas simplement git cloner, car je ne peux pas reproduire tout l'environnement pour travailler «localement» (DB et autres)

le code doit être dans leurs serveurs, pour que je puisse tester / voir mon travail, je dois accéder à une URL, c'est mon bac à sable. Je ne peux pas git push chaque fois que je veux voir mes changements.


3
Pourquoi n'utilisez-vous pas gitla manière saine? Clonez le référentiel et travaillez à distance.
zecrazytux

Je ne peux pas simplement git cloner, car je ne peux pas reproduire tout l'environnement pour travailler «localement», le code doit être sur leurs serveurs, afin que je puisse tester / voir mon travail. J'ai accès à une URL qui est mon bac à sable. Je ne peux pas pousser chaque fois que je veux voir mes changements
Asgaroth

1
Cripes, c'est assez cassé.
EEAA

Comment est-ce une mauvaise question? ce n'est pas comme si je pouvais changer leur infrastructure ou prendre des décisions à ce sujet, j'ai juste besoin d'un moyen de travailler avec eux à distance.
Asgaroth

Réponses:


2

zecrazytux a raison - Pourquoi n'utilisez-vous pas gitla façon dont vous êtes censé: en clonant le référentiel, en travaillant à distance et en repoussant les modifications au maître?

Je ne vois aucune raison pour laquelle vous "ne pouvez pas" git pushtravailler à chaque fois que vous voulez voir vos changements (idéalement en poussant vers une branche de développement qui est ensuite fusionnée lorsqu'elle est testée et éprouvée) - beaucoup de gens le font. Vous pouvez même utiliser un post-receivehook pour déployer vos modifications dans l'environnement si vous souhaitez automatiser cette partie des choses.
(Vous ne VOULEZ évidemment pas le faire , mais vous n'avez donné aucune raison pour laquelle je rejette la prémisse de votre problème.)


Franchement, vous ne pouvez rien faire pour rendre une connexion réseau non fiable «tolérable» (EN PARTICULIER si vous essayez de monter des systèmes de fichiers réseau) - vous pouvez soit travailler à distance comme indiqué ci-dessus, SSH dans le système et travailler directement dessus ( screenest votre ami ici), ou recherchez et corrigez l'instabilité du réseau sous-jacent.
Essayer de faire autre chose pour «le rendre tolérable» est un exercice futile (pensez à «un parapluie cocktail dans un ouragan»).


La raison en est que nous avons redmine et que chaque commit doit avoir un format spécifique. un groupe de validations n'est donc pas acceptable pour une seule tâche. Le fait d'avoir à faire git commit + push, avant d'aller dans le navigateur et de faire un rafraîchissement (F5), le rendrait moins tolérable qu'aujourd'hui. Imaginez devoir engager + pousser, juste parce que j'ai raté un point-virgule (j'exagère, mais vous avez l'idée)
Asgaroth

we have redmine and each commit should have a specific format<- Ainsi, lorsque vous fusionnez le format de la branche de développement, la validation de la fusion est conforme à ce que redmine attend. gitest flexible comme ça :-)
voretaq7

Le point-virgule manquant est simple: ne faites pas d'erreurs (j'exagère, mais vous avez l'idée - vous pouvez exécuter des vérifications de syntaxe statiques par rapport à vos trucs avant de pousser pour éliminer de petites choses comme ça, et puisque Redmine ne va que voir l'engagement de fusion vers le bas, personne n'a besoin de savoir les horreurs qui se sont produites dans votre branche de développement de toute façon) - sinon nous sommes de retour au "travail à distance, à utiliser screenlorsque la connexion s'éteint"
voretaq7

cela pourrait être vrai, mais il me reste à valider + pousser pour voir les changements, bien sûr j'utilise des vérificateurs de syntaxe, vous n'avez pas compris l'idée. mais vous savez que lorsque vous travaillez dans des applications Web, vous devez faire beaucoup de rafraîchissement de page lorsque vous travaillez sur quelque chose, encore une fois commit + puhs le rendrait moins tolérable qu'aujourd'hui.
Asgaroth

Vous devriez pouvoir avoir cette configuration: origine → clone distant → clone local. Une poussée du clone local sera effectuée vers le clone distant (et n'est limitée par aucun élément redmine). Lorsque vous êtes dans un état qui semble approprié pour redmine, vous pouvez pousser le clone distant vers l'origine.
Alfe

0

J'utilise ces options sshfs pour minimiser la latence:

sshfs -o Ciphers=arcfour,compression=no,nonempty,auto_cache,reconnect,workaround=all user@development.net:/usr/local/gitdev/ ~/dev/code

Il a le drapeau de reconnexion, toutes les solutions de contournement sshfs, en utilisant le cache automatique et le chipset arcfour.

Vous pouvez lire ces options sur le manuel sshfs, j'ai trouvé ces options sshfs les plus rapides au moins pour ma configuration.

ETA: Plus d'informations sur les performances de sshfs lire ici: performances de sshfs

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.