-
Notifications
You must be signed in to change notification settings - Fork 2
Workflow
BenjBouv edited this page Feb 14, 2013
·
3 revisions
Cette page explique comment travailler en équipe sans se taper dessus et avec un minimum d'assurance qualité :-)
Sur Github, la branche master contient une version stable du site, c'est-à-dire qui marche pour tous les modules accessibles.
- Pour chaque problème (tâche du backlog) ou fonctionnalité, créer une nouvelle branche en étant le plus explicite dans le nom (pas de branche du style "amelioration" ou "bugfix", mais par exemple "passage-pdo" ou "bugfix-issue17").
- Pour les pull requests (PR), voir la section suivante.
En production, on reste sur master en principe:
- quand y a une PR acceptée sur le site, on essaie de switcher rapidement en production pour voir si la nouvelle version marche aussi (y a pas de raison, si on a bien la même configuration).
- si ça marche, on merge depuis la nouvelle branche vers le master sur le github; on repasse sur master sur la prod; on pull sur la prod depuis github/master.
- on clône depuis le Github, sur sa machine locale
- on code, on commit avec des messages le plus explicite possible. Pusher sur sa copie du repository (pas celle AEDI/SI donc) est à la bonne volonté de chacun.
- on teste localement, avec les mêmes versions que sur le serveur: Configuration du Serveur.
- si ça ne marche pas, on repart en 2. Si ça marche, on continue.
- Si on considère que l'on a fait des modifications intéressantes, on propose une pull request sur le dépôt principal. Il n'y a pas de petite pull request, l'important est que tout passe par les PR pour être certain que qqn valide son contenu. La pull request doit suivre un format:
- titre explicite (pas de "fix old style" mais bien "protection récursive - bug utf8 résolu" etc.)
- référencer toutes les issues qui sont réglées
- préciser que les tests locaux ont bien réussi, sinon revert (annulation de toutes les modifications de la pull request).
- La discussion est ouverte pour que les autres développeurs relisent le code et s'assurent que c'est bien documenté / correct / etc.
- Si au moins un autre développeur s'est assuré que la PR est correcte et fonctionne localement aussi sur son ordi, il peut merger. Pas d'auto-merge. (sinon quel intérêt de faire une PR?)
- Enjoy :)