GitBucket
Bonnes pratiques
Développement
Avant de travailler
Cloner le dépôt
Il faut avoir cloné le dépôt sur sa machine:
git clone ssh://git@gitbucket.inist.fr:22222/tdm/web-services.git
Cette étape n'est nécessaire qu'une seule fois.
Se mettre dans le répertoire web-services
On réutilise toujours le même répertoire de travail (normalement nommé par la commande précédente web-services).
Synchronisation
Avant de commencer la création d'un nouveau service, on rapatrie les dernières modification du dépôt (à partir de la racine, c'est-à-dire le répertoire web-services):
git pull
Nouvelle branche
En fonction de ce que vous voulez faire, créez une branche:
create-serviceoù vous remplacezservicepar le nom du service que vous envisagez de créerfix-serviceoù vous remplacezservicepar le nom du service que vous envisagez de corrigerimprove-serviceoù vous remplacezservicepar le nom du service que vous envisagez d'améliorer
git checkout master # on s'assure qu'on est sur la branche principale git checkout -b create-service # on crée la branche et on s'y déplace
Pull Request
Créez une pull request où vous pourrez documenter plus largement que dans les messages de commit ce que vous faites.
Ça permet également d'avoir une discussion portant sur la modification en cours.
Ça permettra aussi de montrer votre code à quelqu'un d'autre avant de le valider.
La pull request se crée à partir de la branche que vous avez créée, mais elle doit au moins contenir un commit.
Sur le menu Pull requests de GitBucket cliquez sur New pull request (en haut à droite de la page).
Si vous ne voyez pas le bouton, connectez-vous à GitBucket.
Par défaut, on tombe sur une page comparant la branche master à... la branche master.
Comme vous avez déjà poussé votre branche, vous pouvez la sélectionner (à droite):
Il est important de donner un titre et une description parlante à votre pull request, c'est ce qui permettra de la retrouver facilement.
En général, le titre est lié au nom de la branche, si on a été bien inspiré en créant la branche.
Comme la pull request est dédié à la communication entre nous, on peut y écrire en français (dans un projet open source classique, on préfère utiliser l'anglais).
Il ne reste plus qu'à continuer à travailler dans la branche de la pull request, en n'oubliant pas de pousser régulièrement les commits sur le dépôt.
git push
Nouvelle instance ?
- vérifier si une instance existante serait réutilisable
Si non:
- déterminer un nom d'instance en suivant les conventions de nommage (un tiret au milieu, ...)
- création du répertoire de l'instance
- création de la route v1/...
Dans tous les cas:
- création du .ini v1/service.ini
Python
version de python
Utiliser un environnement virtuel
requirements.txt
Tester localement
node
Tester localement
Documentation
paquets ezs
examples.http
Déploiement
Tester sur la vi
Déployer le service sur la vi
La version de la branche.
Tester le swagger
www-home
Si c'est une nouvelle instance, l'ajouter dans le index.html de www-home, qui sera openapi.services.inist.fr.
Code review
Merge vers master
Faire une version
Vérifier l'utilisation (grafana)
Déployer sur la vp
La version générée instance@version.
Après le déploiement
Vérifier que le swagger fonctionne
Si c'est une nouvelle instance, il se peut qu'elle n'apparaisse pas immédiatement dans openapi.services.inist.fr, car ce site est mise à jour automatiquement toutes les demi-heures (pendant les heures de bureau, les jours de semaine).