Flux de travail GIT à développeur unique (passage d'un FTP simple)


11

J'essaie de décider si le passage à VCS est judicieux pour moi. Je suis développeur web unique dans une petite organisation (5 personnes). Je pense à VCS (Git) pour ces raisons: contrôle de version, sauvegarde hors site, référentiel de code centralisé (accessible depuis la maison).

En ce moment je travaille sur un serveur live en général. Je me connecte par FTP, fais mes modifications et les enregistre, puis télécharge et actualise à nouveau. Les modifications concernent généralement des fichiers de thème / plugin pour les CMS (par exemple Concrete5 ou Wordpress). Cela fonctionne bien mais ne fournit aucune sauvegarde et aucun contrôle de version.

Je me demande comment intégrer au mieux VCS dans cette procédure. J'envisagerais de mettre en place un serveur Git sur le serveur Web de l'entreprise, mais je ne sais pas comment pousser les modifications sur les comptes clients (généralement des VPS sur le même serveur) - pour le moment, je me connecte simplement à SFTP avec leurs coordonnées et je fais les changements directement.

Je ne sais pas non plus ce qui représenterait raisonnablement un référentiel - le site Web de chaque client en aurait-il un qui lui appartienne?

Toute idée ou expérience serait vraiment utile. Je ne pense pas avoir besoin de la pleine puissance de Git, mais le contrôle de version de base et l'accès de facto au cloud seraient vraiment utiles.

EDIT: Je l'ai réduit aux deux options qui semblent les plus sensées. La première est basée sur la réponse de ZweiBlumen , selon laquelle les modifications sont effectuées sur le serveur en direct et validées à partir de là sur le serveur (externe) Git. Cela a l'avantage que mon flux de travail ne changera pas beaucoup (il y a l'étape supplémentaire de faire les commits, mais sinon c'est identique).

La deuxième option consiste à travailler localement à l'aide de XAMPP, puis à valider les modifications à partir de la machine locale. Ce n'est que lorsque le site est en ligne que je télécharge l'article fini sur le serveur Web à partir de la machine locale (immédiatement après la validation finale de Git). Cela semble correct en théorie, mais si le site nécessite des modifications et que je les fais sur le serveur en direct (comme je le fais habituellement), je devrai copier manuellement les fichiers modifiés dans mon référentiel local, puis valider ces modifications dans le Serveur Git. Cela semble indûment complexe et est peut-être trop différent de mon flux de travail actuel.

Je pense que tout compte fait, je vais essayer l'option n ° 1 et voir comment je m'en sors.


1
La chose à retenir à propos de git (ou de tout autre VCS distribué) est que tous les référentiels sont, au moins techniquement, des pairs: votre référentiel local est tout aussi "réel" que celui sur le serveur en direct, ou le référentiel de sauvegarde. Ce sont vos politiques de flux de travail qui leur donnent une structure - donc si vous voulez vraiment continuer à faire le travail principal sur le serveur en direct, vous pouvez ...
comingstorm

Merci, c'est bon à savoir. La flexibilité inhérente de Git fait qu'il est difficile de trouver un point de départ de «meilleures pratiques» - c'est une force du POV d'un utilisateur expérimenté mais sans doute une faiblesse d'un noob!
melat0nin

Réponses:


3

Ce que je fais (avec Subversion, mais fonctionnera également avec Git) est de tout valider dans un référentiel Subversion, mais évidemment divisé en projets, branches, balises si nécessaire. Je vérifie ensuite ces référentiels sur le serveur en direct. Ainsi, lorsque j'effectue une modification sur ma machine de développement et que je la valide dans le référentiel, il s'agit souvent simplement de mettre à jour la copie extraite sur le serveur en direct pour rendre les modifications en direct. Le bonus supplémentaire est que si j'ai besoin de faire une correction rapide sur le serveur en direct, je le valide dans le référentiel depuis le serveur et met à jour la copie de travail sur ma machine de développement.

Je suis sûr qu'il existe d'autres façons de gérer cela, mais je trouve cela assez simple et je suis exactement dans la même situation que vous: développeur unique dans une petite organisation (4 personnes).


1
Merci pour votre réponse! Cela signifie-t-il que vous tirez l'instantané sur votre ordinateur local, effectuez et validez les modifications, puis effectuez une demande de tirage depuis le serveur en direct (par SSHing dans)? Et si le changement est vraiment minime? Exécutez-vous un serveur Web local pour le développement? (Je ne pouvais pas passer par ce processus pour de simples changements CSS .. Je
deviendrais

1
Pour une modification CSS mineure, je ferais la modification directement sur le serveur, puis je validerais cette modification dans le référentiel à partir du serveur. Lorsque je dois faire un travail plus sérieux sur le site, je mettrais à jour le site sur ma machine de développement avec la dernière version du site à partir du référentiel. Je suppose que peu importe où vous effectuez le changement (serveur ou machine de développement) tant que vous le validez dans le référentiel.
ZweiBlumen

Alors, quels outils utilisez-vous pour cela? FTP pour effectuer les modifications de fichier directement sur le serveur, puis une session SSH ouverte en arrière-plan pour effectuer les commits sur le serveur Git de temps en temps?
melat0nin

1
Oui, c'est tout. En fait, j'utilise Subversion. Nous avons des sites sur Windows ainsi que des serveurs Linux. Sur le bureau à distance Windows I, effectuez la modification CSS et validez à l'aide de TortoiseSVN. Sous Linux, j'utilise une session SSH et vim pour effectuer les modifications (mais vous pouvez également FTP vos modifications, je suppose).
ZweiBlumen

Je suis allé avec votre suggestion de modifier sur le serveur puis de valider à partir de là via SSH, ce que je fais depuis quelques jours maintenant. Semble très bien fonctionner, merci!
melat0nin

2

Il est assez facile de créer un post-updatehook qui met automatiquement à jour (l'exportation avec git archiveest préférée pour des raisons de sécurité) le répertoire de données du serveur Web lorsque vous poussez vers une branche spécifique.

Ayez donc un référentiel git installé quelque part (pour des raisons de sécurité, je le mettrais sur un serveur différent du Web) avec un tel crochet. Vous aurez bien sûr besoin d'un serveur de test pour tester des modifications plus importantes, qui peuvent être sur votre machine locale ou mises à jour en poussant vers une branche différente. Dans les deux cas, vous pouvez le contourner pour l'orthographe triviale et les correctifs CSS en faisant simplement un commit et un push.


1

Je suivrais ces étapes:

  1. Configurer le serveur distant avec une paire de clés publique / privée appropriée pour le push / pull à distance
  2. Configurer deux branches test et libération
  3. Développer localement avec un environnement de test dans la branche testing
  4. Lorsque vous êtes satisfait de fusionner avec la branche de publication et de pousser vers le serveur distant
  5. Accrochez le serveur distant pour effectuer la mise à jour vers la dernière version de la version

Configurez un dépôt par site Web pour éviter qu'ils ne s'encombrent. Les branches distinctes vous permettent d'éviter d'avoir le "bon" verrou de version actuel sur ce sur quoi vous travaillez actuellement, qui peut ou non fonctionner.


Je comprends donc bien - il y a deux serveurs (1) pour Git, (2) un serveur Web en direct et une machine de développement local. Le développement se fait localement puis est poussé vers le serveur Git qui a un hook pour mettre à jour le serveur live?
melat0nin

@ melat0nin C'est une façon de le faire. Vous pouvez également faire extraire le serveur en direct du serveur git en tant que tâche cron. Ou, vous pouvez avoir 2 machines. La machine de développement locale et le serveur Web de production en direct. De cette façon, en poussant le référentiel de la machine de développement vers la machine de production, les mises à jour vers la dernière branche de version chaque fois que vous appuyez.
Spencer Rathbun
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.