L'impact du déploiement sur des edge servers (chez cloudflare et compagnie) sur l'architecture d'un système est assez important.
Certains éléments dans ce manifeste sont de bonnes idées, et certains sont de terriblement mauvaises idées.
Un modèle de développement d'applications qui vous permet, indépendamment de développer des micro services ou un monolithem C'est intéressant, même si ça me rappelle assez confusément les EJB. Je note surtout que la première implémentation disponible est en Go.
Donc on peut se faire une version auto-hébergée d'un déploiement automatique de notre projet sur une machine ? C'est très cool (et ça me donne une idée vraiment dingue)
Damnation, il va falloir que je mette tout ça dans les scripts Ansible de mon serveur
Sur la papier, cet outil d'automatisation de dépploiement a l'air sympa. Mais quand j'y réfléchis un peu, ça vaut juste un docker-compose.yml, non ?
Je ne sais pas si je suis à gauche ou à droite, mais je sais que je ne suis pas vraiment au milieu
Dans les cas simples, docker-compose est bien suffisant. Et cet article regorge de bonnes pratiques pour l'utiliser en prod
On serait pas à deux doigts de pouvoir créer des applications natives Windows en pur Rust ? En tout cas, on peut accéder aux API Windows ...
Ah oui, je comprend le buzz autour de cette solution. Ca a l'air vraiment bien. Il manque "juste" le tutorial expliquant comment faire du vrai debug (avec des points d'arrêt et tout ça)
Très chouette liste de mauvaises pratiques franchement communes.
Le moment où on va repasser aux monolithes en tant qu'architecture applicative utile sera vraiment chouette, parce qu'il bénéficiera des leçons apprises des microservices.
Oh c'est génial cette checklist !
Bon, j'ai testé le package manager, et ... ça marche vraiment pas pour mettre des artefacts maven dedans.
J'ai cru initialement que c'était une mauvaise idée, mais j'ai maintenant tendance à changer d'avis : avoir les descripteurs de déploiement générés depuis l'application Java est en fait une bonne idée, pour ceux qui ne veulent pas les écrire eux-mêmes.
J'ai toujours trouvé le concept derrière TCR complètement fou.
Mais en lisant cet article (et en particulier la partie où les deux machines font TCR + git push/pull), je crois qu'il tient une idée ... aussi dingue qu'innovante.
Oh, tiens, un choix judicieux de la part de Facebook (oui, évidement que je dis ça juste parce que je pense que Rust est une sacrément bonne idée)
Un bon article sur la mise en place d'une infrastructure de déploiement "correcte" pour Nifi
J'ai quelques collègues qui seront très intéressés par ce retour d'expérience (je pense en particulier à notre vaultiste local).
Ca marche pour un peu toutes les releases, et c'est cool
Je n'avais pas compris le sens du déploiement K8s dans les toyota. Mais avec cet article, c'est bien plus clair !
Intéressant comparatif des outils de templating Kubernetes. je retiens ksonnet (même si Helm est apparement le standard)
Ca donne vraiment à réfléchir
J'ai déja vu ça ... Et tout le monde avait l'air content de remplacer la simplicité d'appels de méthodes par la mise en place de déploiements complexes. Comme toujours, faire compliqué, c'est simple, mais faire simple, c'est compliqué.
un article raisonnablement complet sur le développement et le déploiement de code java avec Docker
Très intéressant. Le cloud apparaît bien plus possible, quand le MOM y est intégré
Très chouette tutorial sur le déploiement Docker/AWS Beanstalk d'une appli Wisdom ( ... what else ?)
Trop chouette comme truc : au lieu d'installer des Debian et de tenter de maintenir une armée de serveurs, il "suffit" d'installer des instances Deis et de déployer des conteneurs Docker dessus. Trop simple !
Et je découvre que je suis plutôt bon en termes de déploiement (merci amven/jenkins) mais assez pauvre pour le test automatisé et la distribution de code.