Intégration continue

Salutations, collègues! Fatigué de forcer votre ordinateur à créer constamment un projet ? Alors cet article est fait pour vous ! Dans cet article, je vais essayer de présenter brièvement et clairement le matériel concernant l'intégration continue (ci-après simplement CI), je répondrai à des questions aussi simples que : « Qu'est-ce que c'est ? », « Pourquoi ? et pourquoi?" et je vais donner un exemple de projet de test. Cet article est destiné à un utilisateur expérimenté qui connaît au moins Build System: Maven , sait utiliser Git et sait comment pousser des projets vers GitHub ;

"Qu'est-ce que l'intégration continue ?"

Voyons ce que Wiki nous dit à propos de cette question : L'intégration continue (CI, anglais Continuous Integration) est une pratique de développement logiciel qui consiste à fusionner des copies de travail dans une branche de développement principale commune plusieurs fois par jour et à effectuer des builds automatisés fréquents du projet au début. détection des défauts potentiels et solutions aux problèmes d’intégration. Effrayant, n'est-ce pas ? Essayons d'expliquer ce terme avec des mots simples : L'intégration continue est un système de construction et de test automatisé de logiciels avec certaines configurations sur certaines machines afin de détecter les bugs et les incompatibilités. D'accord, pas de problème, nous l'avons compris, mais la question logique suivante se pose :

Pourquoi avons-nous besoin de CI ?

Imaginons simplement que vous écrivez un grand projet et qu'il soit nécessaire d'ajouter/modifier des fonctionnalités. Vous l'écrivez avec succès, écrivez des tests, le lancez et tout semble bien se passer, mais non. Il existe des situations où un changement dans une fonctionnalité en affecte une autre, une autre sur une troisième, et ainsi de suite, jusqu'à ce qu'un bug se glisse quelque part et qu'une erreur se produise. Oui, vous pouvez dire qu’il s’agit très probablement d’un projet mal conçu, et vous avez peut-être raison, mais que se passe-t-il si ce n’est pas le cas et que ces connexions devraient vraiment être là ? Et que se passe-t-il si vous écrivez et créez un projet plus d’une fois, ce qui est souvent le cas ? Vous avez effectué des tests sur vos fonctionnalités nouvellement écrites et ils ont donné un résultat positif. Vous vous êtes engagé rapidement, puis vous êtes allé quelque part et vous réfléchissez déjà à la façon dont vous fumerez un cigare à la maison tout en buvant du whisky cher, mais non. Hélas, votre collègue ou votre patron, peu importe qui, dit qu'à cause de votre commit, toute la version s'est écrasée. Vous dites avec perplexité que vous êtes programmeur, vous avez tout testé. Mais souvent, vous n'avez tout simplement pas le temps de tester constamment l'ensemble du projet, et vous n'avez testé que votre morceau de code auquel vous avez apporté des modifications, et non l'ensemble de l'assembly dans son ensemble. C’est là que CI vient à notre aide. À chaque poussée vers n'importe quelle ressource, CI construira votre projet à partir de zéro, exécutera TOUS les tests, et seulement si tous les tests réussissent et que le projet est construit, la construction recevra le statut de réussite . Sinon, vous aurez l'occasion de faire un retour et de voir ce qui n'a pas fonctionné. Il est donc temps de se poser la question « Pourquoi ceci et pas autrement ? et jetez un œil à la mise en œuvre du logiciel. Exemple Comme je l'ai déjà dit, l'article est destiné à ceux qui connaissent Maven et Git. Par conséquent, j'espère que vous savez comment et ce que je fais en plus de configurer CI, etc.

1. Tout d’abord, créons un projet de test Maven simple et créons-y une classe qui affiche « Hello World ! » et effectue une opération simple, et écrivons le test le plus simple pour cette classe.

   En conséquence, nous devrions avoir une structure de projet primitive :

   Toutes les sources seront sur mon GitHub. Peu importe ce que vous écrivez dans votre Main et quels tests il y aura.

2. Nous poussons notre projet sur GitHub.

3. Vient maintenant la partie amusante. Chez CI, j'ai choisi Travis CI en raison de sa disponibilité et de sa fiabilité. Travis utilise GitHub pour héberger son code source.

   Alors, allez sur le site Web de Travis CI et connectez-vous via GitHub. Dans le profil, nous connectons notre projet :

   Tout est prêt à être assemblé à chaque poussée, mais la question est COMMENT assembler ?

4. Nous revenons à notre IDÉE bien-aimée et créons un fichier .travis.yml

   Ce fichier est responsable de la configuration de build Travis. Examinons le paramètre le plus populaire :

   • Vous devez spécifier la langue dans laquelle le projet est mis en œuvre ;
   • Spécifiez le chemin d'accès aux répertoires pour accélérer la construction ;
   • Spécifiez la méthode de notification concernant l'assemblage réussi ou échoué.

   Voici à quoi devrait ressembler une configuration Travis typique :

   # https://docs.travis-ci.com/user/languages/java/
   language: java
   jdk: oraclejdk9
   
   # Improve Build Speed https://dzone.com/articles/travis-ci-tutorial-java-projects
   cache:
     directories:
     - $HOME/.m2
   
   # Notifications https://docs.travis-ci.com/user/notifications/
   notifications:
     email:
       recipients:
         - qThegamEp@gmail.com
       on_success: always # default: change
       on_failure: always # default: always

   J'ai ajouté des commentaires, avec des liens, pour plus de clarté.

5. Nous poussons à nouveau vers GitHub et ouvrons le site Web de Travis , sélectionnons le projet et surveillons la construction. En conséquence, nous recevons une notification concernant une build réussie :

   Également sur le site, nous pouvons voir un badge avec l'assemblage réussi de notre projet, que nous pouvons insérer dans notre README.md :

Liens utiles:

• Mon projet de test que vous pouvez consulter/télécharger si vous ne comprenez pas quelque chose ;

• En fait, le site Web de Travis CI lui-même ;

• Tutoriel sur le site officiel sur la configuration et l'utilisation de Travis CI ;

• Bonne vidéo ;

• Un autre tutoriel ;

• Article suivant

Il peut y avoir des erreurs et des omissions dans le texte. Merci pour votre attention!