CI/CD pour les startups : expédiez plus rapidement sans casser les choses

Les startups qui expédient chaque semaine surpassent celles qui expédient mensuellement. CI/CD est la façon dont vous expédiez chaque semaine sans déployer de bugs. C'est la différence entre une équipe qui avance vite avec confiance et une équipe qui avance vite et interrompt la production un vendredi sur deux.

Si vous dirigez une startup avec 2 à 10 ingénieurs et que vous continuez à déployer en SSH sur un serveur ou en cliquant sur « fusionner » et en priant, ce guide vous guide à travers la configuration minimale CI/CD dont vous avez besoin. La configuration prend un après-midi, coûte 0 $/mois sur les niveaux gratuits et s'amortit la première fois qu'il détecte un bug avant vos utilisateurs.

Ce que signifie CI/CD en anglais simple

Intégration Continue (CI)signifie que chaque changement de code est testé automatiquement. Lorsqu'un développeur ouvre une pull request, un serveur exécute votre linter, votre vérificateur de type et votre suite de tests sur le nouveau code. Si quelque chose échoue, le PR reçoit un X rouge et personne ne le fusionne jusqu'à ce que le problème soit résolu.

Déploiement continu (CD)signifie que chaque test réussi est déployé automatiquement. Lorsque le code fusionne dans votre branche principale, le système le construit, le pousse vers la zone intermédiaire et le rend disponible pour révision. Les déploiements de production s'effectuent en un seul clic ou, si vous faites confiance à votre suite de tests, automatiquement.

C'est ça. CI détecte les bogues avant qu'ils n'atteignent votre branche principale. Le CD transmet le code vérifié à vos utilisateurs sans intervention manuelle. Ensemble, ils remplacent la conversation « ça fonctionne sur ma machine » par « ça a passé le pipeline ».

Pourquoi les startups l'ignorent (et pourquoi cela leur coûte plus tard)

Le manuel déploie le travail chez 2 ingénieurs. Une personne écrit le code, l'autre le révise, quelqu'un exécute git pull sur le serveur et la fonctionnalité est active. Cela semble rapide car la boucle de rétroaction est courte.

Ils cassent à 5. Avec cinq ingénieurs qui poussent le code, vous obtenez des conflits de fusion, des interactions non testées entre les fonctionnalités et des déploiements qui se produisent à des moments aléatoires. Quelqu’un fusionne pendant que quelqu’un d’autre est en cours de déploiement. Le serveur a des modifications non validées depuis un correctif de mardi dernier. Personne ne sait quelle version est utilisée en production.

Au moment où vous avez 10 ingénieurs, les déploiements manuels provoquent2 à 3 incidents de production par mois. Chaque incident nécessite 2 à 4 heures d'ingénierie pour être diagnostiqué et corrigé. Cela représente 4 à 12 heures de temps d'ingénierie senior perdues chaque mois ; le temps que vous payez en salaire mais dont vous n'obtenez aucune valeur de produit.

Le calcul est simple. Un ingénieur senior coûte entre 75 et 150 $/heure. Douze heures de réponse aux incidents par mois coûtent entre 900 et 1 800 $. La configuration de CI/CD prend un après-midi et coûte 0 $/mois sur les niveaux gratuits. Vous récupérez le temps d’installation au cours de votre premier mois.

Le pipeline CI/CD minimum viable

Vous n'avez pas besoin d'un pipeline de 45 minutes comportant 200 étapes. Vous avez besoin de cinq vérifications qui détectent 90 % des bogues avant qu'ils n'atteignent la production.

1. Des peluches sur chaque PR

Le linting détecte les problèmes de style, les variables inutilisées et les erreurs courantes. ESLint avec une configuration standard (comme le préréglage Airbnb ou Next.js) prend 5 à 15 secondes pour s'exécuter et détecte les problèmes qui apparaîtraient autrement lors de la révision du code. Cela permet à vos réviseurs de se concentrer sur la logique et l'architecture au lieu de formater les arguments.

2. Tapez une vérification sur chaque PR

Si vous utilisez TypeScript (et vous devriez l'être), exécutez tsc --noEmit à chaque demande d'extraction. Cela détecte les erreurs de type que votre éditeur pourrait manquer ; notamment les erreurs dans les fichiers que vous n'avez pas directement modifiés mais qui dépendent du code que vous avez modifié. Une erreur de type détectée dans CI coûte 2 minutes à corriger. La même erreur détectée en production coûte 2 heures.

3. Exécutez des tests sur chaque PR

Les tests automatisés vérifient que votre code fait ce qu'il est censé faire. Une suite de tests bien étendue s'exécute en 30 à 90 secondes et détecte les bogues logiques qui manquent au peluchage et à la vérification de type. Vous n'avez pas besoin d'une couverture à 100 %. Vous avez besoin de tests sur les chemins de code qui gèrent l'argent, les données utilisateur et les règles métier de base.

4. Déploiement automatique sur la scène lors de la fusion vers le principal

Lorsqu'un PR réussit toutes les vérifications et est fusionné, le pipeline crée l'application et la déploie dans un environnement de test. Cela donne à votre équipe une URL en direct où les chefs de produit, les concepteurs et les clients peuvent examiner les modifications avant qu'elles n'entrent en production. Plus de « pouvez-vous déployer sur le staging pour que je puisse tester cela ? » messages dans Slack.

5. Déploiement en un clic en production

Les déploiements en production doivent nécessiter une seule action délibérée : cliquer sur un bouton, exécuter une commande ou fusionner avec une branche de production. Le mot clé estvolontaire. Vous voulez qu'un humain décide « oui, c'est prêt pour les utilisateurs », mais vous ne voulez pas que cet humain exécute 15 étapes manuelles pour y parvenir.

Outils et coûts

Vous n'avez pas besoin de dépenser de l'argent pour obtenir un pipeline CI/CD fonctionnel. Chaque outil de cette liste dispose d'un niveau gratuit qui couvre les startups en démarrage.

Actions GitHubest gratuit pour les référentiels publics et comprend 2 000 minutes par mois pour les dépôts privés. C'est suffisant pour une équipe de 5 à 8 ingénieurs réalisant 20 à 30 PR par semaine. Vos étapes de charpie, de vérification de type et de test s'exécutent comme un flux de travail déclenché à chaque demande d'extraction.

Vercelse déploie automatiquement à chaque poussée, vous donne un aperçu des URL pour chaque PR et gère les environnements de transfert et de production prêts à l'emploi. Le niveau gratuit couvre la plupart des startups jusqu'à ce qu'elles atteignent un trafic important. Si vous construisez avec Next.js, Astro ou tout autre framework frontend, Vercel est le chemin le plus rapide vers le CD.

Chemin de fergère les services backend, les bases de données et les travailleurs en arrière-plan avec des déploiements automatiques à partir de GitHub. Le prix commence à 5 $/mois avec une facturation basée sur l'utilisation par la suite. C'est une option intéressante pour les applications full-stack qui nécessitent plus qu'un hébergement statique.

Fly.iodéploie des conteneurs Docker sur des serveurs proches de vos utilisateurs. C'est un bon choix pour les API et les services qui nécessitent une faible latence dans toutes les régions. Le niveau gratuit comprend 3 machines virtuelles partagées et 160 Go de transfert sortant.

Que tester et quoi ignorer

Tout tester ralentit votre pipeline. Ne rien tester ne vous offre aucun filet de sécurité. La bonne réponse se trouve au milieu.

Testez votre logique métier.Si votre application calcule les prix, valide les entrées de l'utilisateur, traite les paiements ou applique des règles de remise, rédigez des tests pour ces fonctions. Ce sont les chemins de code où les bugs coûtent de l’argent.

Testez vos points de terminaison d'API.Envoyez une demande, vérifiez l'état et le corps de la réponse. Cela détecte les erreurs de routage, les bogues de middleware et les problèmes de sérialisation manqués par les tests unitaires.

Ignorez les tests de pixels de l’interface utilisateur.Ne testez pas si un bouton se trouve à 16 pixels du haut de son conteneur. Ces tests s'interrompent à chaque fois que vous modifiez votre mise en page et ne détectent aucun vrai bug.

Ignorer les éléments internes du framework.Ne testez pas si React s'affiche à nouveau lorsque l'état change. L’équipe React l’a déjà testé. Testez ce que fait votre code avec la sortie rendue.

L'échelle de confiance en matière de déploiement

Chaque étape de votre pipeline ajoute une couche de confiance quant à la sécurité du déploiement du code. Considérez-le comme une échelle où chaque barreau détecte une catégorie différente de bugs.

Peluchedétecte les problèmes de formatage et les erreurs courantes.Vérification du typedétecte les formes de données incompatibles et les erreurs de référence nulles.Tests unitairesattraper une logique métier brisée.Tests d'intégrationdétecter les interactions interrompues entre les composants et les services.Aperçu de la mise en scènedétecte les régressions visuelles et les problèmes UX manqués par les tests automatisés.Productionest la dernière étape, où les utilisateurs réels interagissent avec du code vérifié.

La plupart des startups ont besoin des cinq premiers échelons. Vous pouvez ignorer les tests d'intégration dès le début et les ajouter lorsque votre système devient suffisamment complexe pour les justifier. Mais les peluches, les types, les tests unitaires et les aperçus intermédiaires ne sont pas négociables dès le premier jour.

Les déploiements en version préliminaire changent la façon dont les équipes examinent le code

Chaque PR reçoit une URL en direct. Pas une capture d'écran dans un fil de discussion Slack. Pas un enregistrement d'écran. Une version en direct et interactive de votre application avec les modifications proposées s'exécutant sur un serveur réel.

Les chefs de produit cliquent sur la fonctionnalité et laissent des commentaires sur le PR. Les concepteurs vérifient l'espacement et la typographie sur leur propre écran. Les clients voient les progrès en temps réel sans attendre un appel de démonstration. Cela raccourcit les cycles de rétroaction de quelques jours à quelques heures.

Vercel et Netlify le font immédiatement. Chaque poussée vers une branche PR génère une URL d'aperçu unique qui se met à jour automatiquement lorsque vous envoyez de nouveaux commits. Aucune configuration nécessaire au-delà de la connexion de votre dépôt GitHub.

Chez Savi, les déploiements en version préliminaire ont éliminé la conversation « c'était différent sur ma machine ». Les parties prenantes examinent les fonctionnalités dans le même environnement où le code sera finalement exécuté. Si cela fonctionne sur l'URL d'aperçu, cela fonctionne en production.

Erreurs courantes qui ralentissent les équipes

Tout tester.Un pipeline de 25 minutes tue la vitesse du développeur. Les ingénieurs évitent d'ouvrir des PR car la boucle de rétroaction est trop lente. Gardez votre pipeline sous 3 minutes pour les tests de peluches, de types et d'unités. Si cela prend plus de temps, vous testez trop ou vos tests sont mal ciblés.

Ne rien tester.Aucun test ne signifie pas de filet de sécurité. Vous expédierez les bogues plus rapidement, bien sûr, mais vous passerez également vos matinées à réparer ce que vous avez expédié la veille. Commencez par 10 à 20 tests couvrant votre logique métier principale et évoluez à partir de là.

Aucun environnement de mise en scène.Déployer directement d'un PR vers la production signifie que chaque fusion est un pari. La mise en scène vous donne une dernière chance de détecter les problèmes dans un environnement qui reflète la production. Le coût est de 0 $ sur le niveau gratuit de Vercel et de 5 à 20 $/mois sur Railway.

Déploiement vendredi à 17h.Il s’agit d’un problème culturel et non technique. Si quelque chose tombe en panne, personne n'est là pour le réparer. Vos utilisateurs passent le week-end avec un produit cassé et votre équipe passe le lundi matin à contrôler les dégâts. Établissez une règle d'équipe : aucune production n'est déployée après 15 heures le vendredi. Mieux encore, aucune production n'est déployée le vendredi.

Comment Savi met en place chaque projet

Nous configurons CI/CD dans le cadre de chaque build, et non après coup. Voici ce que chaque projet Savi contient dès le premier jour.

Actions GitHub pour CI.Chaque PR déclenche un flux de travail qui exécute ESLint, la vérification de type TypeScript et la suite de tests. Si une étape échoue, le PR ne peut pas être fusionné. Les règles de protection des succursales imposent cela afin que personne ne contourne le pipeline, pas même le chef de projet.

Vercel ou Chemin de fer pour CD.Les applications frontales se déploient sur Vercel avec des URL d'aperçu automatiques à chaque déploiement de PR et de production lors de la fusion vers le principal. Les services backend se déploient sur Railway avec le même modèle de déclenchement. Les deux plates-formes gèrent les restaurations si un déploiement échoue aux vérifications de l'état.

L'aperçu se déploie sur chaque PR.Les clients et les parties prenantes obtiennent une URL en direct pour chaque branche de fonctionnalités. Ils examinent dans le navigateur, laissent des commentaires sur le PR et approuvent avant que le code n'atteigne la production. Cela remplace les appels de démonstration et les enregistrements d’écran par une interaction directe.

Vérification automatique des caractères et peluchage.Nous exécutons du TypeScript strict sans aucun implicite et ESLint avec des règles adaptées pour détecter les vrais bugs, pas les préférences de style. Ces vérifications ajoutent 15 à 30 secondes au pipeline et détectent 60 à 70 % des problèmes avant même qu'un réviseur humain n'examine le code.

Cette configuration prend un après-midi pour être configurée au début d'un projet. Il fonctionne automatiquement pendant toute la durée de vie du produit. Le retour sur investissement se mesure en bugs qui n'atteignent jamais la production, en déploiements qui ne se passent jamais mal et en heures d'ingénierie consacrées aux fonctionnalités plutôt qu'à la lutte contre les incendies.

Questions fréquemment posées