Comment passer correctement des secrets à docker-compose.
Ca n'est généralement pas un problème dans les environments K8s, où docker-compose n'est utilisé que sur le poste des développeurs, mais ça peut aider dans d'autres environnements ...

Encore un outil de build écrit dans un langage de programmation.
(soupir) Le problème avec ces outils est toujours le même : c'est beaucoup trop facile de faire le malin dans son build et de se retrouver avec une usine à gaz inmaintenable par qui que ce soit d'autre.

Oh tiens c'est rigolo cette action GitHub pour assigner automatiquement des labels à une issue en fonction de son texte. J'en ai vu d'autres utilisant des LLM pour ça, mais ça me paraît nettement overkill

C'est comme toujours avec Hey aussi intéressant que disruptif. Et je comprends parfaitement ce point de vue qui existe depuis bien longtemps, parce qu'il est plus facile d'acheter des machines de développeurs que des serveurs. Toutefois, une question demeure : comment garantir que le build fonctionne quelquesoit la machine sur laquelle il est compilé ?

Pourquoi utiliser K8s quand ... un script shell suffit ? (et encore, je trouve que l'auteur se complique la vie puisqu'il recompile chaque projet sur son environnement de prod). Evidement, les professionnels me diront que ça ne marche pas quand on vise le scaling infini. Mais peut-être qu'il ne vise pas le scaling infini ... Par contre, c'est une super implémentation devops

Un article bien organisé sur la sécurité dans le monde Docker. La liste des tâches à mener est bien détaillée.

Comment décommissionner un serveur ? Simplement en l'arrêtant de façon de plus en plus prolongée et en regardant quand les utilisateurs râlent

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)

Comme exactement chaque "innovation" dans le monde de l'informatique, on a enfin atteint le moment où "devops is shit". Et comme exactement chaque fois, ça vient de la complexification imposée par certains acteurs qui y voient leur avantage.

Une intéressante liste de contraintes liées à l'exploitation d'un logiciel. Il y a quelques idées intéressantes.

Une image illustrant bien la simplicité légendaire du DevOps

Je cherchais depuis longtemps un outil pour créer des releases notes à partir de mes issues dans GitHub. Et celui-là a l'air bien.

Bon, en fait, cet outil de monitoring basé sur des actions GitHub est vraiment plus chouette (puisqu'il peut carrément ouvrir des tickets dans mon projet quand il constate des downtimes)

Une critique argumentée assez sévère de la méthodologie de construction de l'étude Accelerate. C'est vraiment une base de réflexion très complémentaire

C'est drôle, parce que c'est vrai

J'aime beaucoup cette distinction entre la pratique devops et le boulot de SRE (qui est une pour moi une évolution moderne du rôle de SysAdmin)

Une présentation (avec transcription complète !) qui présente les fameuses 4 métriques clé d'Accelerate - en oubliant toute la complexité des mesures décrites dans l'ouvrage

Pour l'avoir utilisé, turbine est un très bon outil. Et j'ai d'ailleurs déja dit aux développeurs qu'ils devraient vraiment essayer de le rendre disponible en-dehors d'Adeo.

Carrément d'accord ... Sauf que Jenkins fait partie des "brown tech" : ces produits avec lesquels tout le monde a eu à un moment une mauvaise expérience, donc tout le monde dit "ouin, Jenkins"

Truc de fou (et génial). Maintenant que les pipelines Jenkins sont du code, il est possible de les tester via les outils de test unitaire classiques !