5139 sujets

Le Bar du forum

Bonjour !

Je pense être dans la bonne section pour poster un sujet qui concerne le développement d'un site.

Premièrement: Je cherche une méthode pour développer mes sites à l'avenir. Jusqu'à maintenant j'utilisais MAMP (Mac) pour développer mes sites en local et ensuite je les upload via ftp. Mais je me rends compte qu'il y a 3 choses qui me dérangent.

- La première est que parfois il y a des différences entre le site en local et le site mis en ligne.

- La deuxième chose est que mon client ne peut pas contrôler la version en cours.

- La troisième est que mon site est sauvegardé sur ma machine mais en cas de pépin, je me dis ça ne serait pas très sérieux de perdre mon travail.

Il y a des personnes qui lance une version prod. en sous domaine du genre: www.prod.monsite.com, j'avais donc penser à m'inspirer de cette méthode et de la combiner avec un logiciel de versioning comme Source Tree (je n'ai jamais utiliser de versioning pour info). Voici comment je vois la chose:

1) Développer mon site en sous domaine. www.prod.monsite.com

2) Quand j'ai jugé qu'il peut être mis en ligne, je le pousse vers www.monsite.com et en même temps je le tire sur mon disque dur (en local). Le but serait d'avoir un système de synchronisation de façon à ce que si mon client fait une connerie sur le site, je peux re mettre à jour à partir de la version prod et il faudrait qu'en parallèle je fasse une sauvegarde régulière automatique de la BBD vers mon ordinateur si des éléments ont été ajoutés entre temps. De plus si jamais le serveur perdait les données du site, j'aurai les fichiers de la version prod et la BDD à jour de la version finale sur mon ordinateur. Ça fait un peu usine à gaz vu comme ça mais j'ai pas trouvé d'autres solutions.

Voici un petit schéma (voir image jointe)...
upload/27370-schema-dep.jpg

Est ce que avec Source Tree cela peut être mis en place ? Sinon comment ?



Deuxièmement: J'aimerai recueillir vos témoignages ? Comment procédez vous ?

Merci d'avance Smiley smile
Il faut distinguer le code et le contenu.

Pour le code, l'utilisation d'un DVCS (git étant le plus populaire, et un des 2 gérés par sourcetree) est incontournable.

Le workflow classique est le suivant: tu commites tes changement en local, tu pousses vers un dépôt git (qui peut être bitbucket, github ou un de tes serveurs). Ensuite, depuis ton site, tu pulles les derniers changements. Ces taches sont automatisables grâce à des utilitaires tels que fabric(python) pu capistrano (ruby).

La mise en place d'un serveur de staging est bien utile pour faire valider des modifs à un client avant la mise en prod effective.

Pour les données (db+fichiers de contenus éventuels), il y a plusieurs solutions, la seule règle incontournable étant d'effectuer des sauvegardes régulières et fréquentes ou de mettre en place un système de réplication.

Concernant les différences d'environnement, c'est rarement un pb si tu as un mac en local. Assure toi d'avoir les mêmes versions de db/langages/libs que sur tes serveurs.
Pour avoir un environnement vraiment identique, il te suffit de virtualiser le système cible, par exemple grâce à Vagrant.
Modifié par paolo (22 Mar 2014 - 09:41)
Merci pour ces infos! Comme je ne suis pas encore très familiarisé avec ce vocabulaire, je résume:

Donc en gros le workflow classique consiste à travailler en local, envoyer les modifications (commit) vers un dépôt git et ensuite je télécharge les derniers changements sur ma machine ?

Sinon je vais m'informer sur Vagrant ! Smiley smile

D'autres avis en attendant ?
+ pour Poalo
Personnellement j'utilise Capistrano, la première configuration peut être un peu laborieuse mais une fois que tout fonctionne, tout devient très facile.

Sinon, pour les plus petits projets, j'utilise l'outil de déploiement de springloops (un fournisseur de dépots SVN). Il permettent de définir des règles pour le déploiement automatique (ou manuel) à partir du dépôt, vers ton serveur. Par exemple, tu peux avoir une version staging qui sera automatiquement mise à jour à chaque commit, et une version de production que tu peux mettre à jour en deux clics à partir de leur interface.

Et un gros +1 aussi pour Vagrant Smiley cligne
Ok merci, je vais voir pour springloops, on m'en avait parlé une fois!
Quand tu dis "qu'il permet de définir des règles de déploiement automatique (ou manuel) à partir du dépôt vers ton serveur". Tu veux parler du dépôt local ou distant (bitbucket/github) ?

Si oui je résume...Je bosses sur mon dépôt en local, je fais mes commit, ça "push" en quelque sorte sur ma version staging? Ensuite depuis l'interface de springloops je peux "pusher" vers la version prod ?

Si c'est ça, cela m'évite de passer par un service comme bitbucket ou github qui sont plus utiles pour collaborer à plusieurs sur un code et faire une sauvegarde autre qu'en local et le serveur où est hébergé le site. Ai je bien compris ?

Après faut que je vois si ça cause problème d'avoir un serveur mutualisé!

edit: je vais aussi jeter un coup d'oeil du côté de capistrano Smiley cligne
Modifié par lj44 (10 Apr 2014 - 13:31)
Administrateur
Bonjour,

une précision : faire des backups et versionner son code sont 2 choses différentes, même si elles peuvent apparaître très similaires.
Une sauvegarde est une copie (et 2 sauvegardes c'est mieux), au cas où l'original aurait un quelconque souci.
Versionner son code, c'est disposer de puissants outils de gestion de celui-ci : log, historique du code et des actions, comparaisons, plusieurs versions, des tests sans conséquence sur le reste du dév et sur la prod, stabilité, travail collaboratif, etc
Et indice que c'est différent : il faut un backup du dépôt commun parce qu'à lui aussi il peut arriver quelque chose...

Pour ce qui est du travail collaboratif : versionner ses fichiers est quasi indispensable pour pouvoir travailler à plusieurs mais ce n'est pas pour autant que travailler seul dispense de versionner son code !
J'ai longtemps travaillé seul sur des projets d'intégration statique et j'utilisais quand même SVN (à l'époque) :
- après en avoir eu marre de récupérer un fichier du backup nocturne,
- après avoir perdu 4H de boulot (refait en 1H puisque je me rappelais ce que je venais de faire : 5H de perdues et gros stress... évitable Smiley confus ),
- après avoir constaté un changement et ne plus savoir d'où il provient,
- parce que je ne me rappelais plus pourquoi/comment j'avais fait comme ça 3 mois avant

Bon quand une précision est aussi longue, c'est du HS, dsl Smiley ravi
Merci pour la nuance, il est bon de la rappeler! Effectivement je travail souvent seul et j'aimerai automatiser ces taches: travail en local > mise à jour sur la version staging > mise à jour vers la version prod. Après pousser vers GitHub/Bitbucket me semble aussi essentiel pour du travail collaboratif et avoir une sauvegarde de la dernière version pushé.
Je suis moi même en pleine réflexion d'amélioration de mon Workflow et j'ai donc choisi Git, Github, et un script Node.Js appelé Dploy qui me facilite le push sur mon serveur "staging" et ensuite sur le "prod", et j'en parle dans un article sur mon propre blog !! J'ai découvert d'autres outils ici que je vais m'empresser de tester, capistrano notamment... merci pour ce sujet intéressant ! Smiley cligne