Aspect Devops du projet

Différentes Branches

Lors de notre première interaction avec Monsieur Castiaux, nous n'avions encore rien implémenté.
Après celle-ci, nous avons décidé de mettre en place ces solutions :

• Utiliser le VCS présent dans Android studio pour réaliser nos commits sur le github.
  
• Nous utiliserons des branches qui correspondent aux User stories.
  
• Lors de chaque merge il faudra réaliser un pull request validé par un autre membre du groupe avec un commentaire complet.
  
• Nous devons réaliser des Units tests et des test d'intégration et les montrer à Monsieur Castiaux.
  
• Ces tests seront effectués avant chaque pull pour ne permettre qu'aux codes fonctionnels d'être ajoutés au repository.

Dans un premier temps, lors que nous avons tenté d'effectuer nos premiers merge, nous nous sommes confrontés à des problèmes. En effet, le fait d'utiliser des outils déjà présents dans Android Studio ou Github Desktop nous ont grandement limité, ceux-ci ne prenant pas certaines fonctionnalités des commandes Git directement utilisables en ligne de commandes.
Lorsque nous avons revu Monsieur Castiaux, il nous a expliqué comment réaliser des merges directement en ligne de commande, cette méthode nous a permis d'éviter de multiples erreurs.
Une fois ces premières erreurs passées, nous nous sommes confrontés aux conflits des branches Github, Github nous propose directement de soit :

• Corriger ce(s) problème(s) de conflit
• Visualiser dans quel(s) fichier(s) se situe(nt) ce(s) conflit(s)

Lorsque la première option est disponible, nous utilisons le correcteur en ligne de Github qui facilite grandement la tâche lorsque nous devons résoudre ces conflits.
Si cette première option n'est pas disponible en raison de conflits trop complexes, nous regardons où se situent les conflits et nous les corrigeons directement dans notre éditeur Android Studio.
Nous nous sommes rendus compte que plus nous faisions de merge régulier, plus il était de facile de corriger nos conflits, c'est pourquoi nous essayons d'en effectuer un maximum possible.

Auto Déploiement et Test Automatiques

Ainsi, nous avons à présent un second Linter vérifiant notre syntaxe lors de chaque pull request vers notre main, ainsi que des tests unitaires automatisés sur nos branches, bien que ceux-ci ne soient pas encore en nombre suffisant.
En effet, chaque fois que nous réalisons un merge vers notre branche main, Github va simuler notre projet pour vérifier qu'aucun conflit n'a lieu, pour ce faire, il reprend notre Gradle et reconstruit notre application à partir de celui-ci, nous avons donc un auto déploiement fonctionnel.
Après cette première phase de construction de projet, les tests unitaires écrits s'exécutent et si une erreur apparaît c'est que nos tests ne passent pas correctement. Pour éviter certaines erreurs de déploiement, nous avons également dû placer le fichier .idea dans le .gitignore .