Mots-clé : ci

Django et git : bonnes pratiques / idées pour faire du CI

Conseil d’un ami :

  • gitlab n’est pas 100% opensource, ils proposent une édition communautaire limité et la totalité des fonctionnalités est dispo avec la version entreprise, leur modèle économique c’est de brider la version CEE (community) dans pas mal de coin pour te pousser à prendre une licence, perso je trouve que c’est plus un freeware qu’autre chose
  • gitlab est pas mal mais honnêtement pour l’avoir beaucoup (vraiment beaucoup) utilisé dans le passé ce n’est pas la meilleur alternative.

Si tu cherche à mettre en place un truc je te conseille fortement de jeter un œil à :

Cette stack est un peu plus compliquée à mettre qu’un gitlab, mais c’est très puissant, surtout la partie gerrit qui transcende la manière de faire des revues de code.

Si le code Django / Python n’est pas correct, il y a des méthodes pour améliorer les choses notamment :

  • https://nvie.com/posts/a-successful-git-branching-model/
  • https://semver.org/

Il est également important de mettre en place un système de « core developer » même au sein d’un projet privé en entreprise, afin de garantir la cohérence des données et l’intégrité de l’historique. En effet, si tout le monde à les droits d’écriture sur tout, ça finira toujours à un moment donné à partir dans tous les sens… L’idée, c’est de donner les droits d’écriture à seulement 2-3 personnes de confiance qui ont un certain niveau et à tous les autres imposer de faire des forks dans leur namespace gitlab et de proposer des merge request (l’équivalent des pull requests avec github). Ainsi, la revue de code est obligatoire et il n’est plus possible de merger du mauvais code… et les développeurs « standard » (sans droits donc) ont juste 2-3 commandes de base à connaître pour bosser avec les autres. Sans ce genre de système cela ne peut pas réellement fonctionner car git à été developpé pour ce mode de fonctionnement (au même titre que svn et d’autres gestionnaire de version) et donc son workflow est idéal dans ce cadre.

Fonctionner comme ça m’a permis de :

  1. coder un petit robot qui réagissait au merge requests proposé et donc qui checkait tout un tas de choses automatiquement et qui proposait des commandes si les choses n’allaient pas
  2. responsabiliser les gens de l’équipe en les rendant responsables de leur propre forks
  3. faire monter en compétence l’équipe qui était ultra frileuse à faire du versionning puis au final à pris goût au truc…

J’ai fais des petites formations au début pour leur expliquer l’intérêt et expliquer la sémantique des changement et qu’il est important de penser ses commits de manière propre. Cela permet :

  • dans certains cas de retirer (revert) des bugs complet d’un seul coup,
  • de faire du debug de manière automatique sans rien toucher et de trouver les changements responsable d’un bug (git bisect),
  • de faire un gain énorme de qualité au final
  • d’avoir des historiques clairs avec des messages de commit ayant une réelle plus value (exemple)
  • d’automatiser tout un tas d’actions qui vont augmenter la qualité globale du projet et vont réduire les taches inutiles et donc laisser plus de temps pour les trucs fun à faire.

C’est gagnant gagnant, mais au début les gens râlent… il faut juste s’y préparer et avec le temps ils changent d’avis !

CI / git / gitlab / github

gitlab hints / aide

Git
Workflow Gittrunkbaseddevelopment.com
Semantic versioningsemver.org
Commit messages, règles de base gist.github.com/robertpainsi
Conventional commits conventionalcommits.org
Full refresh à partir du develop (si problème ou autre) git reset --hard origin/develop
git pull
Rafraîchir (à la main) une branche locale (si problème ou autre) git checkout master
git branch -D develop
git fetch
git checkout develop
git pull
Synchroniser le local avec le remote git fetch
Pour faire une nouvelle branche git checkout -b [nom de la branche]
Pour changer de branche git checkout [nom de la branche]
git pull
Sous-module : ajouter un git qui vient d'un autre repo git submodule add [nom du repo] [dossier dest]
Exemple concret qui a fonctionné pour moi : git submodule add https://github.com/goldfire/howler.js.git static/vendors/howler.js

Si erreur git qui parle de répertoire, demander à supprimer le dossier du cache : git rm --cached [dest. ex: static/vendors/howler.js]
Sous-module : ajouter un git qui vient d'un autre repo git submodule add [nom du repo] [dossier dest]
Exemple concret qui a fonctionné pour moi : git submodule add https://github.com/goldfire/howler.js.git static/vendors/howler.js

Si erreur git qui parle de répertoire, demander à supprimer le dossier du cache : git rm --cached [dest. ex: static/vendors/howler.js]
Sous-module : ajouter un git qui vient d'un autre repo git submodule add [nom du repo] [dossier dest]
Exemple concret qui a fonctionné pour moi : git submodule add https://github.com/goldfire/howler.js.git static/vendors/howler.js

Si erreur git qui parle de répertoire, demander à supprimer le dossier du cache : git rm --cached [dest. ex: static/vendors/howler.js]
Sous-module : : sur un autre PC mettre à jour avec tous les sous-modules Si git pull ne met pas à jour les sous-modules, c'est que ce qui gère les sous-modules sous git n'est pas initialisé :
git submodule update --init
Pour changer de branche git checkout [nom de la branche]
git pull
Pour changer de branche git checkout [nom de la branche]
git pull
Git global setup
Sur PC dev		 git config --global user.name "Olivier Pons"
git config --global user.email "monmail@mail.com"
Clone gitlab » dev
Push dev » gitlab		 git clone git@gitlab.com:olivier.pons/ajeter.git
cd ajeter
touch README.md
git add README.md
git commit -m "add README"
git push -u origin master
Init. projet pas vide:
Clone dev » gitlab		 cd existing_folder
git init
git remote add origin git@gitlab.com:olivier.pons/ajeter.git
git add .
git commit -m "Initial commit"
git push -u origin master
Git existant sur dev
Clone dev » gitlab		 cd existing_repo
git remote rename origin old-origin
git remote add origin git@gitlab.com:olivier.pons/ajeter.git
git push -u origin --all
git push -u origin --tags
Autre Git existant sur gitlab
Clone gitlab » dev		 > git clone git@gitlab.com:adresse/repo/sur/gitlab/monprojet.git
Cloning into 'monprojet'...
remote: Enumerating objects: 308, done.
remote: Counting objects: 100% (308/308), done.
remote: Compressing objects: 100% (192/192), done.
Receiving objects: 63% (195/308)
Receiving objects: 100% (308/308), 93.34 KiB | 463.00 KiB/s, done.
Resolving deltas: 100% (169/169), done.
> cd monprojet
> git checkout -b nom-de-la-branche remotes/origin/nom-de-la-branche Donc en local, on a en local nom-de-la-branche liée à la branche distante remotes/origin/nom-de-la-branche.
A partir de là commit, push et pull fonctionnent.
Si des branches ont été ajoutées au remote :
Synchroniser le git local avec le remote 		 git remote update origin --prune

Requirements

requirements
Le résultat du pip freeze permet d'avoir un "snapshot" des versions exactes utilisées, cela peut éviter certains bugs. Dans tous les cas, il faut prendre en compte les dépendances dès le début du projet et tout au long de son cycle de vie.
Une bonne pratique quand on utilise pip est de structurer ses dépendances de la manière suivante : ​
  • Un fichier requirements_base.txt avec les dépendances communes, par exemple : pynsq==0.8.2
    requests==2.19.1
    xlrd==1.1.0
    openpyxl==2.5.7
    python-datauri==0.2.8
  • Un fichier requirements_dev.txt dépendant de requirements_base.txt ne contenant les dépendances uniquement nécessaires pour le développement, test, CI, par exemple :
    -r requirements_base.txt
    pylint
  • Un fichier requirements_prod.txt dépendant de requirements_base.txt contenant les dépendances uniquement nécessaire à la production : -r requirements_base.txt
    gunicorn==19.7.1
  • Et un fichier requirements.txt qui ne sert que de lien à celui de prod (certaines plateformes style heroku utilisent celui-ci par défaut) -r requirements_prod.txt
Le développeur installe requirements_dev.txt, le déploiement en prod utilise requirement_prod.txt ou requirements.txt. ​ Tout ceci permet d'avoir des environnements reproductibles avec des versions figées, et de ne pas avoir à installer des dépendances supplémentaires à la main (par exemple gunicorn en prod).
Commentaires fermés sur CI / git / gitlab / github Publié dans Mots-clé , , ,