Guide des contributeurs

jhuet edited this page Feb 8, 2013 · 21 revisions

Autres versions

Introduction

Gardez en tête que dibber est à un stade de développement très précoce ce qui rend l'application sujette à de nombreux changements tant qu'elle n'aura pas atteint un état plus mature.

Spécifications, idées principales

Les spécifications de l'application ne sont pas totalement conçues encore. Ce sujet demandant de nombreux échanges, ils prennent place dans cette liste de discussion. Nous ne cherchons pas non plus à faire un cahier des charges complet, mais plutôt à rendre les choses faciles à comprendre en (quand c'est possible) réalisant le design visuel de ce que l'on veut voir dans l'application.

Par exemple, il y a déjà 2 mockups de différents designs en cours de réalisation (plus d'infos) :

  • version 1 avec des liens cliquables - appuyez sur shift pour les voir
  • version 2 sans liens pour le moment - utilisez les flèches en haut à droite

Une autre façon d'exprimer d'une façon simple à comprendre ce que pourrait être l'application est d'écrire de petites histoires sur cette partie spécifique. En la décrivant dans un contexte d'utilisation par quelqu'un. Des histoires génériques sur l'application de façon générale seront disponibles bientôt.

Développement

L'application est réalisée avec ces technologies principales :

Installation

La façon la plus simple est d'utiliser à la fois git et composer. Si vous n'avez aucun des deux, vous pouvez les installer de cette façon : sh $ sudo apt-get install git $ curl -s http://getcomposer.org/installer | php

Maintenant, vous allez devoir retrouver le code de dibber ainsi que ses dépendances. Vous pouvez forker ce repository puis récupérer votre code forké ou bien si vous voulez juste jeter un coup d'oeil au code sans pouvoir le modifier vous pouvez tout simplement faire : sh $ git clone git://github.com/dibber-org/dibber.git $ cd dibber $ /path/to/composer.phar install $ chmod -R 777 data/cache data/log N'oubliez pas que vous devez avoir un serveur MongoDB qui tourne. Pour configurer l'application pour qu'elle y ait accès, créez ce fichier : config/autoload/module.doctrine-mongo-odm.local.php et copiez la partie doctrine.connection du fichier config/autoload/module.doctrine-mongo-odm.global.php dans le premier avec les bonnes données afin qu'il ressemble à : ``` php

[ 'connection' => [ 'odm_default' => [ 'server' => 'localhost', 'port' => '27017', 'user' => 'root', 'password' => 'pwddeouf', 'dbname' => 'dibber', 'options' => [] ], ], ], ]; ``` Faites attention à ne jamais commiter vos fichiers de configuration ``*.local.php`` car ils ne sont là que pour votre propre environnement. Vous avez maintenant dibber qui fonctionne, bien joué ! Si vous avez des questions jetez un coup d'oeil à la [liste de discussion](https://groups.google.com/forum/#!forum/dibber) et/ou posez les dessus. #### Guide de dev ##### Workflow Comme nous utilisons git pour le versionnement, vous êtes tenus de suivre le [Git workflow](http://nvie.com/posts/a-successful-git-branching-model/). Les deux branches importantes sont : * La branche `master` le dernier code stable pour release (on ne commit jamais dedans) * La branche `dev` contient le dernier code de développement (les pull requests sont mergées dedans) Pour vous, cela veut essentiellement dire que si vous souhaitez contribuer du code, vous devez toujours envoyer une pull request (même si vous avez les droits pour commiter). Les étapes sont : 1. Forkez le projet, 2. Créez une branche ; suivant sa nature préfixez la avec `fix/`, `feature/` ou `hotfix/` suivis par le numéro de l'issue si il y en a un puis d'une petite description (ie : `feature/6-ma-super-feature`), 3. Codez dedans, 4. Créez une pull request sur la branche `dev`, 5. Si besoin : discussions à son sujet dans les commentaires de l'issue, re-code, re-commit, 6. Puis la _team admin_ fermera la pull request et la mergera dans la branche `dev`. Si vous avez besoin de conseils, d'aide, de commentaires, de revues... sur ce que vous êtes en train de coder, n'hésitez pas à créer une pull request et à commencer la discussion dans les commentaires de l'issue. La pull request se mettra à jour à chacun de vos futurs push sur votre branche. Aussi, je(jhuet) propose d'utiliser [Trello](https://trello.com/board/development/502979250e2623863414d33e) en conjonction de la page d'issues de GitHub en tant que système [kanban](https://en.wikipedia.org/wiki/Kanban_(development). Cela nous permettrait de facilement déterminer qui travaille sur quoi et de valider les différentes étapes nécessaires pour qu'une nouvelle feature soit complète. J'utilise [Zapier](https://zapier.com) qui créé automatiquement des cartes Trello quand une issue est créée (bien que ça ne soit synchronisé que toutes les 5 heures car j'utilise la version gratuite). Néanmoins, les discussions sur les issues doivent rester sur GitHub. Des cartes qui ne concernent pas une issue peuvent être crées manuellement sur Trello. Les discussions à leurs sujets ont alors lieu dessus. ##### Standards de codage Pour le moment nous allons emprunter les standards utilisés par le Zend Framework 2 que vous pouvez [trouver ici](http://framework.zend.com/wiki/display/ZFDEV2/Coding+Standards). ##### Couverture de test [Atoum](https://github.com/mageekguy/atoum/) est utilisé pour réaliser les tests unitaires. Autant que possible essayez de penser [Développement Piloté par les Tests](http://fr.wikipedia.org/wiki/Test_Driven_Development) quand vous développez et fournissez des tests unitaires pour les pull requests que vous faites. Pour récupérer Atoum comme une dépendance avec composer, `cd` dans le répertoire racine du projet et : ``` sh $ /path/to/composer.phar --dev update ``` Tous les tests sont dans le répertoire `/tests`. Pour les lancer `cd` dans le répertoire racine du projet et : ``` sh $ bin/tests.sh ``` Cela lancera tous les tests et vous dira lesquels sont passés ou pas. Nous recommandons fortement d'utiliser les statements `assert`, `if`, `and`, `then` pour rendre les tests plus verboses et [faciles à lire](https://github.com/mageekguy/atoum/wiki/%C3%80-propos-de-if%28%29,-and%28%29,-then-et-c%C3%A6tera). Vous pouvez trouver quelques [exemples](https://github.com/dibber-org/dibber/blob/dev/tests/Dibber/Tests/Units/Document/Place.php) dans le [code](https://github.com/dibber-org/dibber/blob/dev/tests/Dibber/Tests/Units/Document/User.php) [déjà](https://github.com/dibber-org/dibber/blob/dev/tests/Dibber/Tests/Units/Document/Mapper/Base.php). Vous pouvez trouver de l'aide sur comment l'utiliser [ici en français](https://github.com/mageekguy/atoum/wiki) et [là en anglais](https://github.com/geraldcroes/atoum-s-documentation/blob/master/Contents/chapter1.md). ##### Intégration continue L'intégration continue est faite grâce à [Travis](http://travis-ci.org/). Vous pouvez voir le résultat du dernier build et les précédents sur [cette page](http://travis-ci.org/#!/dibber-org/dibber). Des icones affichant si le dernier build a passé ou échoué pour les branches `master` et `dev` se trouvent sur [la page principale](https://github.com/dibber-org/dibber#readme) ici sur GitHub. Travis nécessite d'avoir un fichier [`.travis.yml`](https://github.com/dibber-org/dibber/blob/master/.travis.yml) à la racine du projet. Il contient les scripts qui seront exécutés pour réaliser le process complet. Si vous voulez plus d'informations sur sa syntaxe, vous pouvez lire [le guide de Travis](http://about.travis-ci.org/fr/docs/user/getting-started/). Seules les branches `master` et `dev` sont build. Si vous faites une branche, les builds ne commenceront qu'au moment de votre 1ère pull request dans la branche `dev`. Puis tous les commits fait sur cette branche mettront à jour la pull request et lanceront un nouveau build. Si vous savez qu'un commit n'as pas besoin d'être build, vous pouvez ajouter `[ci skip]` au message de commit. ### Design / Interface Bientôt... ### Traduction Nous utiliserons certainement [Transifex](https://www.transifex.net/) quand le moment sera venu.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.