Nous souhaitons déployer nos applications plus rapidement certes, mais de manière qualitative et sécurisée. Dans un contexte de plus en plus agile, les méthodes d’audit de sécurité manuelles (tests intrusifs, revue de code) ne sont plus suffisantes, et ne permettent plus de s’adapter à la vélocité des processus de déploiement continu.

Il faut donc automatiser tout ça pour permettre de garder la cadence en évitant de livrer n’importe quoi en production 🙈

Lire la suite

Vous avez, probablement, entendu une des prononciations suivantes : ku-ber-nay-tess , koo-ber-nay-tess, ku-ber-ni-tiss…

Laquelle est correcte ?

Nous pensons que c’est un simple détail. Surement la personne en face de vous comprendra de quoi vous parler. Il y a plein de choses à apprendre beaucoup plus importante que la prononciations. Dans cet article, on évoque l’origine de ce produit ainsi que quelques concepts de base.

L’intégration continue (CI) et la livraison continue (CD) représentent un ensemble de pratiques permettant aux équipes de développement d’appliquer leurs modifications de code de manière plus fréquente, reproductible et fiable. L’implémentation la plus courante du CI/CD est l’utilisation d’un pipeline (une suite d’étapes) dans un orchestrateur (outil qui exécute les actions définies dans les étapes du pipeline).

En déploiement continue, chaque commit est une “release candidat”. Donc potentiellement, une nouvelle version de notre produit. Et comme le principe de base de déploiement continue est l’automatisation, on délègue le changement de version à l’outil de construction (Jenkins, Maven, …).

Un conteneur est un environnement d’exécution isolé. Il comprend le système d’exploitation, les outils systèmes et les librairies. Cette isolation est garantie par des fonctionnalités du noyau Linux : namespaces et cgroups. En effet, cela donne l’impression qu’il s’agit d’une machine virtuelle mais ce n’est pas tout à fait cela. Voyons cela en détails.