dev-env + workflow
Qwann
parent
4513986dff
commit
d3dfbf0868
4 changed files with 145 additions and 1 deletions
101
dev-env.md
Normal file
101
dev-env.md
Normal file
|
|
@ -0,0 +1,101 @@
|
|||
# Environnement de développement
|
||||
|
||||
Il a deux façon d'accéder à l'environnement de développement de `GestionÉvènementiel`. Celui utilisant la `Vagrant`, plus lourde, mais très proche des conditions de développement, et l'utilisation d'un `virtualenv` qui a l'avantage d'être plus rapide d'utilisation.
|
||||
|
||||
## La VM Vagrant
|
||||
|
||||
### Installation
|
||||
|
||||
La façon recommandée de simuler `GestionÉvènementiel` sur votre machine est d'utiliser [Vagrant](https://www.vagrantup.com/). Vagrant permet de créer une machine virtuelle minimale sur laquelle tournera `GestionÉvènementiel`; ainsi on s'assure que tout le monde à la même configuration de développement (même sous Windows !), et l'installation se fait en une commande.
|
||||
|
||||
Pour utiliser Vagrant, il faut le [télécharger](https://www.vagrantup.com/downloads.html) et l'installer.
|
||||
|
||||
Vagrant permet d'utiliser différents types de machines virtuelles; par défaut il utilise [Virtualbox](https://www.virtualbox.org/) qu'il vous faudra également [télécharger](https://www.virtualbox.org/wiki/Downloads) et installer.
|
||||
|
||||
L'installation est terminée.
|
||||
|
||||
### Utilisation
|
||||
|
||||
#### Premier lancement
|
||||
|
||||
##### Machine virtuelle
|
||||
|
||||
Le lancement se fait avec la commande `vagrant up` dans le répertoire du dépot local.
|
||||
|
||||
À son premier lancement, Vagrant va télécharger une image Debian8 ainsi que des mises à jour (il vaut mieux avoir une connexion Internet pas trop mauvaise)
|
||||
|
||||
##### Paquets Python
|
||||
|
||||
Pour mettre à jour les paquets Python, il faut d'abord se connecter à la machine virtuelle en utilisant `vagrant ssh`, puis utiliser la commande suivante : `pip install --upgrade -r requirements-devel.txt`
|
||||
|
||||
Pour mettre à jour les modèles après une migration, il faut ensuite faire : `python manage.py migrate`
|
||||
|
||||
#### Utilisations suivantes
|
||||
|
||||
Voici quelques commandes importantes pour gérer la machine virtuelle :
|
||||
|
||||
- `vagrant up` permet de lancer la machine virtuelle. Si une machine virtuelle existe déjà, elle sera réutilisée ; sinon, Vagrant va créer et configurer une nouvelle machine virtuelle pour vous.
|
||||
|
||||
- `vagrant suspend` permet de sauver l'état de la machine virtuelle sur le disque pour la relancer plus tard (y compris après un reboot) avec `vagrant up`
|
||||
|
||||
- `vagrant halt` permet d'éteindre la machine virtuelle (par comparaison avec `vagrant suspend`, cela prend moins de place sur le disque car il n'y a pas besoin de sauver la RAM, mais la recréation avec `vagrant up` sera plus lente)
|
||||
|
||||
- Enfin, `vagrant destroy` permet de détruire complètement la machine virtuelle : lors du prochain appel de `vagrant up`, elle sera réinstallée de zéro.
|
||||
*Attention, contrairement aux deux méthodes précédentes, `vagrant destroy` détruira irrémédiablement le contenu de votre base de données locale, si elle vous est d'un quelconque intérêt, réfléchissez à deux fois !*
|
||||
|
||||
- `vagrant ssh` vous connecte en SSH à la machine virtuelle.
|
||||
|
||||
Une fois connecté en SSH, vous pouvez utiliser les commandes Django habituelles.
|
||||
|
||||
#### Lancement du serveur
|
||||
|
||||
Par défaut Django n'écoute que sur l'adresse locale de la machine virtuelle - or vous voudrez accéder à `GestionÉvènementiel` depuis votre machine physique.
|
||||
|
||||
Pour lancer le serveur, il faut donc lancer la commande `python manage.py runserver 0.0.0.0:8000`.
|
||||
|
||||
**Le dossier avec le code est partagé entre la machine virtuelle et votre machine physique : vous pouvez donc utiliser votre éditeur favori pour coder depuis votre machine physique, et les changements seront répercutés automatiquement dans la machine virtuelle.**
|
||||
|
||||
#### You know sometimes…
|
||||
|
||||
Des fois on essaye des trucs, on rate une migration, on s'assoie sur son clavier et PAF on casse la base de donnée.
|
||||
Même si le très radical `vagrant destroy && vagrant up` est une solution, elle est un peu longue. Il est possible de repartir
|
||||
avec une base de donnée fraîche en tapant les commandes suivantes
|
||||
|
||||
mysql -uroot -p$DBPASSWD -e "DROP DATABASE $DBNAME; CREATE DATABASE $DBNAME"
|
||||
python manage.py migrate
|
||||
|
||||
## Le virtualenv
|
||||
|
||||
### Utilisation de virtualenv
|
||||
|
||||
#### premier lancement
|
||||
Pour créer le virtualenv il suffit de lancer la commande `virtualenv venv` depuis la racine de votre dossier git, qui créera un répertoire `venv` à cet endroit. Pour installer les paquets python nécessaires : `pip install -r requirements-devel.txt`.
|
||||
|
||||
#### Utilisation
|
||||
Pour rentrer dans l'environnement virtuel simplement lancer : `source venv/bin/activate`. S'il y a de nouveaux paquets à installer il suffit de les installer à l'aide de `pip` une fois dans le virtualenv ou simplement de lancer à nouveau `pip install -r requirements-devel.txt`.
|
||||
|
||||
Pour sortir du virtualenv simplement lancer `deactivate`.
|
||||
|
||||
### Environnement
|
||||
Avec cette méthode les condition ne sont pas les mêmes qu'en production. Le SQL est géré ç l'aide de SQLite et la base de donnée est stockée dans un fichier à la racine du répertoire git. Il est possible de lancer django comme d'habitude. Cela est assuré par le fichier `/evenementiel/settings/devlocal.py`.
|
||||
|
||||
## Commandes utiles pour interagir avec GestionÉvènementiel
|
||||
|
||||
Django fournit un certain nombre de fonctions pour interagir avec GestionÉvènementiel en ligne de commande. Pour les lancer, taper `python manage.py <command_name>`. Une partie d'entre elles sont décrites ci-dessous.
|
||||
|
||||
### Les indispensables
|
||||
|
||||
- La commande `runserver`… lance le serveur ! On peut spécifier une interface et un port en ajoutant à la suite `0.0.0.0:8000` par exemple.
|
||||
- La commande `migrate` permet de faire suivre la base de donnée lorsque les modèles changent. Les "migrations" appliquées par `migrate` sont stockées dans `app_name/migrations/`. Lorsque vous effectuez des changements dans les modèles, utilisez `makemigrations` (cf plus bas) pour créer ces fichiers de migration automatiquement. On peut rétablir une version précise de la BDD, pour une application, avec `migrate bda 0001` par exemple.
|
||||
- La commande `makemigrations` crée automatiquement les fichiers de migrations dont il est question plus haut. Ils sont stockés dans `app_name/migrations/`. Ils peuvent être édités à la main si les migrations automatiques ne suffisent pas à vos besoins. Typiquement s'il faut ajouter un élément à la base de donnée pour la rendre cohérente. Cf https://docs.djangoproject.com/en/dev/ref/migration-operations/ pour plus de détails
|
||||
- La commande `createsuperuser` permet de créer un utilisateur avec tous les droits. Il peut créer des utilisateurs, des objets, etc via l'[interface-admin](gestiocof admin).
|
||||
|
||||
### Autres commandes utiles
|
||||
|
||||
- La commande `shell` ouvre un shell python qui connaît la config du site. Ça permet de faire toutesles opérations qu'on pourrait faire depuis une vue par exemple. Utile pour faire des essais avant de coder ou manipuler la base de données.
|
||||
- Un autre commande permettant de manipuler la base de donneés : `dbshell` qui lance un shell mysql sur la BDD de GestionÉvènementiel
|
||||
- Les commandes `loaddata` et `dumpdata` permettent respectivement de charger et d'exporter tout ou partie de la base de données. À noter que l'option `--indent=4` est utile pour la lisibilité. Attention il peut se passer des choses pas nettes si on charge une bdd dans une bdd non vide.
|
||||
|
||||
### Doc officielle
|
||||
|
||||
Pour plus de détails sur ces commandes et d'autres encore, ne pas hésiter à taper `python manage.py help <command_name>`et à visiter https://docs.djangoproject.com/en/dev/ref/django-admin/
|
||||
3
home.md
3
home.md
|
|
@ -1,8 +1,9 @@
|
|||
# GestionÉvènementiel
|
||||
|
||||
## Table des matières
|
||||
## Liens vers le wiki
|
||||
* [Documentation utilisat-rice-eur](user-doc)
|
||||
* [Documentation développeu-se-r](dev-doc)
|
||||
* [Environnement de développement](dev-env)
|
||||
* [Workflow](workflow)
|
||||
|
||||
## But du projet
|
||||
|
|
|
|||
42
workflow.md
Normal file
42
workflow.md
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
# Workflow
|
||||
|
||||
Merge requests
|
||||
==============
|
||||
|
||||
Le fonctionnement des dépots cof-geek se fait par merge requests, qui doivent être reviewées par une personne expérimentée (= Master, cf plus bas) qui n'a pas participé à l'écriture du code. En pratique pour faire une merge request, après avoir cloné le dépot, il faut faire une branche séparée avec `git checkout -b login/ma-branche` où `login` est votre pseudo et `ma-branche` un nom simple décrivant les modifications que vous souhaitez apporter. Ensuite faites vos modifications, puis poussez sur le GitLab. Là vous pouvez aller sur l'interface Web et cliquer sur le bouton "faire une merge request" qui apparaît.
|
||||
|
||||
Une fois la merge request effectuée, un Master lira et commentera votre code. Une merge request est une discussion entre l'auteur du code et le reviewer, ne vous pliez pas juste aux demandes du reviewer, votre point de vue compte ! Par ailleurs c'est plus à vous de modifier le code qu'au reviewer, mais cela dépend des situations.
|
||||
|
||||
N'hésitez pas à regarder les merge requests des autres, même sans être master, toute remarque constructive est bonne à prendre. De plus, c'est une bonne façon de se familiariser avec le code.
|
||||
|
||||
### Quelques outils pour review son code ou celui des autres
|
||||
|
||||
* [Pylint](https://www.pylint.org/) fait un tas de vérifications et permet notamment d'éviter un certain nombre d'erreurs.
|
||||
* [Flake8](https://pypi.python.org/pypi/flake8) vérifie que les conventions de la [PEP8](https://www.python.org/dev/peps/pep-0008/) (et quelques autres) sont bien respectées. Ce n'est pas une nécessité mais ça peut être une bonne habitude à prendre. À noter: Django est testé avec flake8 et recommande son usage(https://docs.djangoproject.com/en/1.11/internals/contributing/writing-code/coding-style/)
|
||||
|
||||
|
||||
Tests
|
||||
=====
|
||||
|
||||
C'est une bonne habitude à prendre d'ajouter des tests quand on développe une nouvelle fonctionnalité, si vous avez du mal demandez et quelqu'un vous aidera. Une autre bonne habitude à prendre : quand on résout un bug il faudrait systématiquement ajouter un test correspondant au bug pour s'assurer qu'il n'arrivera plus.
|
||||
|
||||
|
||||
Membres
|
||||
=======
|
||||
|
||||
Il y a trois types de contributeurs à cof-geek.
|
||||
|
||||
Extérieurs
|
||||
----------
|
||||
|
||||
Les extérieurs sont des gens avec un compte sur le GitLab mais non membres de cof-geek. Ils peuvent contribuer en forkant le dépot et en faisant une merge request. Ils n'ont aucun droit particulier sur le dépôt.
|
||||
|
||||
Developer
|
||||
---------
|
||||
|
||||
Le titre de Developer indique un membre de cof-geek, c'est-à-dire quelqu'un présent sur la ML et qui contribue activement (ou pas) du code. Les Developers peuvent accéder au dépôt commun, créer des branches, etc : ce sont donc des gens en qui une certaine confiance est placée.
|
||||
|
||||
Master
|
||||
------
|
||||
|
||||
Les membres possédant le titre de Master sont des gens qui connaissent bien au moins une partie du code. Ils ont quelques droits supplémentaires par rapport aux Developers ; en particulier ils peuvent modifier la branche principale (`master`). Ce sont eux qui mergent les merge request. Attention : être master n'est pas une raison suffisante pour pusher ses changements sur la branche `master` sans vergogne ! Ils doivent tout de même être reviewés par un autre Master, voir la section Merge requests.
|
||||
Loading…
Reference in a new issue