search

afup / back-office

V2 of Afup back-office
MIT License
3 stars 4 forks source link

Proposition de changement de workflow interne #38

Closed jewome62 closed 4 years ago

jewome62 commented 9 years ago

Salut,

J'aimerai proposer un changement de workflow de travail en interne (Développeur autorisé à pusher sur le projet)

Tout, d'abord, je voudrais mettre en place le workflow gitflow http://nvie.com/posts/a-successful-git-branching-model/ http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

La master sera la branche de production La develop sera la branche en cours de développement et de petites corrections (typo par exemple) Les développements seront sur des branches feature

On conserve la phase de validation par pull request et par vote pour merger la feature sur la develop

Qu'en pensez-vous ?

cc @webaaz @thierrymarianne @mikaelkael

D'ailleurs, si c'est ok, je pousserai mes modif sur une branche de feature avant de la finir. Je préviens que je n'ai pas bien découper mon travail donc cette branche sera un lot d'évolution :

webaaz commented 9 years ago

hello, perso je m'en fiche un peu, mais vu qu'on est sur github et qu'on bénéficie des pull request, git flow me semble un peu lourd. De simples branhes avec un système de reviews sur les PR me semble largement suffisant ;-)

My two cents ...

Martin Supiot 06 19 03 31 27 http://www.webaaz.com @webaaz https://twitter.com/#%21/webaaz

Faites des bébés ! utilisez www.mybabygame.com !

Le 15 novembre 2014 16:04, Desjardins Jérôme notifications@github.com a écrit :

Salut,

J'aimerai proposer un changement de workflow de travail en interne (Développeur autorisé à pusher sur le projet)

Tout, d'abord, je voudrais mettre en place le workflow gitflow http://nvie.com/posts/a-successful-git-branching-model/ http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

La master sera la branche de production La develop sera la branche en cours de développement et de petites corrections (typo par exemple) Les développements seront sur des branches feature

On conserve la phase de validation par pull request et par vote pour merger la feature sur la develop

Qu'en pensez-vous ?

cc @webaaz https://github.com/webaaz @thierrymarianne https://github.com/thierrymarianne @mikaelkael https://github.com/mikaelkael

D'ailleurs, si c'est ok, je pousserai mes modif sur une branche de feature avant de la finir. Je préviens que je n'ai pas bien découper mon travail donc cette branche sera un lot d'évolution :

  • Changement de structure bundle
  • ajout theme
  • design page login
  • Nettoyage du composer.json

— Reply to this email directly or view it on GitHub https://github.com/afup/back-office/issues/38.

jewome62 commented 9 years ago

Le truc c'est que on peut déclarer comme la master stable et faire des déploiements automatiques avec des outils comme dploy.io Et l'autre avantage de git flow, c'est qu'il est intégré dans le logiciel smartgit ou source tree et il existe un paquet git-flow sur ubuntu dans les dépots officiels (je sais pas sur les autres distributions) Donc très facile à utiliser

webaaz commented 9 years ago

oui oui, enfin ça ajoute une couche pas forcément nécessaire. Faisons simple on est pas des dizaines à bosser sur le sujet non ? Autant ca peut sembler adapté à un git classique autant les PR de github apportent une autre manière de faire plus simple.

D'autres avis ?

erichard commented 9 years ago

Alors voici le mien. git-flow j'ai essayé, j'ai arreté. De mon point de vue c'est utile si ton projet est versionnable, dans le sens avoir des numéro de version. Unf bibli, un projet distribué, un framework... Mais pour une application web métier c'est absolument pas nécessaire et ça rajoute de la complexité pour rien.

Donc comme Martin, je vote -1, les PR de github c'est suffisant.

jewome62 commented 9 years ago

Ah bon ? J'ai découvert et appliqué git flow sur un application métier, et j'ai trouvé que cela simplifié la chose.

donc deux -1, à part si tierry est à 200% pour on abandonne

webaaz commented 9 years ago

Oui je confirme le point de vue d'Erwan, je sort d'une semaine de formation sur Git avec Christophe Porteneuve et c'est aussi son point de vue !

Martin Supiot 06 19 03 31 27 http://www.webaaz.com @webaaz https://twitter.com/#%21/webaaz

Faites des bébés ! utilisez www.mybabygame.com !

Le 17 novembre 2014 00:59, Desjardins Jérôme notifications@github.com a écrit :

Ah bon ? J'ai découvert et appliqué git flow sur un application métier, et j'ai trouvé que cela simplifié la chose.

donc deux -1, à part si tierry est à 200% pour on abandonne

— Reply to this email directly or view it on GitHub https://github.com/afup/back-office/issues/38#issuecomment-63246328.

jacquesbh commented 9 years ago

En l'occurence git-flow peut apporter beaucoup dans le cas d'un site web qui a du déploiement (semi-)automatique. Mais effectivement ici je pense que un système de PR est bien suffisant. Si on bosse proprement alors nous n'aurons pas de soucis.

Par contre quid du déploiement automatique… C'est pas impossible que je m'amuse à ça un jour sur le site de l'afup :)

jewome62 commented 9 years ago

J'ai prévu d'ici 1 à deux semaines (quand j'aurai fini la partie connexion et bien commencé adhésion) de faire une pré-prod chez moi (serveur ubuntu, php 5.5) (le host est http://jewome62.eu )

Et mettre en place sur cette pré-prod un deploiement totalement automatique. Par contre, je conseille un semi-automatique en prod vu que la master aura tout les developpements et qu'il n'y aura pas de processus de release

jacquesbh commented 9 years ago

Yes.

Je vais ajouter un fabric.py afin de pouvoir faire des déploiements manuels mais automatisés par les personnes qui ont leur clé sur le serveur. Ça me permettra aussi de mettre ça en place sur le jenkins de Monsieur Biz et ainsi donner quelques accès. Ça sera sans doute plus simple. Avec une URL pour lancer le déploiement qui sera disponible quelque part sur le wiki ou dans le BO de l'AFUP…

2014-11-17 12:53 GMT+01:00 Desjardins Jérôme notifications@github.com:

J'ai prévu d'ici 1 à deux semaines (quand j'aurai fini la partie connexion et bien commencé adhésion) de faire une pré-prod chez moi (serveur ubuntu, php 5.5) (le host est http://jewome62.eu )

Et mettre en place sur cette pré-prod un deploiement totalement automatique. Par contre, je conseille un semi-automatique en prod vu que la master aura tout les developpements et qu'il n'y aura pas de processus de release

— Reply to this email directly or view it on GitHub https://github.com/afup/back-office/issues/38#issuecomment-63294416.

Jacques Bodin-Hullin jacques@bodin-hullin.net +33 6 75 54 11 97 - http://jacques.sh

mikaelkael commented 9 years ago

Sur barometre (https://github.com/afup/barometre) et aperophp (https://github.com/afup/aperophp), on le fait via Capistrano. Est-ce nécessaire de rajouter un nouveau type de processus ?

webaaz commented 9 years ago

Pensez à voir avec Mickael Perraud, il a déjà des scripts de déploiement !

webaaz commented 9 years ago

Oui voilà exactement ce que je voulais dire :) Gardons le même !

jewome62 commented 9 years ago

Est-ce nécessaire de rajouter un nouveau type de processus ?

Absolument pas ! Moi je ne fais que proposer car il n'y avait encore rien sur le sujet ici. Je suis là pour apprendre, donc si vous mettez en place les différents fichiers et que l'on m'explique comme cela fonctionne :D :smile:

mikaelrandy commented 9 years ago

Faites moi signe pour les premières MEP, je mettrais en place Capistrano, et on s'assurera tous que la procédure de déploiement est claire et documentée.

thierrymarianne commented 9 years ago

Vive les PR :+1:

jewome62 commented 9 years ago

Euh quel est le rapport, sur mon workflow, on utilise aussi les PR ...

On conserve la phase de validation par pull request et par vote pour merger la feature sur la develop

erichard commented 9 years ago

Un article intéressant pour compléter le sujet : https://about.gitlab.com/2014/09/29/gitlab-flow/

Je pense qu'on peux clore l'issue…

thierrymarianne commented 9 years ago

@erichard Merci beaucoup !