Django : MEP, versionning et simplification

Le problème exposé dans ce sujet a été résolu.

BOnjour à tous,

Je vais surement poser une question un peu bête mais les multiples tuto de Zds et la doc officielle de Django m’ont plus embrouillé qu’autre chose par la multitude de choix proposé à mon problème :o

Le contexte : Grace au tuto de Zds j’ai développé une application web Django pour ma boîte sur mon temps libre mais maintenant ils aimeraient bien que cet app soit vraiment déployée sur un serveur et utilisable par tout le monde

J’ai donc un site python fonctionnel en local et tout ce qui va bien

Tout le code est versionné sur Github et je me demandais quelle serait la meilleure solution (surtout la plus simple pour un neophyte) pour pouvoir déployer sur une VM mon site en contiuous delivery depuis Github

J’ai trouvé presque autant de facon de faire que de tutoriel en ligne et au final je suis un peu perdu sur quelle serait la solution la plus simple (et surtout la plus simple à apprendre pour un neophyte) pour gérer cela ?

Merci a tous pour votre aide et encore merci a cette belle communauté pour tous les tutos qui m’ont bien aidé :)

Tout le code est versionné sur Github et je me demandais quelle serait la meilleure solution (surtout la plus simple pour un neophyte) pour pouvoir déployer sur une VM mon site en contiuous delivery depuis Github

alliocha1805

Sans trop te prendre la tête : git pull régulier (dans un cron). Tu peux utiliser des clefs SSH en lecture seule depuis le serveur qui fait le pull : https://developer.github.com/v3/guides/managing-deploy-keys/#deploy-keys

C’est un peu la méthode low-cost, mais ça se maintient facilement et tu peux toujours évoluer vers plus sophistiqué si le besoin s’en fait ressentir.
Si tu pars sur cette méthode, surtout, distingue bien une branche pour la production (laquelle est pull sur le serveur de production) et les autres branches de dev. La règle d’or est la suivante : la branche de production (master par exemple, mais c’est pas obligé) doit toujours être garantie prête pour passer en prod. Ça implique un certain workflow avec Git : développer sur une branche de dév., tester, puis merge avec la branche de prod quand tout est nickel.

Selon l’app container que tu utilises (Gunicorn, uWSGI), il faudra voir comment gérer l’autoreload de l’application. Je sais que uWSGI a une option pour ça, où il suffit de touch un fichier pour qu’il recharge (sans downtime) ton application.

+0 -1

Ok ca semble une bonne solution low cost mais juste pour savoir : mettre en place un truc de type Jenkins c’est complexe (ou autre solution si besoin) ?

Pour les questions de PROD / DEV j’ai pas encore ce souci ==> La Prod n’existe pas avant un bon moment ^^

Il faut absolument que ce soit sur une VM de ta boîte ?

Parce qu’avec Heroku, c’est très rapide de déployer une app Django et ça demande aucune maintenance.

Theo

J’avais vu que beaucoup de gens recommandent mais j’ai pas reussi à comprendre pourquoi :o

Ca apporte quoi comme avantages ? (que j’essaye de gratter les 25€ par mois) :)

Il faut absolument que ce soit sur une VM de ta boîte ?

Parce qu’avec Heroku, c’est très rapide de déployer une app Django et ça demande aucune maintenance.

Theo

J’avais vu que beaucoup de gens recommandent mais j’ai pas reussi à comprendre pourquoi :o

Ca apporte quoi comme avantages ? (que j’essaye de gratter les 25€ par mois) :)

alliocha1805

Les avantages c’est qu’ils s’occupent de toute l’infrastructure à ta place, ce qui te permet de te concentrer uniquement sur la partie développement (qui en soi devient une problématique de plus en plus chronophage, surtout en 2020).

Heroku s’intègre très bien avec git. Tu as juste à pousser une branche sur leur « remote » et ils s’occupent du déploiement.

Cela dit je ne sais pas si tu peux programmer facilement des tâches post-déploiement, comme appliquer des migrations éventuelles et consort (je le fais à la main pour le moment, car j’utilise heroku pour héberger un site sous Django et ça se passe très bien).

Il y a des choses qui me dérangent chez Heroku et dont je pourrais parler, mais je suis globalement assez satisfait.

Pas forcément. Tu as un plan gratuit pour une base de données Postgres de 10 000 lignes maximum avec Heroku (Et pour 9 $ tu en as 10 millions, ce qui n’est pas dégueulasse).

Pour les fichiers statiques, tu parles de ceux qui sont téléversés (brr…) par les utilisateurs ? Tu as https://cloudinary.com/ qui est pas mal (bon, après, ça n’est que pour les images). Il doit peut-être y avoir des suppléments via heroku, mais de mémoire ça se rabattait sur des buckets Amazon payants.

OK cest juste pour noter les avantages et inconvénients parceque vu que je dois faire raquer la boîte faut que je donne des arguments :)

Je vais évoquer les deux possibilités (la basique et heroku) et on verra bien ce qu’ils choisissent :)

Merci a tous en tout cas ^^

OK cest juste pour noter les avantages et inconvénients parceque vu que je dois faire raquer la boîte faut que je donne des arguments :)

Je vais évoquer les deux possibilités (la basique et heroku) et on verra bien ce qu’ils choisissent :)

Merci a tous en tout cas ^^

alliocha1805

Avec Heroku ça te coûte peut-être grand max 30 $ / mois. 360 $ par an donc.

Si tu fais ça avec « ta propre VM », le coût se répercute sur le temps de travail d’un de vos collègues (ou du tien). Ce n’est peut-être pas évident à chiffrer, mais tu coûtes bien plus cher à ta boîte.

Le contexte : Grace au tuto de Zds j’ai développé une application web Django pour ma boîte sur mon temps libre mais maintenant ils aimeraient bien que cet app soit vraiment déployée sur un serveur et utilisable par tout le monde

Qu’entends-tu par « utilisable par tout le monde » ? C’est la dizaine d’employés de ta boîte ou plutôt le public avec 100k utilisateurs ?

En fait, ça changerait tout. Pour un petit service interne non critique (= c’est un outil), j’irais au plus simple (et au moins cher), même si ça implique de faire des petits trucs à la main de temps en temps. Dans l’autre cas (= c’est un produit), il faut taper une infra et une stratégie de déploiement solide. Le degré de sophistication est à déterminer en fonction de vos contraintes économiques et de la main d’œuvre technique disponible.

D’expérience des mes anciennes boîtes, je peux quand même te dire que les pipelines super complexes (mais propres) de déploiement aux petits oignons, ça peut vite devenir une tannée quand y a pas du staff (genre DevOps) dédié qui s’occupe de ça en continu. Techniquement c’est cool, mais économiquement, pas toujours. Ce sont des choses à voir avec ton équipe et ceux qui gèrent la partie argent.

On cède parfois aux chants des sirènes et à la doxa des pairs qui nous poussent à toujours avoir la solution le plus correcte sur le plan de l’ingénierie, mais je resterais assez sur mes gardes en privilégiant le pragmatisme pour avoir le truc techniquement juste assez bon pour les besoins, quitte à le faire évoluer au fil du temps vers quelque chose de « propre » si les besoins surviennent pendant la durée de vie du projet.
Là encore, c’est à voir avec ton équipe et la culture technique de ta boîte ;)

+2 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte