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

Next revision
Previous revision
2018_2019:s3:methodo:td:ci [2018/08/12 08:53]
blay created
2018_2019:s3:methodo:td:ci [2018/09/02 22:07] (current)
blay [Analyse de la qualité : SonarQube]
Line 1: Line 1:
 ====== Intégration continue ====== ====== Intégration continue ======
  
-Objectifs : mettre en place une intégration continue minimale+Objectifs : mettre en place une intégration continue minimale ​associée à votre projet gitlab
  
-NOus allons à présent reprendre les codes donnés lors du premier exercice, les placer sous contrôle de version (GIT) et mettre en placce ​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''​**
 +  - 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.
  
 +/*        - clique droit sur le projet, configure build path{{ :​2018_2019:​s3:​methodo:​td:​configurebuildpath2018-09-02_a_19.18.10.png?​direct&​300 |}} 
 +*/
  
-PENSEZ à revenir sur le 1e TD pour connecter SONAR 
-[[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.1534056821.txt.gz · Last modified: 2018/08/12 08:53 by blay