Skip to content
BenjBouv edited this page Feb 14, 2013 · 3 revisions

Workflow

Cette page explique comment travailler en équipe sans se taper dessus et avec un minimum d'assurance qualité :-)

Les Branches

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.

Proposer une PR

  1. on clône depuis le Github, sur sa machine locale
  2. 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.
  3. on teste localement, avec les mêmes versions que sur le serveur: Configuration du Serveur.
  4. si ça ne marche pas, on repart en 2. Si ça marche, on continue.
  5. 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).
  1. La discussion est ouverte pour que les autres développeurs relisent le code et s'assurent que c'est bien documenté / correct / etc.
  2. 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?)
  3. Enjoy :)
Clone this wiki locally