Besoin de conseil - Serveur de dev

Version imprimable

04/06/2010, 20h57
Sebish

Besoin de conseil - Serveur de dev

Bonjour,

Je suis actuellement en train de revoir un peu le système de développement web de ma boite. Je voudrais faire les choses bien donc j'aurais besoin de quelques conseils.

Pour l'instant j'ai juste tout ce qu'il faut en local sur ma bécane. Je créé un sous-domaine dev.nomdusite.com sur l'hébergement mutualisé du client et quand c'est validé je met ça sur le www puis je sauvegarde le tout sur un HD externe. Bon ça fait assez amateur mais pour le moment ça me suffisait.

Maintenant, on va être plusieurs à bosser et il me faudrait quelques conseils pour organiser tout ça. Voilà ce que je souhaiterais avoir au final mais malheureusement, je ne sais pas si tout est réalisable:

- Avoir un serveur dédié qui pourrait supporter PHP et RoR.
- Pouvoir travaillé directement sur le serveur sans avoir à installer des trucs en local.
- Pouvoir travaillé sur le serveur pas internet même si on est à perpette les oies.
- Avoir un système de gestion de versions.
- Que le serveur servent également pour les save/backup
- Qu'il y ait plusieurs versions pour les sites (dev, test, stage)
- Que les clients puissent aller sur le stage pour voir le site
- Qu'on puisse mettre le site en ligne depuis la version stage vers le serveur de prod du client.

La question est : Est ce que tout ça est réalisable ?
Je suis preneur de tout liens/conseils/infos/tutos qui peut avoir un lien même éloigné sur le sujet.

Merci d'avance aux âmes charitables qui m'aiguilleront dans ma quête vers un travail plus organisé !
Seb
04/06/2010, 22h03
_Mac_

Citation:

Envoyé par Sebish

- Avoir un serveur dédié qui pourrait supporter PHP et RoR.

Un serveur dédié c'est un serveur dont tu as le contrôle quasi total, donc tu y installes ce que tu veux : PHP et RoR par exemple. Et comme tu le contrôles pas seulement au niveau d'un seul site Web, tu peux écrire des scripts pour automatiser certaines tâches, comme par exemple passer d'un staging à une prod.

Citation:

Envoyé par Sebish

- Pouvoir travaillé directement sur le serveur sans avoir à installer des trucs en local.

Mauvaise idée surtout si vous êtes plusieurs à travailler. Généralement, chaque développeur a son serveur (en local la plupart du temps) sur lequel il peut tester tout ce qu'il veut, faire planter des trucs sans embêter ses copains. Quand il a un truc qui va bien, il stocke son dev dans un outil de gestion de conf. Après, on a la phase d'intégration plus ou moins automatisée et fréquente. Là, on fait plein de choses et en particulier installer tout le dev (de tous les développeurs) sur un serveur dit d'intégration. Pour le coup, ça peut être sur ton serveur dédié sur Internet, mais je déconseille vivement de développer directement sur le serveur distant et surtout à plusieurs en même temps. Après la phase d'intégration, on a la recette qui peut se faire sur le staging, puis on a la prod.

Citation:

Envoyé par Sebish

- Pouvoir travaillé sur le serveur pas internet même si on est à perpette les oies.

C'est un peu le principe d'un serveur sur Internet. Le seul truc qui peut faire qu'on ne peut pas tout faire de partout, c'est la sécurité. Depuis chez toi, tu pourras tout faire, mais depuis le réseau d'un client par exemple, tu ne pourras peut-être pas faire de telnet ou de SSH, voire du FTP, sur le serveur car ces protocoles sont bloqués en sortie.

Citation:

Envoyé par Sebish

- Avoir un système de gestion de versions.

C'est indispensable. A voir où on le met. Ca peut être sur le serveur dédié mais je ne suis pas sûr que ce soit la meilleure solution. Je n'ai pas trop d'avis sur la question.

Citation:

Envoyé par Sebish

- Que le serveur servent également pour les save/backup

Tu veux dire quoi ? Que le serveur soit sauvegardé, c'est indispensable. Que tu y déposes des sauvegardes de ton PC par exemple, c'est plus discutable.

Citation:

Envoyé par Sebish

- Qu'il y ait plusieurs versions pour les sites (dev, test, stage)

Pourquoi pas, c'est parfaitement faisable, surtout sur un dédié.

Citation:

Envoyé par Sebish

- Que les clients puissent aller sur le stage pour voir le site

Oui, c'est possible.

Citation:

Envoyé par Sebish

- Qu'on puisse mettre le site en ligne depuis la version stage vers le serveur de prod du client.

Oui, en développant un script spécifique, par exemple. C'est faisable dans le cas d'un serveur dédié. Avec un mutualisé, c'est beaucoup plus difficile à faire.
04/06/2010, 22h42
Sebish

Merci bien Mac, pour toutes ces infos, ça m'est bien utile. Pour le coup j'ai quelques questions supplémentaires ;).

Citation:

Un serveur dédié c'est un serveur dont tu as le contrôle quasi total, donc tu y installes ce que tu veux : PHP et RoR par exemple.

Ça me plait bien ça !

Citation:

Mauvaise idée surtout si vous êtes plusieurs à travailler. Généralement, chaque développeur a son serveur (en local la plupart du temps) sur lequel il peut tester tout ce qu'il veut, faire planter des trucs sans embêter ses copains.

Je pensais justement que c'était le but du système de gestion de contrôle d'empêcher un dev de tout écrabouiller sur un serveur. Si c'est pas conseillé, ça limite grandement l'intérêt de l'affaire. Comment ça se passe alors si on est plusieurs à travaillé sur un même projet, en même temps et chacun sur sa machine en local ? On ne risque pas de zapper des trucs qu'un autre à déjà fait au moment de l'upload ?

Citation:

C'est un peu le principe d'un serveur sur Internet. Le seul truc qui peut faire qu'on ne peut pas tout faire de partout, c'est la sécurité. Depuis chez toi, tu pourras tout faire, mais depuis le réseau d'un client par exemple, tu ne pourras peut-être pas faire de telnet ou de SSH, voire du FTP, sur le serveur car ces protocoles sont bloqués en sortie.

Ici ton conseil est donc de télécharger le fichier en local, travaillé dessus et le remettre sur le serveur une fois finis, c'est ça ?

Merci beaucoup en tout cas de te pencher sur mes questions (même s'il elles semblent parfois stupides).
05/06/2010, 00h11
_Mac_

Citation:

Envoyé par Sebish

Je pensais justement que c'était le but du système de gestion de contrôle d'empêcher un dev de tout écrabouiller sur un serveur. Si c'est pas conseillé, ça limite grandement l'intérêt de l'affaire.

Non. Un système de gestion de version sert juste à stocker des fichiers et à gérer différentes versions de ces fichiers. Ce n'est pas parce qu'on utilise un tel outil qu'on ne peut plus écrabouiller des trucs, bien au contraire !!! Ne rien écraser par inadvertance, c'est une question de méthode et le système de gestion des versions fait partie de cette méthode mais ce n'est pas tout. Le reste de cette méthode, je l'ai déjà décrit et j'en reparle plus bas.

Citation:

Envoyé par Sebish

Comment ça se passe alors si on est plusieurs à travaillé sur un même projet, en même temps et chacun sur sa machine en local ? On ne risque pas de zapper des trucs qu'un autre à déjà fait au moment de l'upload ?

Relie ce que j'ai dit. Pour éviter justement d'écraser ce qu'a fait le copain en développant, chaque développeur a un truc pour développer seul dans son coin. Quand le code est jugé stable, il est poussé dans le système de gestion de version. De ce système, on extrait l'ensemble du code de l'application ou du site qu'on pousse alors sur un serveur unique appelé serveur d'intégration.

Citation:

Envoyé par Sebish

Ici ton conseil est donc de télécharger le fichier en local, travaillé dessus et le remettre sur le serveur une fois finis, c'est ça ?

Pas nécessairement. Tout dépend de ce que tu appelles "en local" et de la façon dont tu veux que ça se passe. Si ton serveur dédié est sur le réseau de ton entreprise et que tu bosses depuis le réseau local de ton entreprise, tu peux faire tout ce que tu veux sur le serveur à tout moment. En revanche, si le serveur est sur le réseau de ton entreprise mais que tu prévois de développer depuis chez toi ou ton client, tout de suite ça devient plus difficile de travailler sur le serveur car il n'est généralement pas accessible depuis l'extérieur de ton entreprise. Si ton serveur est sur Internet, c'est plus simple mais certaines choses ne sont pas possibles dans certains cas car dès qu'il s'agit de franchir différents réseaux (passer d'un réseau local (chez toi ou une entreprise) à Internet, c'est un franchissement de réseau) des difficultés potentielles peuvent apparaître.
05/06/2010, 02h31
Sebish

Ok je commence à comprendre un peu mieux l'idée générale.

Donc, si je récapitule on a une machine installé dans la boite qui contient :
- Un système de version control
- Apache
- MySQL
- Php
- Ruby

Quand le dev a fini son affaire sur sa propre machine, il envoit ça sur le système de controle de version. Et la le CSV se synchronise avec le serveur d'intégration ? Comment ça se passe concrètement, il y des softs qui se charge de ça pour rendre le tout automatique ?
05/06/2010, 14h46
_Mac_

Citation:

Envoyé par Sebish

Et la le CSV se synchronise avec le serveur d'intégration ? Comment ça se passe concrètement, il y des softs qui se charge de ça pour rendre le tout automatique ?

Oui, mais je n'en connais pas qui soit dédié à PHP ou Ruby. Hudson tourne en Java. Après, ça dépend des besoins et de la technologie : pour PHP et Ruby, je pense qu'un simple script écrit par tes soins peut faire l'affaire : se connecter à SVN (ou autre) pour télécharger les sources et les copier dans un certain répertoire. Ce n'est pas sorcier, ça se fait bien. Après, si tu veux jouer des tests unitaires automatiquement, à condition que ton projet s'y prête, c'est plus difficile car ça dépend de la façon de réaliser ces tests unitaires. Je ne sais pas s'il existe l'équivalent de JUnit pour PHP ou Ruby.