CI/CD für Rust: Build- und Deployment-Automatisierung von Grund auf

Warum Ihr Rust-Projekt ein echtes CI/CD verdient?

Stellen Sie sich vor: Sie programmieren in Rust, der Compiler ist Ihr bester Freund, der Borrow Checker lässt Sie nicht nachlässig werden, und der Code arbeitet blitzschnell. Aber sobald es um das Deployment geht, ist die Magie vorbei. Manuelles Ausführen von Tests, Build auf dem lokalen Rechner, Hochladen der Binary auf den Server per SCP – das ist ein Weg ins Nichts. Besonders wenn das Projekt wächst und ein zweiter Entwickler zum Team stößt.

CI/CD (Continuous Integration / Continuous Deployment) ist nicht nur ein Modewort. Es ist ein System, das die Routinearbeit übernimmt: Tests ausführen, Code-Stil prüfen, eine Release-Version bauen und sie dorthin senden, wo sie arbeiten soll. Für Rust, mit seinem Fokus auf Zuverlässigkeit und Leistung, ist die Build-Automatisierung eine natürliche Fortsetzung der Sprachphilosophie.

In diesem Artikel richten wir von Grund auf eine CI/CD-Pipeline für eine Rust-Anwendung mit GitHub Actions ein. Sie erfahren, wie Sie Tests, Linting, das Erstellen von Binaries für verschiedene Plattformen und das Deployment organisieren. Alles mit echten Codebeispielen, die Sie in Ihr Projekt kopieren können.

Was werden wir automatisieren?

Bevor wir Code schreiben, legen wir die Ziele fest. Unsere Pipeline wird vier Dinge erledigen:

\n
• Linting und Formatierung – damit der Code den Rust-Standards entspricht und keine typischen Fehler enthält.
\n
• Testen – Ausführen aller Unit-Tests und, falls vorhanden, Integrationstests.
\n
• Binary-Build – Kompilieren einer optimierten Version (Release).
\n
• Deployment – Hochladen des erstellten Artefakts auf den Server oder in die GitHub-Releases.
\n

All dies wird automatisch bei jedem Push in den Branch main oder bei der Erstellung eines Pull Requests geschehen. Klingt nach Magie? In Wirklichkeit sind es nur YAML-Dateien und ein paar Cargo-Befehle.

Schritt 1: Projektvorbereitung

Als Beispiel nehmen wir einen einfachen Webserver mit Actix-web. Aber die Pipeline ist universell: Sie passt für jedes Rust-Projekt, sei es ein CLI-Tool, eine Bibliothek oder ein Mikroservice.

Erstellen wir ein neues Projekt:

cargo new rust-ci-cd-demo --bin\ncd rust-ci-cd-demo

Fügen wir Abhängigkeiten in Cargo.toml hinzu:

[dependencies]\nactix-web = "4"\nserde = { version = "1", features = ["derive"] }

Und einen einfachen Code in src/main.rs:

use actix_web::{get, App, HttpResponse, HttpServer, Responder};\n\n#[get("/")]\nasync fn hello() -> impl Responder {\n    HttpResponse::Ok().body("Hello from Rust CI/CD!")\n}\n\n#[actix_web::main]\nasync fn main() -> std::io::Result<()> {\n    HttpServer::new(|| {\n        App::new().service(hello)\n    })\n    .bind(("0.0.0.0", 8080))?\n    .run()\n    .await\n}

Fügen wir einen einfachen Test in src/main.rs hinzu (am Ende der Datei):

#[cfg(test)]\nmod tests {\n    use actix_web::{test, App, web};\n    use crate::hello;\n\n    #[actix_web::test]\n    async fn test_hello_endpoint() {\n        let app = test::init_service(App::new().service(hello)).await;\n        let req = test::TestRequest::get().uri("/").to_request();\n        let resp = test::call_service(&app, req).await;\n        assert!(resp.status().is_success());\n    }\n}

Alles bereit. Jetzt kommt der spannende Teil – die CI/CD-Einrichtung.

Schritt 2: GitHub Actions Workflow erstellen

GitHub Actions ist das integrierte CI/CD-Tool von GitHub. Es basiert auf YAML-Dateien, die im Verzeichnis .github/workflows/ liegen. Erstellen wir es:

mkdir -p .github/workflows\ntouch .github/workflows/ci.yml

Öffnen wir ci.yml und beginnen mit dem Schreiben der Pipeline. Nennen wir sie "Rust CI/CD Pipeline".

Basis-Trigger und Umgebung

name: Rust CI/CD Pipeline\n\non:\n  push:\n    branches: [ main ]\n  pull_request:\n    branches: [ main ]\n\nenv:\n  CARGO_TERM_CO