Commit af8aef91 authored by Rémi Cailletaud's avatar Rémi Cailletaud

exo 12 et 13

parent 12fffadd
......@@ -9,6 +9,8 @@ Le code source est fourni. Après l'échauffement, Nous allons travailler sur de
À chaque fois, nous fournissons les mots-clés à chercher dans la [documentation très complète de gitlab](https://docs.gitlab.com/ee/ci/yaml/README.html). Comme nous sommes gentils, nous fournissons aussi les solutions dans les fichiers .gitlab-ci-\*.yml.
Nous conseillons fortement l'utilisation de virtualenv pour les tests locaux.
## Échauffement ##
### 1. Mon premier script ###
......@@ -123,7 +125,7 @@ Nous allons maintenant travailler avec un petit module en pur python créé pour
### 11. Tests et publication de la documentation à l'aide de Gitlab Pages ###
Nous allons écrire un pipeline complet, qui teste la fonctionnalité et le style du code (avec *pycodestyle*, disponible dans *pip*,) et qui génère et déploie la documentation (avec *sphinx*, disponible lui aussi dans pip). Pour la partie documentation, on utilisera [only](https://docs.gitlab.com/ee/ci/yaml/#only-and-except-complex) pour ne la regénérer que si le message de commit commence par `[doc]`. Cette étape un peu spéciale est appelée [pages](https://docs.gitlab.com/ee/ci/yaml/#pages) et s'appuie sur une fonctionnalité appelée [Gitlab Pages](https://docs.gitlab.com/ee/user/project/pages/index.html) (original !).
Nous allons écrire un pipeline complet, qui teste la fonctionnalité et le style du code (avec *pycodestyle*, disponible dans *pip*) et qui génère et déploie la documentation (avec *sphinx*, disponible lui aussi dans *pip*). Pour la partie documentation, on utilisera [only](https://docs.gitlab.com/ee/ci/yaml/#only-and-except-complex) pour ne la regénérer que si le message de commit commence par `[doc]`. Cette étape un peu spéciale est appelée [pages](https://docs.gitlab.com/ee/ci/yaml/#pages) et s'appuie sur une fonctionnalité appelée [Gitlab Pages](https://docs.gitlab.com/ee/user/project/pages/index.html) (original !).
**But** : Écrire un fichier .gitlab-ci.yml qui comporte trois deux étapes.
* La première étape comporte deux jobs, l'un qui teste le code à l'aide du test unitaire, et l'autre qui teste son style à l'aide de pycodestyle. Comme nous ne sommes pas des orthodoxes, admettons que dans certains cas le *coding style* peut ne pas être respecté...
......@@ -134,14 +136,43 @@ Vérifier que la documentation est bien déployée (le lien est disponible dans
*Note* : Pour générer la documentation dans `build/sphinx/html`, utilisez la commande distutils `build_sphinx`.
### 12. badges pipeline et coverage (Settings -> CI/CD -> General) ###
### 12. Les (presque) inutiles et donc indispensables badges ###
L'utilitaire *coverage* (disponible dans *pip*) permet d'obtenir le taux de couverture de vos tests, indicateur intéressant de la qualité du code. Cette information (ainsi que le status du pipeline) peut apparaître par exemple dans votre doc grâce aux désormais très populaires [Badges](https://docs.gitlab.com/ee/user/project/pipelines/settings.html#test-coverage-report-badge)
**But** : Ajouter les tests de couveture au job de test. Dans *Settings -> CI/CD -> General*, spécifier la regexp permettant de récupérer le taux de couverture, et récupérer le code HTMl et/ou Markdown à ajouter à la doc et/ou au fichier README.md.
*Note 1* : Pour lancer les tests de couverture
```bash
coverage run -m unittest discover
coverage report
```
*Note 2* : On vous aide pour la regexp...
*Note* : On vous aide pour la regexp...
```ruby
TOTAL\s+\d+\s+\d+\s+(\d+\%)$
```
### 13. déploiement : only branch - pypi - mot de passe : variables Gitlab CI (TWINE_PASSWORD TWINE_USERNAME), mais quand on grossit, utilisation de vault (par ex. Terraform Vault) ###
### 13. Le déploiement sur Pypi ###
Nous allons maintenant déployer notre paquet sur Pypi.
But : Ajouter une étape qui va construire le paquet Pypi (wheel) et le déployer sur l'instance de test à l'aide de *twine*, disponible dans *pip*.
*Note 1* : Construire une wheel dans le répertoire wheelhouse
```bash
pip wheel . -w wheelhouse
```
*Note 2* : Utiliser l'instance de test de Pypi avec `--repository-url https://test.pypi.org/legacy/`
*Note 1* : On ne peut déployer plusieurs fois la même version d'un paquet sur Pypi. Utilisez le numéro de version correspondant au numéro de votre dépôt (ex : version 1.0 pour le groupe formation-ci-01).
*Note 2* : Pour les gros projets multi-depôts, il est conseillé d'utiliser plutôt des outils dédiés pour la gestion de secrets (comme [Hashicorp Vault](https://www.vaultproject.io/).
### 14. docker: construire et déployer une image docker en production - docker info pr vérfier qu'on est bien sur distant - évidemment on le fait normamlement sur une branche spéciale (production) ###
### 15. blue/green ? templates (en fait anchors YAML) ###
### 16. bonus : répertoire infra, haproxy, docker-compose.yml ###
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment