Je sais qu’en général, les développeurs aiment bien personnaliser des trucs… Genre en mettant des autocollants sur leur laptop, sur leur voiture, sur leur torse glabre et leur ventre de bière, ou encore sur leurs enfants.
Si c’est votre cas, que vous avez beaucoup de temps devant vous, il existe une extension pour Visual Studio Code qui permet de modifier la couleur de TOUS les éléments de VS Code.
Pour l’installer, rendez-vous sur la marketplace ici puis choisissez VS Look comme thème par défaut. Ensuite, via l’outil de lancement de commande, cherchez VSLook:Edit.
Basiquement, l’outil est un peu pénible à prendre en main, car il existe de très nombreux paramètres à changer, mais les développeurs de ce plugin ont réalisé une doc pour vous guider.
Si vous êtes l’heureux propriétaire d’un de ces nouveaux macbook pro équipés d’une webcam avec la fameuse encoche (notch), peut-être que ça vous agace fortement d’avoir ce truc au milieu de votre écran.
À partir de là, 2 choix s’offrent à vous. Le premier est d’aller consulter un médecin puisque visiblement vous êtes assez maniaque. Le second choix est de tout simplement le faire disparaître tel un ninja qui se fond dans l’obscurité.
Et comment est-ce qu’on fait ça ? Et bien avec ce logiciel gratuit pour macOS nommé TopNotch qui fera passer votre écran de ça :
à ça :
Les dev ne savent plus quoi inventer… C’est juste une application qui passe la barre de menu en noir.
Et pourtant, je suis sûr que ça rendra super service à beaucoup de monde.
Je ne me lasse pas de ces émulateurs x86 qui permettent au travers d’une page web de faire tourner d’anciens OS tels que Windows 95, Windows 2000 ou encore ReactOS. Mais également des trucs encore d’actualité comme FreeDOS, OpenBSD ou Haiku.
Le projet v86 émule un processeur et du matériel compatible x86. Ainsi, le code machine est traduit en modules WebAssembly au moment de l’exécution ce qui permet d’obtenir des performances décentes.
Sur le site copy.sh/v86/ vous pourrez ainsi lancer du DOS, du Windows ou encore du Linux et du BSD, directement à partir des images proposées ou charger vous-même votre propre image CD, disquette, disque dur…etc. Le matériel émulé est un CPU compatible x86 équivalent d’un Pentium III de l’époque avec le support SSE2 et d’autres choses comme un contrôleur de lecteur de disquette, un clavier PS2, une carte VGA ou encore une carte réseau PCI NE2000.
Comme le projet est open source, vous pouvez le forker et déployer ça sur votre propre serveur si besoin. En tout cas, c’est une chouette initiative.
Aujourd’hui les amis, nous allons parler d’un sujet très cher au Devops : Le CI/CD !
Pour ceux qui auraient zappé ces 10 dernières années, le CI/CD est une méthode de développement qui permet de publier des mises à jour de votre code à tout moment sans impacter ce qui est en production. C’est donc parfait lorsqu’on a besoin de mettre en place des cycles de développement plus rapide avec des modifications de code quotidiennes.
En ce qui concerne la signification, CI veut dire « Intégration Continue » et CD, « Déploiement Continu ». C’est très demandé dans les entreprises actuelles et en tant que développeur ou devops, c’est un sujet que vous devez connaître surtout si vous avez prévu de changer de travail pour quelque chose qui vous correspond plus.
Si vous souhaitez être plus proche de chez vous voire en télétravail, avoir un meilleur salaire ou tout simplement travailler sur des projets plus intéressants, je vous invite à vous créer un compte sur la plateforme talent.io. Ça se fait en quelques clics et vous recevrez ensuite des offres de la part d’entreprises qui correspondent à vos critères et qui affichent le salaire d’entrée de jeu ! talent.io c’est LE moyen le plus simple et le plus rapide de trouver votre prochain job tech. Les inscrits trouvent leur emploi en 20 jours en moyenne.
L’intégration Continue
Ce qu’on appelle Intégration Continue (CI) consiste pour les développeurs à tout simplement fusionner avec la branche master, l’ensemble de leurs modifications et cela autant de fois qu’ils le souhaitent
Ainsi, une équipe de développeurs peut travailler simultanément sur le même projet. Le fait d’intégrer une équipe de développeur dans un processus CI/CD permet de s’assurer que le code est testé, correctement formaté et compatible avec l’existant avant de le déployer.
Chacune de ces fusions de code va alors déclencher automatiquement une séquence qui « construire » (build) et tester le code. Ainsi, à chaque ouverture d’une pull request ou à chaque modification du code, le serveur git envoie une notification au serveur d’intégration continue. Ce dernier va alors cloner le dépôt, effectuer les checkouts nécessaires sur la branche source pour enfin la fusionner avec la branche master. Puis le script de build est alors lancé. Cette étape permet ainsi de valider que le code est sûr et respecte les bonnes pratiques, mais également d’automatiser le chargement des dépendances, l’installation des outils nécessaires à l’application et bien sûr la compilation si besoin.
Exemple de script dans l’éditeur de pipeline de Gitlab
La phase de build
Cette phase de build vérifie que l’application, selon le code qui a été commité, peut se qualifier pour les tests ultérieurs.
Cela consiste à « construire » l’application. Avec des langages compilés, ça signifie obtenir un binaire opérationnel alors que sur les langages interprétés, cela consiste à valider la présence des dépendances et des outils nécessaires pour construire l’application. L’objectif ici est d’avoir quelque chose qu’on puisse lancer et tester. Cela peut donc être un binaire, un programme d’install, une image docker, un site web…etc.
La phase de test
La seconde étape consiste à analyser le code sous différents aspects à l’aide d’outils de tests automatisés. C’est une étape qui lorsqu’elle est faite manuellement, est boudée par les développeurs qui la trouvent chronophage et ennuyeuse. On pourrait bien sûr déléguer les tests à d’autres personnes, mais cela déconnecte les développeurs de l’ensemble du projet sans parler du fait que les testeurs vont passer leur temps à les déranger.
Les étapes de validation
Ainsi durant cette phase de test, le linting qui consiste à vérifier le code pour détecter les erreurs programmatiques et stylistiques. Cela permet de s’assurer une certaine homogénéité dans le code.
La qualité du code et de ses fonctions est également évaluée et de nombreuses mesures comme le nombre de lignes, la documentation ou la complexité du code sont prises en compte pour déterminer les endroits dans le projet où le code peut être amélioré.
La sécurité du code est également prise en compte à l’aide d’outils d’analyses qui partent à la recherche des risques de vulnérabilités dans le code lui-même et ses dépendances.
L’accès aux logs
Tout cela se fait durant un laps de temps assez rapide (moins d’une dizaine de minutes) selon les ressources machines disponibles et une fois que la séquence est terminée avec succès, cela signifie que la Pull Request est autorisée et on peut alors passer à la phase de déploiement.
Évidemment, si la séquence est stoppée à cause d’une erreur, la fusion du code est stoppée et un rapport est généré pour permettre aux développeurs de résoudre rapidement le souci. Le CI permet ainsi de travailler par petites itérations et les bugs peuvent ainsi être corrigés plus rapidement.
Vient ensuite une phase « release » qui consiste à packager l’application pour son déploiement ou sa distribution en y intégrant le code de l’application, les scripts d’installation, les dépendances et autres bibliothèques, la documentation, les métadonnées et bien sûr la licence.
Cette version packagée de l’application est alors disponible pour être distribuée ou publiée sur le serveur et servir de point de départ à une configuration des éléments tiers comme la base de données. Si on s’arrêtait à cette étape, on parlerait alors de « livraison continue » (Continuous Delivery), c’est à dire s’assurer que le code est en permanence déployable.
Mais avec le déploiement continu, comme avec talent.io, on va un peu plus loin. D’ailleurs pensez bien lorsque vous renseignerez votre profil talent.io à vous démarquer en faisant ressortir vos points forts comme la maîtrise des concepts CI/CD et vos éléments différenciant pour que les entreprises qui recrutent s’arrêtent sur votre profil.
La phase CD (Déploiement Continue) permet de déployer cette release sur le serveur de destination soit directement après chaque pull request, soit en respectant un calendrier de mise en prod ou sur action humaine uniquement. Ainsi, chaque changement qui arriver à passer toutes les étapes de validation (CI) peut alors finir en production, et cela sans aucune intervention humaine.
C’est donc un excellent moyen d’accélérer la mise en production des nouveautés et permet aux développeurs de se concentrer sur l’écriture de code plutôt que d’organiser des journées de mises en production après des mois de travail à l’aveugle.
Pour faire du CI/CD, il existe des dizaines de solutions commerciales dont voici les plus connues et utilisées :
Jenkins est super populaire, car totalement libre et gratuit et permet de décrire des pipelines de construction avec le langage Groovy. Il offre ainsi plus de flexibilité, mais demande un peu plus de compétences techniques.
GitHub Actions, cet outil de CI/CD proposé sur le site GitHub et son équivalent pour les entreprises, permet de construire ses pipelines à l’aide d’une configuration YAML.
Gitlab CI/CD est semblable à Github Actions. Il est capable de pointer de manière assez spécifique vers les tests qui ont échoué, ce qui permet un debug plus rapide.
Enfin, Travis CI totalement dans le cloud permet de monter ses routines CI/CD sans aucune configuration complexe. Et comme il est compatible gratuitement avec Github, Bitbucket ou encore Gitlab, vous pouvez également l’utiliser pour vos projets open source ouvert.
Conclusion
Vous l’aurez compris, il y a de nombreux avantages à mettre en place une procédure CI / CD. En procédant par petites étapes, et en multipliant le nombre d’itérations, on réduit ainsi la probabilité d’erreur et la quantité de travail nécessaire à l’intégration des changements dans l’application. Au contraire, travailler dans de longues boucles de rétroaction est beaucoup plus risqué pour le projet et le temps de travail est plus difficile à estimer.
Le fait d’automatiser toutes ces étapes d’intégration soulage fortement les développeurs des tâches répétitives et permet d’éviter bon nombre d’erreurs humaines à l’aide des tests automatisés effectués à chaque livraison de code. Cela se fait d’ailleurs en toute transparence avec un accès rapide aux logs et il devient très simple de comprendre d’où provient l’erreur.
Il y a donc une meilleure productivité de la part des développeurs, des releases plus fréquentes et une augmentation de la qualité et de la sécurité de ce qui est produit grâce à la standardisation des tests.
Si vous ne l’avez pas encore mis en place dans votre entreprise, je vous recommande vivement d’essayer l’approche CI/CD. Cela vous soulagera sur bien des aspects, notamment en ce qui concerne les tests et l’ensemble des tâches rébarbatives et vous pourrez enchaîner les déploiements dans la joie.
Vous avez surement suivi l’arrivée de Dall-E 2, une IA extraordinaire d’OpenAI capable de générer des images assez qualitatives à partir d’un simple texte.
Pour le moment, on ne peut pas encore réellement tester l’outil, car c’est encore sur liste d’attente. Mais j’ai quand même de quoi vous occuper avec l’IA de Craiyon qui n’a pas grand-chose à voir avec sa grande sœur, mais qui est quand même assez rigolo.
Le principe est le même. Vous écrivez une phrase en anglais et l’outil vous générera des images logiquement moches, mais avec quand même une idée.
Voici quelques exemples de requêtes que j’ai pu effectuer :
Je sens que ça ne va pas trop taffer au bureau ce matin 🙂
