- Mettre en place un systeme d'integration continue avec Gitlab on

Bonjour,

Je ne sais pas si je suis dans la bonne catégorie pour poser cette question mais comme elle concerne un système que je veux mettre en place sur mon serveur web…

Avec d'autre personnes nous souhaitons simplifier la mise en production de notre site et c'est pour cela qu'on souhaiterai utiliser Gitlab avec Gitlab-ci (ou tout autre système) afin de faire de l'integration continue afin de simplifier notre système.

Il y aurait plusieurs branches : - Production (version en ligne accessible au public) - Développement (version ou on teste les modules avant la mise en prod') - Features (la ou chacun développe ses modules avant de les intégrer a la dev)

Je souhaite également faire en sorte que lorsque je fais des modifications sur une branche que ca s'affiche automatiquement que ca soir en prod', dev' Exemple, sur une branche de feature, nommé inscription je fais un push avec des modifications et via l'integration continue la branche se charge sur la dev (ainsi on peut travailler sur diverses choses séparément sans toucher a la dev ou a la prod') et une fois les tests en dev' terminés on peut faire un merge sur la version de prod'.

Je ne sais pas si ma demande est claire.

Je sais qu'on peut faire ceci avec Gitlab et Gitlab-CI, Teamcity ou Jenkins mais le soucis se pose niveau configuration.

Donc si quelqu'un a deja travaillé avec ce système et sais comment le mettre en place, je le remercie par avance.

Zestement,

Selmac

J'ai déjà travaillé avec jenkins et avec gitlab.

En fait l'idée est de créer un build jenkins à partir du git. Puis de créer un "webhook" côté gitlab (ou bien d'utiliser l'intégration du plugin gitlab-jenkins) pour que lorsque le build réussit côté jenkins, un merge est fait sur dev. Puis, un nouveau build est lancé et si ça marche, un script met tout ça en prod.

Merci de ta reponse.

Sauf que ce que je veux faire c'est que je veux pas que ca merge sur le dev ou sur la prod (ca c'est quelque chose qu'on veut faire manuellement apres avoir fait plusieurs tests)

Lorsqu'on push, sur la version de dev, on voit ce qu'on dev, mais il faut qu'on puisse changer de branche comme on veut et si on veut revenir sur la branche de dev sans les features.

Lorsqu'on push, sur la version de dev, on voit ce qu'on dev, mais il faut qu'on puisse changer de branche comme on veut et si on veut revenir sur la branche de dev sans les features.

hein?

si tu as pushé dans dev, alors les features sont dans dev, si tu veux enlever les features, faut faire un revert.

Ensuite, pour ce qui est des "branches". Sur travis, tu peux lui dire de faire un "fetch" tous les X temps et s'il découvre une nouvelle branche ou une modification ET que tu ne lui a pas dit de ne pas prendre cette branche/modification en compte, il va créer tous le build sur cette branche. Et à partir de là tu auras ce qu'il faut.

On parle peut-être de la meme chose sans se comprendre car c'est pas evident a expliquer

Je veux avoir deux sites bien distincts :

• Production
• Développement

Sur la production je souhaiterai que ca affiche le contenu de la branche master.

Sur le développement je souhaiterai que ca affiche le contenu de la branche dev ainsi que les features quand on en pousse une et changer de branche comme je veux depuis l'interface (avec Teamcity ca fonctionne ainsi, on utilise ca au travail mais je ne sais pas comment ca été mis en place)

Ainsi je peux créer de nouvelles fonctionnalité sans casser le site de développement (ou si je veux développer / corriger autre chose a coté) via des branches de feature et lorsque que tout les tests sur la version de développement sont validés, je peux créer une branche de release et la merger sur la branche de production.

En gros, tu veux un site par branche ?

Je veux avoir la branche de dev pour le dev du site et la branche master pour sa version prod comme ca si je casse le site sur la branche de dev, ca sera du a du code foireux dans le commit et ca se réglera rapidement et les autres dev peuvent voir par exemple ce que j'ai pousse et inversement.

Edit 27/12/15 - 01:45 : Etant habitué au couple Gitlab / Teamcity avec le travail, je souhaiterai les utiliser. J'ai deja normalement effectué une partie de la configuration mais je cherche pour faire ce que j'ai demandé ci-dessus.

A priori y'a pas vraiment de lien avec GitLab. N'importe quel repo git fera l'affaire.

Ensuite, qu'il s'agisse de Jenkins, Travis ou autre, n'importe quel outil de CI te permettra de faire ce que tu veux, c'est le b-à-ba.

Si on "parle" Jenkins (et je paraphrase quasiment artragis là, il t'a donné les bons conseils) :

• tu as un job "déployer en environnement de dev" dont la description serait :
  • se placer dans un workspace adapté (il le fait tout seul normalement)
  • git pull origin dev
  • construire le projet (compilation, etc.)
  • lancer les tests s'il y en a
  • si tests OK, déployer sur la machine de test ( + éventuellement redémarrer le serveur si besoin)
• Second job : "déploiement en production"
  • git pull origin master
  • les mêmes étapes que ci-dessus
  • déployer le code sur la machine de production

Ensuite pour ce qui est du reversement d'une branche à l'autre, tu peux soit le faire à la main, soit l'automatiser par un 3ème "job".