Einrichtung für Continuous Integration und Deployment mit CircleCI und Coveralls

Continuous Integration (CI) und Continuous Deployment (CD) sind entscheidende Entwicklungspraktiken, insbesondere für Teams. Jedes Projekt ist fehleranfällig, unabhängig von seiner Größe. Aber wenn ein CI/CD-Prozess mit gut geschriebenen Tests eingerichtet ist, sind diese Fehler viel einfacher zu finden und zu beheben.

In diesem Artikel werden wir uns ansehen, wie man die Testabdeckung prüft, einen CI/CD-Prozess einrichtet, der CircleCI und Coveralls verwendet, und eine Vue-Anwendung auf Heroku bereitstellt. Selbst wenn dieser genaue Werkzeugkasten nicht Ihr Ding ist, werden die Konzepte, die wir behandeln, für alles in Ihrer Einrichtung hilfreich sein. Zum Beispiel kann Vue durch ein anderes JavaScript-Framework ersetzt werden, und die Grundprinzipien bleiben relevant.

Hier ist ein kleiner Überblick über die Terminologie, bevor wir richtig loslegen

Continuous Integration: Dies ist eine Praxis, bei der Entwickler Code früh und häufig committen, den Code verschiedenen Test- und Build-Prozessen unterziehen, bevor er zusammengeführt oder bereitgestellt wird.
Continuous Deployment: Dies ist die Praxis, Software jederzeit produktionsreif zu halten.
Testabdeckung: Dies ist ein Maß, das verwendet wird, um den Grad der getesteten Software zu beschreiben. Ein Programm mit hoher Abdeckung bedeutet, dass der Großteil des Codes getestet wird.

Um diesen Tutorial bestmöglich nutzen zu können, sollten Sie Folgendes besitzen

CircleCI-Konto: CircleCI ist eine CI/CD-Plattform, die wir für die automatisierte Bereitstellung verwenden werden (einschließlich des Testens und Erstellens unserer Anwendung vor der Bereitstellung).
GitHub-Konto: Wir werden das Projekt und seine Tests in einem Repository speichern.
Heroku-Konto: Heroku ist eine Plattform, die zum Bereitstellen und Skalieren von Anwendungen verwendet wird. Wir werden sie für die Bereitstellung und das Hosting nutzen.
Coveralls-Konto: Coveralls ist eine Plattform, die zur Aufzeichnung und Anzeige der Codeabdeckung verwendet wird.
NYC: Dies ist ein Paket, das wir zur Überprüfung der Codeabdeckung verwenden werden.

Ein Repository, das das in diesem Beitrag behandelte Beispiel enthält, ist auf GitHub verfügbar.

Lasst uns alles einrichten

Zuerst installieren wir NYC im Projektordner

npm i nyc

Als Nächstes müssen wir die Skripte in package.json bearbeiten, um die Testabdeckung zu überprüfen. Wenn wir versuchen, die Abdeckung während der Ausführung von Unit-Tests zu überprüfen, müssten wir das Testskript bearbeiten

"scripts": {
  "test:unit": "nyc vue-cli-service test:unit",
},

Dieser Befehl geht davon aus, dass wir die App mit Vue erstellen, die eine Referenz auf vue-cli-service enthält. Der Befehl muss geändert werden, um das im Projekt verwendete Framework widerzuspiegeln.

Wenn wir versuchen, die Abdeckung separat zu überprüfen, müssen wir eine weitere Zeile zu den Skripten hinzufügen

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

Jetzt können wir die Abdeckung mit einem Terminalbefehl überprüfen

npm run coverage

Als Nächstes installieren wir Coveralls, das für die Berichterstattung und Anzeige der Abdeckung zuständig ist

npm i coveralls

Jetzt müssen wir Coveralls als weiteres Skript in package.json hinzufügen. Dieses Skript hilft uns, unseren Testabdeckungsbericht bei Coveralls zu speichern.

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

Gehen wir zu unserem Heroku-Dashboard und registrieren unsere App dort. Heroku werden wir zum Hosten verwenden.

Wir werden CircleCI verwenden, um unseren CI/CD-Prozess zu automatisieren. Gehen Sie zum CircleCI-Dashboard, um unser Projekt einzurichten.

Wir können unsere Projekte über den Tab Projekte in der Seitenleiste von CircleCI aufrufen, wo wir die Liste unserer Projekte in unserer GitHub-Organisation sehen sollten. Klicken Sie auf die Schaltfläche „Projekt einrichten“. Dies führt uns zu einer neuen Seite, auf der wir gefragt werden, ob wir eine vorhandene Konfiguration verwenden möchten. Wir haben tatsächlich unsere eigene Konfiguration, also wählen wir die Option „Vorhandene Konfiguration verwenden“.

Danach gelangen wir zur Pipeline des ausgewählten Projekts. Großartig! Wir haben unser Repository mit CircleCI verbunden. Fügen wir nun unsere Umgebungsvariablen zu unserem CircleCI-Projekt hinzu.

Um Variablen hinzuzufügen, müssen wir zu den Projekteinstellungen navigieren.

Die Projekteinstellungen haben einen Tab Umgebungsvariablen in der Seitenleiste. Hier möchten wir unsere Variablen speichern.

Für dieses Tutorial benötigte Variablen sind

Der Heroku App-Name: HEROKU_APP_NAME
Unser Heroku API-Schlüssel: HEROKU_API_KEY
Das Coveralls Repository-Token: COVERALLS_REPO_TOKEN

Der Heroku API-Schlüssel kann im Abschnitt „Account“ des Heroku-Dashboards gefunden werden.

Das Coveralls Repository-Token befindet sich auf dem Coveralls-Konto des Repositorys. Zuerst müssen wir das Repository zu Coveralls hinzufügen, was wir tun, indem wir das GitHub-Repository aus der Liste der verfügbaren Repositories auswählen.

Nachdem wir das Repository zu Coveralls hinzugefügt haben, können wir das Repository-Token abrufen, indem wir auf das Repository klicken.

CircleCI integrieren

Wir haben Circle CI bereits mit unserem GitHub-Repository verbunden. Das bedeutet, dass CircleCI über jede Änderung oder Aktion im GitHub-Repository informiert wird. Was wir jetzt tun wollen, ist, die Schritte durchzugehen, um CircleCI über die Operationen zu informieren, die es nach Erkennung einer Änderung im Repository ausführen soll.

Im Stammordner unseres Projekts erstellen wir lokal einen Ordner namens .circleci und darin eine Datei namens config.yml. Hier werden alle Operationen von CircleCI stattfinden.

Hier ist der Code, der in diese Datei kommt

version: 2.1
orbs:
  node: circleci/[email protected] // node orb 
  heroku: circleci/[email protected] // heroku orb
  coveralls: coveralls/[email protected] // coveralls orb
workflows:
  heroku_deploy:
    jobs:
      - build
      - heroku/deploy-via-git: # Use the pre-configured job
        requires:
          - build
        filters:
          branches:
            only: master
jobs:
  build:
    docker:
      - image: circleci/node:10.16.0
    steps:
      - checkout
      - restore_cache:
        key: dependency-cache-{{ checksum "package.json" }}
      - run:
        name: install-npm-dependencies
        command: npm install
      - save_cache:
        key: dependency-cache-{{ checksum "package.json" }}
        paths:
          - ./node_modules
      - run: # run tests
        name: test
        command: npm run test:unit
      - run: # run code coverage report
        name: code-coverage
        command: npm run coveralls
      - run: # run build
        name: Build
        command: npm run build
      # - coveralls/upload

Das ist ein großer Codeblock. Lassen Sie uns ihn aufschlüsseln, damit wir wissen, was er tut.

Orbs

orbs:
  node: circleci/[email protected] // node orb 
  heroku: circleci/[email protected] // heroku orb
  coveralls: coveralls/[email protected] // coveralls orb

Orbs sind Open-Source-Pakete, die zur Vereinfachung der Integration von Software und Paketen über Projekte hinweg verwendet werden. In unserem Code geben wir die Orbs an, die wir für den CI/CD-Prozess verwenden. Wir haben den node Orb referenziert, da wir JavaScript verwenden. Wir haben heroku referenziert, da wir einen Heroku-Workflow für die automatisierte Bereitstellung nutzen. Und schließlich referenzieren wir den coveralls Orb, da wir die Testergebnisse an Coveralls senden wollen.

Die Heroku- und Coverall-Orbs sind externe Orbs. Wenn wir die App jetzt durch Tests laufen lassen, lösen diese einen Fehler aus. Um den Fehler zu beheben, müssen wir zur Seite „Organisationseinstellungen“ im CircleCI-Konto navigieren.

Navigieren Sie dann zum Tab Sicherheit und erlauben Sie unspezifizierte Orbs

Workflows

workflows:
  heroku_deploy:
    jobs:
      - build
      - heroku/deploy-via-git: # Use the pre-configured job  
          requires:
            - build
          filters:
            branches:
              only: master

Ein Workflow wird verwendet, um eine Sammlung von Jobs zu definieren und sie in Reihenfolge auszuführen. Dieser Abschnitt des Codes ist für das automatisierte Hosting zuständig. Er weist CircleCI an, das Projekt zu erstellen und dann bereitzustellen. requires bedeutet, dass der Job heroku/deploy-via-git den Abschluss des Builds erfordert – das heißt, er wartet auf den Abschluss des Builds vor der Bereitstellung.

Jobs

jobs:
  build:
    docker:
      - image: circleci/node:10.16.0
    steps:
      - checkout
      - restore_cache:
          key: dependency-cache-{{ checksum "package.json" }}
      - run:
          name: install-npm-dependencies
          command: npm install
      - save_cache:
          key: dependency-cache-{{ checksum "package.json" }}
          paths:
            - ./node_modules

Ein Job ist eine Sammlung von Schritten. In diesem Abschnitt des Codes stellen wir die Abhängigkeiten wieder her, die während der vorherigen Builds durch den Job restore_cache installiert wurden.

Danach installieren wir die nicht gecachten Abhängigkeiten und speichern sie, damit sie beim nächsten Build nicht neu installiert werden müssen.

Dann weisen wir CircleCI an, die für das Projekt geschriebenen Tests auszuführen und die Testabdeckung des Projekts zu überprüfen. Beachten Sie, dass das Caching von Abhängigkeiten nachfolgende Builds beschleunigt, da wir die Abhängigkeiten speichern und somit die Notwendigkeit der Installation dieser Abhängigkeiten beim nächsten Build entfällt.

Hochladen unserer Codeabdeckung zu Coveralls

- run: # run tests
    name: test
    command: npm run test:unit
  - run: # run code coverage report
    name: code-coverage
    command: npm run coveralls
# - coveralls/upload

Hier geschieht die Coveralls-Magie, denn hier führen wir tatsächlich unsere Unit-Tests aus. Erinnern Sie sich, als wir den nyc Befehl zum test:unit Skript in unserer package.json Datei hinzugefügt haben? Dank dessen liefern Unit-Tests nun Codeabdeckung.

Unit-Tests liefern ebenfalls Codeabdeckung, daher werden wir diese in den Abdeckungsbericht aufnehmen. Deshalb rufen wir diesen Befehl hier auf.

Und zuletzt führt der Code das Coveralls-Skript aus, das wir in package.json hinzugefügt haben. Dieses Skript sendet unseren Abdeckungsbericht an Coveralls.

Sie haben vielleicht bemerkt, dass die Zeile coveralls/upload auskommentiert ist. Dies sollte das abschließende Zeichen des Prozesses sein, wurde aber am Ende eher zu einem Blocker oder, in Entwicklerbegriffen, zu einem Bug. Ich habe sie auskommentiert, da sie für einen anderen Entwickler ein Trumpf sein könnte.

Putting everything together

Sehen Sie sich unsere App an, komplett mit Continuous Integration und Deployment!

A screenshot of CircleCI showing 9 successful development, test, and build steps. — Ein erfolgreicher Build

Continuous Integration und Deployment helfen in so vielen Fällen. Ein häufiges Beispiel wäre, wenn die Software sich in einer Testphase befindet. In dieser Phase finden viele Commits für viele Korrekturen statt. Das Letzte, was ich als Entwickler tun möchte, wäre, nach jeder kleinen Änderung manuell Tests auszuführen und meine Anwendung manuell bereitzustellen. Igitt. Ich hasse Wiederholungen!

Ich weiß nicht, wie es Ihnen geht, aber CI und CD sind Dinge, die ich schon seit einiger Zeit kenne, aber ich habe immer Wege gefunden, sie beiseite zu schieben, weil sie entweder zu schwierig oder zeitaufwendig klangen. Aber jetzt, da Sie gesehen haben, wie relativ wenig Einrichtung erforderlich ist und welche Vorteile damit verbunden sind, fühlen Sie sich hoffentlich ermutigt und bereit, es mit einem eigenen Projekt auszuprobieren.