CI/CD konzipieren #4

New issue

Closed

opened 2025-04-02 14:42:19 +02:00 by moritz · 3 comments

moritz commented

2025-04-02 14:42:19 +02:00

Owner

Welche Actions sollen erledigt werden?
Welche Tools sollen dafür verwendet werden?

Welche Actions sollen erledigt werden? Welche Tools sollen dafür verwendet werden?

rafael was assigned by moritz

2025-04-02 14:42:19 +02:00

moritz added this to the Sprint 0 - Vorarbeit project 2025-04-02 14:42:20 +02:00

simon commented

2025-04-03 10:50:01 +02:00

Owner

Ich hab bisher meistens mit Jenkins gearbeitet, der ja doch grundlegend anders funktioniert.

Aber wir haben damit bei jedem main-Commit gebuilded, ein docker-image in ein repo gepushed, auf eine Testinstanz deployed und Integrationstests ausgeführt.

Entwicklung erfolgte auf feature-branch ebene. Bei Bedarf konnten wir auch feature-branch deployments zum Testen durchführen, also vorm Mergen von PRs.

Lass gerne schauen was davon wir wann brauchen, aber ich habe das ziemlich gefeiert. So kommt auch niemand auf die Idee manuell Releases zu bauen

Ich hab bisher meistens mit Jenkins gearbeitet, der ja doch grundlegend anders funktioniert. Aber wir haben damit bei jedem main-Commit gebuilded, ein docker-image in ein repo gepushed, auf eine Testinstanz deployed und Integrationstests ausgeführt. Entwicklung erfolgte auf feature-branch ebene. Bei Bedarf konnten wir auch feature-branch deployments zum Testen durchführen, also vorm Mergen von PRs. Lass gerne schauen was davon wir wann brauchen, aber ich habe das ziemlich gefeiert. So kommt auch niemand auf die Idee manuell Releases zu bauen

rafael commented

2025-04-07 13:27:07 +02:00

Collaborator

Genau wie Simon bin ich großer Fan von review-environments und voll automatisierten releases. Hier ein Vorschlag für das Setup:

Checks

Hier wird überprüft, dass alles im Projekt so funktioniert wie es soll.

Code-formatierung checken: mix format
Postgres-Instanz für Tests starten
Tests laufen lassen: mix test
Verifizieren, dass Migrations durchlaufen
Sicherstellen, dass es keine Fehler oder Warnungen beim kompilieren gibt: mix compile --warnings-as-errors. In diesem Schritt hat elixir inzwischen einen grundlegenden Typechecker eingebaut, der einfache Fehler erkennen kann.
Sobelow-Sicherheitsanalyse laufen lassen. Wir können mal ausprobieren, welche Fehlerstufe hier sinnvoll in der CI zum abbruch führen sollte.
mix_audit: Überprüfen, dass unsere dependencies keine vulnerabilities enthalten.
Überprüfen, dass wir keine dependencies verwenden, die nicht mehr maintained sind: mix hex.audit.
Optional: credo-linter laufen lassen
Optional: Dialyzer via Dialyxir laufen lassen. Der Dialyzer ist ein statisches analyse-tool für Erlang, das mehr Fehler als der Elixir-compiler aufdecken kann.
Optional: test-coverage in einem HTML-report zusammenfassen und den Report als Pipeline-Artefakt hochladen. Idealerweise den Report automatisch in Pull-Requests und im README für den main-branch verlinken.

Ich lege außerdem gerne ein just ci task an, mit dem man in der lokalen Entwicklungsumgebung alles ausführen kann, was die CI normalerweise überprüft. Das geht schneller, als zu pushen und zu schauen, ob die CI Fehler ausspuckt.

Build

Wenn die Checks erfolgreich waren, wird hier ein Container gebaut. Hierfür kann uns Phoenix ein initiales Dockerfile generieren.

Deploy

Der gebaute Container in eine Container-Registry hochgeladen und im Haupt-environment oder in einem temporären Review-environment deployed, je nachdem ob wir auf dem main-Branch oder in einem Pull Request laufen.

Generelles

Migrations & Downtime: Mein Vorschlag ist, die App kurz herunterzufahren, um die Migrations auszuführen. Zero-downtime-migrations sind ein sehr großer Aufwand für verhältnismäßig geringe Vorteile.
Pipeline-Laufzeit: Wir sollten schauen, wie wir möglichst viele Inputs in der CI cachen können. In den Drone docs habe ich dazu auf die schnelle noch nichts gefunden, aber da kriegen wir bestimmt was hin. Zusätzlich sollten wir Jobs innerhalb einer Pipeline möglichst parallel laufen lassen.
Wann läuft die CI? Ich habe gute Erfahrungen damit gemacht, die CI immer für den neuesten commit auf dem main-Branch und in jedem Pull Request laufen zu lassen.

Genau wie Simon bin ich großer Fan von review-environments und voll automatisierten releases. Hier ein Vorschlag für das Setup: ## Checks Hier wird überprüft, dass alles im Projekt so funktioniert wie es soll. - Code-formatierung checken: `mix format` - Postgres-Instanz für Tests starten - Tests laufen lassen: `mix test` - Verifizieren, dass Migrations durchlaufen - Sicherstellen, dass es keine Fehler oder Warnungen beim kompilieren gibt: `mix compile --warnings-as-errors`. In diesem Schritt hat elixir inzwischen [einen grundlegenden Typechecker eingebaut, der einfache Fehler erkennen kann](https://elixir-lang.org/blog/2024/06/12/elixir-v1-17-0-released/). - [Sobelow](https://sobelow.io/)-Sicherheitsanalyse laufen lassen. Wir können mal ausprobieren, welche Fehlerstufe hier sinnvoll in der CI zum abbruch führen sollte. - [mix_audit](https://github.com/mirego/mix_audit): Überprüfen, dass unsere dependencies keine vulnerabilities enthalten. - Überprüfen, dass wir keine dependencies verwenden, die nicht mehr maintained sind: `mix hex.audit`. - Optional: [credo-linter](https://github.com/rrrene/credo) laufen lassen - Optional: [Dialyzer](https://www.erlang.org/doc/apps/dialyzer/dialyzer.html) via [Dialyxir](https://github.com/jeremyjh/dialyxir) laufen lassen. Der Dialyzer ist ein statisches analyse-tool für Erlang, das mehr Fehler als der Elixir-compiler aufdecken kann. - Optional: test-coverage in einem HTML-report zusammenfassen und den Report als Pipeline-Artefakt hochladen. Idealerweise den Report automatisch in Pull-Requests und im README für den main-branch verlinken. Ich lege außerdem gerne ein `just ci` task an, mit dem man in der lokalen Entwicklungsumgebung alles ausführen kann, was die CI normalerweise überprüft. Das geht schneller, als zu pushen und zu schauen, ob die CI Fehler ausspuckt. ## Build Wenn die Checks erfolgreich waren, wird hier ein Container gebaut. [Hierfür kann uns Phoenix ein initiales Dockerfile generieren](https://hexdocs.pm/phoenix/releases.html#containers). ## Deploy Der gebaute Container in eine Container-Registry hochgeladen und im Haupt-environment oder in einem temporären Review-environment deployed, je nachdem ob wir auf dem main-Branch oder in einem Pull Request laufen. ## Generelles **Migrations & Downtime**: Mein Vorschlag ist, die App kurz herunterzufahren, um die Migrations auszuführen. Zero-downtime-migrations sind ein sehr großer Aufwand für verhältnismäßig geringe Vorteile. **Pipeline-Laufzeit**: Wir sollten schauen, wie wir möglichst viele Inputs in der CI cachen können. In den Drone docs habe ich dazu auf die schnelle noch nichts gefunden, aber da kriegen wir bestimmt was hin. Zusätzlich sollten wir Jobs innerhalb einer Pipeline möglichst parallel laufen lassen. **Wann läuft die CI?** Ich habe gute Erfahrungen damit gemacht, die CI immer für den neuesten commit auf dem main-Branch und in jedem Pull Request laufen zu lassen.

👍 2

moritz commented

2025-04-09 14:44:14 +02:00

Author

Owner

Bin hierdrauf noch gestoßen, dein Vorschlag enthält aber auch schon soweit ich es sehe alle Punkte: https://fly.io/phoenix-files/github-actions-for-elixir-ci/
Hier etwas zu Drone Caching: https://laszlo.cloud/the-ultimate-droneci-caching-guide https://github.com/drone-plugins/drone-meltwater-cache

Bin hierdrauf noch gestoßen, dein Vorschlag enthält aber auch schon soweit ich es sehe alle Punkte: https://fly.io/phoenix-files/github-actions-for-elixir-ci/ Hier etwas zu Drone Caching: https://laszlo.cloud/the-ultimate-droneci-caching-guide https://github.com/drone-plugins/drone-meltwater-cache

moritz closed this issue

2025-04-24 16:22:14 +02:00