Une configuration d'intégration et de déploiement continu avec circleci et couvertures

L'intégration continue (IC) et le déploiement continu (CD) sont des pratiques de développement cruciales, en particulier pour les équipes. Quelle que soit la taille du projet, les erreurs sont susceptibles de se produire. Cependant, si un processus CI / CD avec de bons tests est configuré, il est plus facile de détecter et de corriger ces erreurs.

Cet article expliquera comment vérifier la couverture des tests, configurer un processus CI / CD à l'aide de Circleci et Coveralls, et déployer des applications Vue à Heroku. Même si vous n'utilisez pas ces outils, les concepts présentés dans cet article sont toujours utiles pour votre configuration. Par exemple, Vue peut être remplacé par d'autres frameworks JavaScript, et les principes de base s'appliquent toujours.

Avant de commencer, apprenez quelques termes:

• Intégration continue: les développeurs soumettent fréquemment du code, effectuant divers processus de test et de création avant de fusionner ou de déployer.
• Déploiement continu: pratique qui rend les logiciels toujours déployables dans les environnements de production.
• Couverture de test: une mesure utilisée pour décrire le degré de tests logiciels. Un programme avec une couverture élevée signifie que la majeure partie du code a été testée.

Pour tirer le meilleur parti de ce tutoriel, vous devriez remplir les conditions suivantes:

• Compte Circleci: Nous utiliserons Circleci, la plate-forme CI / CD pour le déploiement automatisé (y compris les applications de test et de création avant le déploiement).
• Compte GitHub: nous stockons des projets et leurs tests dans le référentiel.
• Compte Heroku: Nous utiliserons la plate-forme Heroku pour déployer et étendre les applications.
• Compte CoverAlls: CoverAlls est une plate-forme pour enregistrer et afficher la couverture du code.
• NYC: Nous utiliserons ce package pour vérifier la couverture du code.

Un référentiel contenant les exemples de cet article est disponible sur GitHub.

Démarrer le réglage

Tout d'abord, installez NYC dans le dossier du projet:

 <code>npm i nyc</code>

Ensuite, nous devons modifier le script dans package.json pour vérifier la couverture du test. Si nous essayons de vérifier la couverture lors de l'exécution de tests unitaires, nous devons modifier le script de test:

 <code>"scripts": { "test:unit": "nyc vue-cli-service test:unit", },</code>

Cette commande suppose que nous utilisons Vue pour créer l'application en référence à vue-cli-service . Cette commande doit être modifiée pour refléter le cadre utilisé dans le projet.

Si nous essayons de vérifier la couverture séparément, nous devons ajouter une autre ligne au script:

 <code>"scripts": { "test:unit": "nyc vue-cli-service test:unit", "coverage": "nyc npm run test:unit" },</code>

Nous pouvons maintenant vérifier la couverture en utilisant la commande du terminal:

 <code>npm run coverage</code>

Ensuite, nous installerons CoverAlls, qui est responsable de la déclaration et de l'affichage de la couverture:

 <code>npm i coveralls</code>

Maintenant, nous devons ajouter des couvertures comme un autre script dans package.json . Ce script nous aide à enregistrer le rapport de couverture de test sur Coveralls.

 <code>"scripts": { "test:unit": "nyc vue-cli-service test:unit", "coverage": "nyc npm run test:unit", "coveralls": "nyc report --reporter=text-lcov | coveralls" },</code>

Allons au tableau de bord Heroku et inscrivons notre application là-bas. Nous utiliserons Heroku pour l'héberger.

Nous utiliserons Circleci pour automatiser notre processus CI / CD. Continuez à visiter le tableau de bord Circleci pour mettre en place nos projets.

Nous pouvons accéder à notre projet via l'onglet Projets dans la barre latérale Circleci, où nous devrions voir une liste de projets dans notre organisation GitHub. Cliquez sur le bouton Définir le projet. Cela nous amènera à une nouvelle page pour nous demander si nous voulons utiliser une configuration existante. Nous avons notre propre configuration, alors sélectionnons l'option "Utiliser la configuration existante".

Après cela, nous irons au pipeline sélectionné. Très bien! Nous avons fait le travail de connexion de notre référentiel à Circleci. Maintenant, ajoutons nos variables d'environnement à notre projet Circleci.

Pour ajouter des variables, nous devons naviguer vers les paramètres du projet.

Les paramètres du projet ont une onglet Variables d'environnement dans la barre latérale. C'est là que nous voulons stocker des variables.

Variables requises pour ce tutoriel:

• Nom de l'application HEROKU: HEROKU_APP_NAME
• Notre clé API Heroku: HEROKU_API_KEY
• COVERALLS REPOSERTY TOKEN: COVERALLS_REPO_TOKEN

La clé de l'API Heroku se trouve dans la section des comptes du tableau de bord Heroku.

Le jeton de référentiel CoverAlls est situé dans le compte CoverAlls du référentiel. Tout d'abord, nous devons ajouter le référentiel à Coveralls en sélectionnant le référentiel GitHub dans la liste des référentiels disponibles.

Nous avons maintenant ajouté le référentiel à Coveralls. Nous pouvons obtenir le jeton de référentiel en cliquant sur le référentiel.

Intégrer les circleci

Nous avons connecté Circle CI à notre référentiel GitHub. Cela signifie que Circleci sera informé lorsque des modifications ou des actions se produisent dans le référentiel GitHub. Ce que nous devons faire maintenant, c'est effectuer les étapes pour informer Circleci sur les actions que nous voulons qu'elle exécute après avoir détecté un changement de référentiel.

Dans le dossier racine du projet local, créons un dossier appelé .circleci et créons un fichier appelé config.yml . C'est là que se trouvent toutes les opérations de circleci.

Voici le code contenu dans le fichier:

 Version: 2.1
Orbes:
  Node: circleci / [e-mail protégé] # Orb de nœud
  Heroku: Circleci / [Protégé par e-mail] # HEROKU ORB
  CoverAlls: CoverAlls / [Protégé par e-mail] # CoverAlls Orb
flux de travail:
  HEROKU_DEPLOY:
    Emplois:
      - construire
      - Heroku / Deploy-via-git: # Utilisez des exigences de travail préconfigurées:
          - construire
        Filtres:
          Branches:
            Seulement: maître
Emplois:
  construire:
    docker:
      - Image: circleci / nœud: 10.16.0
    Mesures:
      - vérifier
      - restore_cache:
        clé: dépendance-cache - {{chèque "package.json"}}
      - courir:
        Nom: Installer-NPM-Dépendances
        Commande: Installation de NPM
      - Save_Cache:
        clé: dépendance-cache - {{chèque "package.json"}}
        Chemins:
          - ./Node_Modules
      - Exécuter: # Exécuter Nom du test: Test
        Commande: NPM Run Test: Unité
      - Exécuter: # Exécuter Nom du rapport de la couverture du code: Coverage de code
        Commande: NPM Run CoverAlls
      - Exécuter: # Exécuter le nom de la construction: build
        Commande: NPM Run Build
      # - Coveralls / Téléchargement

Ceci est un grand morceau de code. Décomposons-le pour que nous sachons ce que cela fait.

Orbes

 Orbes:
  Node: circleci / [e-mail protégé] # Orb de nœud
  Heroku: Circleci / [Protégé par e-mail] # HEROKU ORB
  CoverAlls: CoverAlls / [Protégé par e-mail] # CoverAlls Orb

Orbs est un package open source qui simplifie l'intégration des logiciels et des packages entre les projets. Dans notre code, nous soulignons les ORB pour le processus CI / CD. Nous avons référencé Node Orb car nous utilisons JavaScript. Nous citons Heroku parce que nous utilisons le flux de travail Heroku pour un déploiement automatisé. Enfin, nous référentes les couvertures ORB car nous prévoyons d'envoyer des résultats de couverture sur les couvertures.

Heroku et Coverall Orbes sont des orbes externes. Donc, si nous exécutons l'application maintenant via des tests, ceux-ci déclencheront des erreurs. Pour éliminer l'erreur, nous devons naviguer vers la page Paramètres de l'organisation dans notre compte Circleci.

Ensuite, accédez à l'onglet de sécurité et permettons des orbes non authentifiés:

Flux de travail

 flux de travail:
  HEROKU_DEPLOY:
    Emplois:
      - construire
      - Heroku / Deploy-via-git: # Utilisez des exigences de travail préconfigurées:
          - construire
        Filtres:
          Branches:
            Seulement: maître

Les workflows sont utilisés pour définir des collections de travaux et les exécuter séquentiellement. Cette partie du code est responsable de l'hébergement automatisé. Il dit à Circleci de construire le projet, puis de le déployer. requires signifie que heroku/deploy-via-git doit être construit-complet - ce qui signifie qu'il attendra que la construction se termine avant le déploiement.

Opération

 Emplois:
  construire:
    docker:
      - Image: circleci / nœud: 10.16.0
    Mesures:
      - vérifier
      - restore_cache:
          clé: dépendance-cache - {{chèque "package.json"}}
      - courir:
          Nom: Installer-NPM-Dépendances
          Commande: Installation de NPM
      - Save_Cache:
          clé: dépendance-cache - {{chèque "package.json"}}
          Chemins:
            - ./Node_Modules

Un travail est une collection d'étapes. Dans cet extrait de code, nous avons restauré les dépendances installées lors du processus de construction précédent via restore_cache .

Après cela, nous installons les dépendances non achetées, puis les enregistrons afin que nous n'ayons pas besoin de les réinstaller lors de la prochaine version.

Nous disons ensuite à Circleci d'exécuter les tests que nous avons écrits pour le projet et de vérifier la couverture des tests du projet. Notez que les dépendances en cache facilitent les constructions ultérieures car nous stockons les dépendances, il n'est donc pas nécessaire de les installer lors de la version suivante.

Téléchargez notre couverture de code sur Coveralls

 - Exécuter: # Exécuter Nom du test: Test
    Commande: NPM Run Test: Unité
  - Exécuter: # Exécuter Nom du rapport de la couverture du code: Coverage de code
    Commande: NPM Run CoverAlls
# - Coveralls / Téléchargement

C'est la magie des couvertures parce que nous exécutons en fait des tests unitaires ici. Rappelez-vous quand nous avons ajouté la commande nyc dans test:unit du fichier package.json ? Grâce à cela, les tests unitaires offrent désormais une couverture de code.

Les tests unitaires fournissent également une couverture de code, nous les inclurons donc dans le rapport de couverture. C'est pourquoi nous appelons la commande ici.

Enfin, le code exécute le script CoverAlls que nous avons ajouté dans package.json . Ce script envoie notre rapport de couverture à Coveralls.

Vous avez peut-être remarqué que coveralls/upload est commentée. C'était à l'origine le caractère final du processus, mais à la fin, il est devenu une barrière ou une erreur dans la terminologie du développeur. Je l'ai commenté car il pourrait s'agir de la carte Trump d'un autre développeur.

Tout assembler

Regarder! Nos applications, y compris l'intégration et le déploiement continus!

L'intégration et le déploiement continus peuvent aider dans de nombreux cas. Un exemple courant est lorsque le logiciel est en phase bêta. À ce stade, de nombreuses soumissions se produiront pour de nombreuses corrections. En tant que développeur, la dernière chose que je veux faire est d'exécuter des tests manuellement et de déployer mon application manuellement après chaque petit changement. Ughhh. Je déteste la répétition!

Je ne sais pas comment vous êtes, mais je connais CI et CD depuis un certain temps, mais je trouve toujours des moyens de les mettre de côté parce qu'ils semblent trop durs ou trop longs. Mais maintenant que vous avez vu la configuration relativement simple et les avantages qui l'accompagnent, j'espère que vous serez inspiré et prêt à essayer votre propre projet en personne.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!