CI/CD pour Rust : Automatisation de la construction et du déploiement à partir de zéro

Pourquoi votre projet Rust mérite-t-il un vrai CI/CD ?

Imaginez : vous écrivez en Rust, le compilateur est votre meilleur ami, le borrow checker ne vous laisse pas vous relâcher, et le code fonctionne à une vitesse fulgurante. Mais dès qu'il s'agit de déploiement, la magie s'arrête. Lancer les tests manuellement, compiler sur votre machine locale, transférer le binaire sur le serveur via SCP — c'est une voie sans issue. Surtout lorsque le projet s'agrandit et qu'un deuxième développeur rejoint l'équipe.

Le CI/CD (Intégration Continue / Déploiement Continu) n'est pas qu'un mot à la mode. C'est un système qui prend en charge la routine : exécuter les tests, vérifier le style du code, compiler la version de release et l'envoyer là où elle doit fonctionner. Pour Rust, avec son accent sur la fiabilité et la performance, l'automatisation de la construction est une extension naturelle de la philosophie du langage.

Dans cet article, nous allons configurer à partir de zéro un pipeline CI/CD pour une application Rust avec GitHub Actions. Vous apprendrez à organiser les tests, le linting, la compilation de binaires pour différentes plateformes et le déploiement. Le tout avec des exemples de code réels que vous pouvez copier dans votre projet.

Qu'allons-nous automatiser ?

Avant d'écrire du code, définissons nos objectifs. Notre pipeline fera quatre choses :

\n
• Linting et formatage — pour que le code soit conforme aux standards Rust et ne contienne pas d'erreurs typiques.
\n
• Tests — exécution de tous les tests unitaires et, s'il y en a, des tests d'intégration.
\n
• Compilation du binaire — compilation de la version optimisée (release).
\n
• Déploiement — téléchargement de l'artefact compilé sur le serveur ou dans les releases GitHub.
\n

Tout cela se produira automatiquement à chaque push sur la branche main ou à la création d'une pull request. Cela semble magique ? En réalité, ce ne sont que des fichiers YAML et quelques commandes Cargo.

Étape 1 : Préparation du projet

Pour l'exemple, prenons un simple serveur web avec Actix-web. Mais le pipeline est universel : il convient à tout projet Rust, qu'il s'agisse d'un utilitaire CLI, d'une bibliothèque ou d'un microservice.

Créons un nouveau projet :

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

Ajoutons les dépendances dans Cargo.toml :

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

Et un code très simple dans 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}

Ajoutons un test simple dans src/main.rs (en bas du fichier) :

#[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}

Tout est prêt. Passons maintenant à la partie la plus intéressante : la configuration du CI/CD.

Étape 2 : Création du workflow GitHub Actions

GitHub Actions est l'outil CI/CD intégré de GitHub. Il fonctionne avec des fichiers YAML situés dans le répertoire .github/workflows/. Créons-le :

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

Ouvrons ci.yml et commençons à écrire le pipeline. Nommons-le "Rust CI/CD Pipeline".

Déclencheur de base et environnement

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