So konfigurieren Sie Travis CI für ein .NET Core + PostgreSQL-Projekt

  • Tutorial

Ich werde erläutern, wie Sie die Komponententests so konfigurieren, dass sie automatisch im Travis CI- Dienst für ein .NET Core- Projekt ausgeführt werden, das PostgreSQL verwendet .


Sie können diesen Artikel als Beispiel für einen schnellen Einstieg verwenden.



Ich habe ein Hobbyprojekt - ein Tool für die versionierte Datenbankmigration nach .NET Core. Er kann mit mehreren DBMS arbeiten, einschließlich PostgreSQL. Das Projekt verfügt über eine Reihe von Tests ( xUnit ), für die auch PostgreSQL erforderlich ist.


Ich habe viel über Travis CI gehört und wollte es seit langem so konfigurieren, dass Tests automatisch ausgeführt werden, aber zwei Dinge haben mich davon abgehalten:


  • Es war unklar, wie Travis CI und .NET Core gekreuzt werden sollten.
  • Es ist nicht klar, wie PostgreSQL für Tests konfiguriert wird.

Nachdem ich einen halben Tag lang Dokumentation studiert und experimentiert habe, habe ich die Tests eingerichtet und möchte Ihnen davon erzählen.


Was ist Travis CI?


Travis CI ist ein kontinuierlicher Integrationsdienst für Projekte auf Github. Wenn Sie etwas an das Repository übergeben, kann Travis CI automatisch verschiedene nützliche Aktionen ausführen. Beispielsweise können Unit-Tests und Code-Linters ausgeführt werden . Ich werde diese nützlichen Aktionen das Wort "build" ("build") nennen.


Um Travis CI für Ihr Repository zu konfigurieren, müssen Sie die Repository-Adresse in der Travis CI-Weboberfläche angeben und die Datei .travis.ymlmit den Build-Einstellungen im Stammverzeichnis des Projekts ablegen .


Konfigurieren Sie Travis CI


Das erste , was zu tun - auf der Website einzuloggen https://travis-ci.org , mit Ihrem Konto GitHub. Danach sehen Sie eine Liste aller Ihrer Repositories. Klicken Sie auf den Schalter gegenüber dem Repository, für das Sie die Integration mit Travis aktivieren möchten:



Wechseln Sie anschließend zu den Einstellungen des ausgewählten Repositorys. Hier können Sie konfigurieren, in welchen Fällen Sie die Assembly ausführen müssen. Ich wies darauf hin, dass die Assembly bei jedem Push-Vorgang im Repository sowie beim Erstellen oder Ändern einer Pull-Anforderung ausgeführt werden muss. Außerdem habe ich angegeben, dass die Assembly nur gestartet werden soll, wenn sich im Stammverzeichnis des Repositorys eine Konfigurationsdatei befindet .travis.yml.



.Travis.yml Beispiel für .NET Core


Der nächste Schritt ist das Hinzufügen der .travis.ymlBuild-Einstellungsdatei zum Repository . Um ein Projekt auf .NET Core zu erstellen .travis.yml, sieht die Datei folgendermaßen aus:


language: csharp  
sudo: required  
dist: trusty  
mono: none
dotnet: 2.0.0-preview2-006497
before_script:
  - dotnet restore
script:  
  - dotnet test ./ThinkingHome.Migrator.Tests -c Release -f netcoreapp2.0

Mal sehen, was hier geschrieben steht:


  • mono: none- Dieser Parameter legt die Version von Mono fest, die für die Montage verwendet werden soll. Weil Wir erstellen ein Projekt für .NET Core. Deaktivieren Sie Mono, um keine Zeit mit der Initialisierung zu verschwenden.
  • dotnet: 2.0.0-preview2-006497- hier stellen wir die Version von .NET Core ein, die wir benötigen. Bitte beachten Sie, dass Sie die SDK-Version und nicht die Runtime-Version angeben müssen .
  • before_script:- Befehle, die ausgeführt werden müssen, bevor die Montage beginnt. Bisher haben wir hier nur ein Team dotnet restore(installieren Sie die erforderlichen Pakete von NuGet). Hier können Sie mehrere Befehle in eine separate Zeile schreiben.
  • script:- Grundlegende Build-Befehle. In unserem Fall ist dies der Start von Tests, die im Projekt sind ThinkingHome.Migrator.Tests. Beim Start werden die Konfiguration Releaseund das Zielframework verwendet netcoreapp2.0. Wenn Sie mehrere Befehle ausführen müssen, schreiben Sie diese jeweils in eine separate Zeile.

Stellen Sie vor dem Übertragen der Einstellungsdatei in das Repository sicher, dass die Befehle in den Abschnitten scriptund before_scriptlokal fehlerfrei ausgeführt werden. Übertragen Sie anschließend die Datei .travis.ymlund übertragen Sie die Änderungen auf den Remote-Server.


git add .travis.yml  
git commit -m "Add travis config file"  
git push

Nach einigen Sekunden sehen wir, dass Travis unsere Änderungen sah und mit der Montage begann. Sie können detaillierte Informationen über die Assembly anzeigen, einschließlich aller Informationen, die in der Konsole angezeigt wurden. Wir sehen, dass .NET Core installiert und Tests gestartet wurden.



Wir sehen auch, dass die Tests da runtergefallen sind Sie greifen auf eine Datenbank zu, die ihnen nicht zur Verfügung steht.




PostgreSQL-Verbindung


Verbinden wir PostgreSQL mit unserer Assembly. Fügen Sie dazu den .travis.ymlAbschnitt servicesmit dem Datensatz postgresqlund den before_scriptBefehl zum Erstellen einer Datenbank für Tests mit dem Dienstprogramm hinzu psql.


services:
  - postgresql
before_script:
  - psql -c "CREATE DATABASE migrations;" -U postgres
  ...

Standardmäßig ist eine Datenbank verfügbar postgres, mit der Sie sich als Benutzer postgresohne Kennwort verbinden können. Um nicht von diesen Standardeinstellungen abhängig zu sein, erstellen wir einen separaten Benutzer und eine separate Datenbank für Tests. Wenn Sie etwas mit der neuen Datenbank tun müssen, vergessen Sie nicht, ihren Namen im Parameter anzugeben -d.


Der vollständige Text der Datei ist .travis.ymlunten angegeben:


language: csharp  
sudo: required  
mono: none
dotnet: 2.0.0-preview2-006497
dist: trusty  
services:
  - postgresql
before_script:
  - psql -c "CREATE DATABASE migrations;" -U postgres
  - psql -c "CREATE USER migrator WITH PASSWORD '123';" -U postgres  
  - psql -c 'CREATE SCHEMA "Moo" AUTHORIZATION migrator;' -U postgres -d migrations  
  - dotnet restore
script:  
  - dotnet test ./ThinkingHome.Migrator.Tests -c Release -f netcoreapp2.0

Übernehmen Sie die geänderte Datei und übertragen Sie sie auf den Remote-Server. Tada !!! Diesmal waren die Tests erfolgreich!



Fazit


Großartig! Wir haben herausgefunden, wie Travis CI mit PostgreSQL für unser .NET Core-Projekt konfiguriert werden kann. Jetzt können wir der Readme-Datei unseres Projekts ein Tag hinzufügen, das das Ergebnis des letzten Builds mit dem Shields.io- Dienst anzeigt .


[![Travis](https://img.shields.io/travis/thinking-home/migrator.svg)](https://travis-ci.org/thinking-home/migrator)


Vielen Dank für Ihre Aufmerksamkeit!


Jetzt auch beliebt: