Nous utilisons Ansible pour provisionner les serveurs et/ou déployer nos applications. Au fil des années, nous avons rassemblé notre expérience avec Ansible au sein d’un outil interne qui se veut utilisable facilement par tout le monde chez nous, y compris les personnes moins à l’aise avec l’OPS. Suite à quelques changements récents, nous avons pu simplifier l’étape de génération de certificats sans downtime avec Let’s Encrypt et Certbot. C’est l’occasion de montrer comment nous utilisons ces 2 outils et de partager quelques astuces qui pourront être utiles – que vous utilisiez, ou pas, Ansible et nginx.

Suite à un souci rencontré sur un de mes projets, j’ai dû me plonger dans le fonctionnement de la protection par IP dans nos applicatifs Symfony lorsque des reverse proxies se trouvent devant. Après quelques recherches et tâtonnements, je me suis dit que c’était l’occasion parfaite pour reprendre les bases, puis expliquer comment trouver l’origine du problème et le résoudre. Cet article est donc l’occasion d’expliquer la transmission de l’IP originale de l’utilisateur dans une stack web ainsi que de présenter le fonctionnement du header Forwarded (et les différences avec les headers X-Forwarded-*).

Récemment, j’ai eu l’occasion de passer un peu de temps sur la configuration des CI de plusieurs de nos projets. En effet, après que Travis ait effectué un changement dans son modèle tarifaire, les builds des projets open source l’utilisant mettaient très longtemps avant même de démarrer (parfois plusieurs heures). N’ayant encore jamais joué avec les GitHub Actions, je me suis dit qu’il était temps de s’y mettre. Et à cette occasion, j’ai pu tester différentes configurations pour faire en sorte que les builds soient les plus rapides possibles.

En cette période de confinement, je vous propose de vous évader quelques instants et de partir à la découverte du monde merveilleux du cloud et de démystifier l’utilisation des fonctions en tant que service, notamment grâce aux lambdas d’Amazon. Parce que même si, aujourd’hui, tous les développeurs connaissent le « cloud », beaucoup moins ont déjà eu l’occasion de s’y essayer. Cet article sera donc l’occasion de voir comment mettre en place et exécuter facilement du code dans le cloud avec PHP.

Nous aimerions débuter ce calendrier de l’avent avec un retour d’expérience sur notre migration vers Symfony 5. Nous avons fait évoluer notre side-project Secret-Santa.team de Symfony 4.3 à 4.4, puis 5.0, et nous voulons vous montrer quelles ont été nos difficultés et les changements que nous avons dû apporter, afin de vous éclairer sur la facilité (ou non) d’entreprendre une telle mise à jour. Lire l’article complet sur le calendrier de l’avent de l’afsy.

Chez JoliCode, la plupart de nos projets (clients ou internes) utilisent Docker, principalement pour simplifier l’expérience développeur en local. Quelques uns de nos gros projets ont une architecture suffisamment complexe pour justifier un autre fonctionnement (avec le binaire Symfony par exemple), mais pour tous les autres, l’infrastructure est souvent similaire : NGINX, PHP-FPM et une base de données (MariaDB ou PostgreSQL). Pendant plusieurs années, nous avons copié/collé de projets en projets une infrastructure Docker gérée avec Fabric par dessus Docker Compose.

Les versions de Symfony 3.4 et 4.0 viennent tout juste de sortir et avec elles vient une nouvelle façon de développer des applications Symfony. Dîtes adieu à la Standard Edition et bonjour aux tout nouveaux symfony/skeleton, Symfony Flex et les recettes qui vont avec. Lire l’article complet sur le calendrier de l’avent de l’afsy.

Analyse statique, parseur, AST, etc. Autant de notions que nous ne manipulons que rarement, si ce n’est jamais, dans notre quotidien de développeur Web. Ces notions sont pourtant au coeur des outils que nous utilisons au quotidien : IDE, scripts, intégration continue mais aussi PHP lui-même. Envie de faire une rapide promenade dans le monde de l’analyse statique en PHP et d’apprendre comment vous pouvez analyser vous aussi du code ?