User Tools

Site Tools


2018_2019:s3:methodo:td:ci

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
2018_2019:s3:methodo:td:ci [2018/09/02 19:03]
blay [Intégration continue]
2018_2019:s3:methodo:td:ci [2018/09/02 22:07] (current)
blay [Analyse de la qualité : SonarQube]
Line 5: Line 5:
 Nous allons à présent reprendre les codes donnés lors du premier exercice, les placer sous contrôle de version (GIT) et mettre en place des mécanismes automatiques de tests. Nous allons à présent reprendre les codes donnés lors du premier exercice, les placer sous contrôle de version (GIT) et mettre en place des mécanismes automatiques de tests.
  
-  - Placez les codes que vous avez développé lors du premier exercice dans votre répertoire sous gestion de version, i.e. seulement src et tests +  - Placez les codes que vous avez développé lors du premier exercice dans votre répertoire sous gestion de version, i.e. **seulement ​''​src'' ​et ''​tests''​** 
-  -  ​+  - Créez un projet java sous eclipse qui référence votre projet 
 +        - new java project  
 +        - dé-sélectionner la localisation par défaut pour y mettre la place où vous avez stocké votre projet 
 +  - Exécutez les tests 
 +  - AVANT de commiter, nous devons éliminer tout ce qui n'a pas besoin d'​être sous version de contrôle en particulier les binaires, pour cela le fichier ''​.gitignore''​ nous permet de préciser les fichiers à omettre.  
 +       - Sous sourceTree vous pouvez sélectionner les fichiers à ignorer et commiter.. {{ :​2018_2019:​s3:​methodo:​td:​capture_d_e_cran_2018-09-02_a_19.34.06.png?​direct&​300 |}} 
 +       - Dans le projet que vous aviez récupéré initialement,​ il y a un fichier ''​.gitignore''​ qui élimine d'​office la plupart des fichiers qu'il est inutile de commiter dans le cadre d'un projet eclipse et java. Vous pouvez trouver des patrons de ''​.gitignore''​ sur le web facilement. 
 +  - Vérifiez que vous avez bien "​poussé " uniquement des fichiers voulus.  
 +  - A présent nous avons pour objectif de forcer la validation des tests à chaque fois que le code est poussé. 
 +      - Récupérer le fichier .gitlab-ci.yml et l'​ouvrir sous eclipse par exemple en installant le plugin Yaml 
 +      - Ajouter le fichier à la gestion de version. 
 +  - Constater sous gitlab ci que l'​exécution est en attente d'un "​runner"​ {{ :​2018_2019:​s3:​methodo:​td:​gitlabci_2018-09-02_a_21.02.57.png?​direct&​400 |}} 
 +      - Pour désigner le Runner aller sous Setting, Ci, {{ :​2018_2019:​s3:​methodo:​td:​gitlabci_2018-09-02_a_21.07.16.png?​direct&​300 |}} 
 +      - Expand Runners 
 +           - Sélectionner ​ le runner specific {{ :​2018_2019:​s3:​methodo:​td:​specificrunners_2018-09-02_a_21.12.15.png?​direct&​300 |}} 
 +  - Vérifier que les tests s'​exécutent correctement. 
 +  - Oter le commentaire devant le test qui échoue dans yml, commiter et vérifier que les tests échouent bien.
  
-PENSEZ à revenir ​sur le 1e TD pour connecter SONAR +/*        - clique droit sur le projet, configure build path{{ ​:2018_2019:s3:methodo:​td:​configurebuildpath2018-09-02_a_19.18.10.png?​direct&​300 ​|}}  
-[[2018-2019:gitlab:ci:start|Gestion de versions]]+*/
  
-===== Analyse de la qualité : SonarQube ===== 
  
-<​accordion ​ collapsed="​true">​ 
-<​panel ​ icon="​fa fa-pencil" ​ title="​Gérer la qualité">​ 
-Générer un token 
- 
-Attention il faut etre sur le VPN 
-http://​codequal-info-01:​9000 
- </​panel>​ 
-</​accordion>​ 
2018_2019/s3/methodo/td/ci.1535907825.txt.gz · Last modified: 2018/09/02 19:03 by blay