5139 sujets

Le Bar du forum

Pages :
(reprise du message précédent)

Oula oula oula, c'est là que je vois que je comprends encore pas tout : je fais pas de pull moi Smiley sweatdrop : je travaille mon code, je l'ajoute (add) je l'indexe (commit) sur ma branche develop et je le push sur bitbucket. Automatiquement il est déployé sur mon répertoire ovh de test. Si ça me convient, je merge develop dans master, je push master qui est déployé sur mon répertoire ovh de pré-prod, seule partie que peut voir mon client.
Alors j'ai compris que finalement il faut que je versionne tout (à part d'éventuels password) mais je ne comprends pas à quoi servirait un npm install après chaque pull et surtout pourquoi je ne fais pas des pull alors qu'il te parait logique que j'en fasse...
a écrit :

je travaille mon code, je l'ajoute (add) je l'indexe (commit) sur ma branche develop et je le push sur bitbucket. Automatiquement il est déployé sur mon répertoire ovh de test. Si ça me convient, je merge develop dans master, je push master qui est déployé sur mon répertoire ovh de pré-prod, seule partie que peut voir mon client.


Là c'est moi qui n'ai pas compris ce que tu fais. Le déploiement sur le site de test ou de préprod, tu le fais comment ?

De mon côté je parle de pull parce qu'en fait, tout comme sur ma machine locale, mon site a une copie du dépôt indépendante à lui. Du coup pour mettre à jour le site je n'ai qu'à faire pull et il va tirer les modifications depuis bitbucket ou mon serveur GIT général.
Le pull ne plante jamais vu que sur la copie qui est sur le serveur web, je ne fais jamais de commit (c'est toujours du fast forward)

Pour faire simple, sur mon serveur GIT général, il y a un hook script sur post-update qui, en gros, fait git pull origin master.
Voilà pourquoi je parlais de pull...

C'est une façon de faire mais tu peux bien sûr envoyer ton site avec FTP ou autre chose.

Le gros avantage à avoir une copie de dépôt sur le serveur web que je peux manipuler comme n'importe quel autre dépôt, c'est que si pour une raison ou une autre il faut revenir à une version précédente du site, un git checkout suffit.
Si tu passes par FTP, il faut d'abord clone, pull ou checkout la version qui va bien quelque part (ou en tout cas je ne vois pas comment faire autrement), puis synchroniser le dossier FTP en tenant compte de ce qui a été non seulement modifié mais surtout ajouté/supprimé pour que la copie soit clean. C'est vite compliqué... Avec rsync c'est déjà plus simple de synchroniser proprement, mais même, j'ai l'impression que c'est prendre des contours inutiles quand on peut tout faire avec GIT.
Modifié par QuentinC (12 Aug 2016 - 15:59)
Et bien, comme sur les serveurs mutualisés ovh, git c'est un peu compliqué parce que pas trop adapté, même s'il existe des solutions, je suis plutôt parti sur le script FTPbucket de Thomas Malicet que j'ai installé dans un répertoire sur mon mutualisé :
https://github.com/Wanchai/FTPbucket
Sur bitbucket j'ai créé un webhook qui pointe sur le script avec un trigger sur Repository push.
Donc je code, je versionne sur ma branche dev, je commit, je push et il déploie sur mon espace de test. Une fois testé en ligne sur mon espace de test et satisfait, je merge develop dans master en local, je push et il déploie sur ma pré-prod. Un des trucs que j'ai pas encore capté, c'est la différence entre le merge que je fais de develop à master ou plutôt refaire un add+commit sur master.
Et donc dans cette cuisine là, je n'ai pas de pull.
Maintenant, ça marche, mais je ne sais pas du tout si c'est correct ou efficace. Je suis en train d'essayer de mettre en place git + gulp sur un wordpress, et c'est un poil plus dur pour un néophyte.
Bonsoir,

J'hésite pour versionner un projet wordpress : je versionne à la racine du projet, en gitignorant quelques petites choses ^^
# Keep these files out of the repo
/wp-content/themes/twenty*
/wp-content/upgrade
/wp-content/uploads
/sitemap.*
/wp-config.php
*.sql

# Hidden files
*.DS_Store
*Thumbs.db
*.sass-cache*
*~imageoptim*


Mais ma question est relative au thème : je suis en train de concevoir un thème qui me servira de modèle pour les petites structures. Ce qui veut dire que, pour reprendre la logique WP, je ferai un thème enfant de ce thème lorsque je voudrai créer un projet pour un client. Je pourrai ainsi faire évoluer le thème parent pour des choses globales, et les thèmes enfants pour des choses spécifiques.
Mais quid du versioning... Les 2 thèmes (enfant + parent) ou bien seulement l'un ? Je pencherais pour les 2 mais z'ai un rho doute ^^

Edit : C'est bon, j'ai trouvé mes marques, en versionnement comme en automatisation.
Merci aux intervenants. Smiley smile
Modifié par Manhattan (17 Aug 2016 - 14:25)
Pages :