Ce que « déployer depuis Git » veut dire réellement
Pendant l'essentiel de l'histoire du métier, déployer voulait dire qu'une personne exécutait une séquence à la main : construire en local, copier des fichiers sur un serveur, lancer une migration, redémarrer un processus, espérer n'avoir rien oublié. Chaque étape était une occasion de faire les choses un peu différemment de la fois précédente — et l'écart entre « ça marche chez moi » et un site de production cassé vivait précisément dans ces étapes-là.
Le déploiement git remplace cette séquence par une règle : la branche fait foi, et ce qui s'y trouve est ce qui tourne. Vous n'envoyez rien. Vous poussez, et la plateforme fait le même build à l'identique, à chaque fois. C'est la reproductibilité qui compte — pas le confort.
Ce qui se passe entre votre push et l'application en ligne
La chaîne est courte et mérite d'être connue, car lorsqu'un problème survient vous voulez savoir quel maillon regarder.
Votre push arrive dans le dépôt, qui nous prévient. Nous vérifions si ce dépôt et cette branche précis sont bien connectés à une application ; si c'est le cas, une build démarre. La build s'exécute dans un bac à sable isolé — votre code ne partage jamais un processus avec celui de quelqu'un d'autre — et produit une image de conteneur à partir de votre Dockerfile. Ce n'est qu'une fois l'image prête que la plateforme démarre la nouvelle version et retire l'ancienne. Si la build échoue, rien n'est remplacé : la version précédente continue de servir le trafic, ce qui est exactement le comportement que vous voulez à 2 h du matin.
L'accès est éphémère par conception : l'identifiant utilisé pour lire votre dépôt est créé au moment du déploiement plutôt que stocké, si bien qu'un jeton dormant dans notre base de données ne peut pas survivre à son utilité.
Ce dont votre dépôt a besoin
Une chose, principalement : un **Dockerfile**. C'est la recette qui transforme vos sources en image exécutable — image de base, dépendances, étape de build, commande de démarrage. Si votre projet n'en a pas encore, l'écrire est une tâche à faire une seule fois, et le même fichier fonctionne sur votre portable.
Deux détails font gagner le plus de temps. D'abord, votre application doit écouter sur le port que vous avez indiqué à la plateforme, et sur toutes les interfaces (`0.0.0.0`) plutôt que seulement sur `localhost` — un conteneur qui se lie à localhost est injoignable depuis l'extérieur de lui-même. Ensuite, tout ce qui est secret (URL de base de données, clés d'API) a sa place dans des variables d'environnement, pas dans l'image : les images sont reconstruites et déplacées, et un secret cuit dans l'une d'elles est un secret que vous ne pouvez pas faire tourner.
Un projet multi-services fonctionne de la même façon via un fichier Docker Compose — chaque service qui n'a pas d'image prête a besoin d'un Dockerfile constructible, et la stack démarre déjà câblée.
Branches : tenez la production à l'écart de votre travail quotidien
C'est là que les équipes se font mal, et le remède est une décision plutôt qu'une fonctionnalité. Si la production est connectée à la branche sur laquelle vous développez, chaque commit à moitié fini part en ligne. Connectez la production à une branche dans laquelle vous ne fusionnez que lorsque vous le décidez vraiment — souvent `main` tandis que le travail quotidien se fait sur des branches de fonctionnalité, ou une branche `production` dédiée si `main` est l'endroit où vous itérez.
Le test mental utile : « si je pousse tout de suite, suis-je à l'aise à l'idée que des visiteurs le voient ? » Si la réponse est un jour non pour la branche connectée, c'est la branche qui est mauvaise, pas le processus.
Un flux de release qui garde la production ennuyeuse
# gundelik is: feature dalinda
git checkout -b feature/yeni-fiyatlandirma
git commit -am "pricing page"
git push origin feature/yeni-fiyatlandirma # deploy TETIKLEMEZ
# yayina hazir oldugunda
git checkout main
git merge feature/yeni-fiyatlandirma
git push origin main # deploy BU push ile baslarQuand un push ne se voit nulle part
Le déploiement a tout d'un tour de magie jusqu'au jour où il ne fait silencieusement rien : diagnostiquez donc dans l'ordre où la chaîne s'exécute.
Commencez par la fin : une build a-t-elle seulement démarré ? Si aucune build n'apparaît pour votre push, le maillon qui a cédé est la connexion — le dépôt ou la branche n'est pas celui qui est rattaché, ou l'intégration a perdu son accès (installation révoquée, dépôt renommé ou transféré). Si une build a démarré et échoué, le journal de build vous dit exactement où ; les causes les plus fréquentes sont une étape du Dockerfile qui passe en local grâce à un fichier que votre `.dockerignore` exclut, ou une installation de dépendances qui réclame un identifiant dont la build ne dispose pas. Si la build a réussi mais que vous voyez toujours l'ancienne version, vous regardez presque à coup sûr une réponse en cache plutôt qu'une application périmée — demandez la page avec un cache-buster ou vérifiez l'en-tête d'état du cache avant de soupçonner le déploiement.
Un cas peu évident mérite d'être connu : relancer un déploiement pour un commit qui a déjà échoué ne le réparera pas de lui-même. Le commit est l'entrée ; si l'entrée ne change pas, le résultat non plus. Poussez un correctif — même un commit vide — plutôt que de réessayer le même.
Vérifier l'état et forcer un déploiement depuis le terminal
# calisan uygulamanin durumu
cdnctl container apps list --account <uuid>
# son deploy ne yapti
cdnctl container apps logs --account <uuid> --app <app_uuid>
# elle yeniden dagit (ayni commit)
cdnctl container apps deploy --account <uuid> --app <app_uuid>Ce que vous y gagnez une fois que c'est devenu ennuyeux
Le vrai bénéfice du déploiement git n'est pas la vitesse, c'est que déployer cesse d'être un événement. Quand livrer se résume à un push, les petits changements partent tout seuls au lieu de s'accumuler dans une release mensuelle risquée — et les petits changements sont ceux que vous savez déboguer, parce que lorsque quelque chose casse vous savez exactement quel commit l'a fait.
Cela transforme aussi le rollback en opération ordinaire plutôt qu'en urgence : l'image précédente est toujours là, et revenir en arrière est un déploiement comme un autre. Les équipes qui livrent chaque jour ne sont pas plus courageuses que celles qui livrent chaque mois ; elles ont rendu chaque déploiement pris isolément assez petit pour être sans intérêt.
Questions fréquentes
Ai-je besoin d'un Dockerfile, ou la plateforme peut-elle deviner comment construire mon application ?
Vous avez besoin d'un Dockerfile. Nous ne devinons pas de build à votre place — le fichier est explicite sur l'image de base, les dépendances et la commande de démarrage, et c'est précisément pour cela que la build est reproductible. Le même fichier construit à l'identique sur votre machine.
Qu'arrive-t-il à l'application en cours pendant qu'une nouvelle version se construit ?
Elle continue de servir. La nouvelle version ne remplace l'ancienne qu'une fois l'image construite avec succès ; une build en échec laisse la production exactement telle qu'elle était.
Puis-je déployer sans pousser — par exemple pour relancer la dernière version ?
Oui. Un déploiement peut être déclenché manuellement depuis le panneau ou avec cdnctl, en utilisant le même commit. Utile après avoir modifié une variable d'environnement, ce qui ne crée pas de nouveau commit.
Comment garder mes secrets hors du dépôt ?
Placez-les dans les variables d'environnement de l'application, pas dans le Dockerfile ni dans le code. Tout ce qui est cuit dans une image voyage avec cette image et ne peut pas être renouvelé sans une reconstruction.
J'ai poussé mais rien ne s'est passé. Où regarder en premier ?
Vérifiez si une build a seulement démarré. Aucune build signifie un problème de connexion (mauvaise branche, accès révoqué, dépôt renommé). Une build en échec renvoie au journal de build. Une build réussie avec un site qui a l'air ancien veut généralement dire que vous voyez une réponse en cache.